Classify project type, recommend approach, identify needed agents, estimate complexity, and flag risks. Runs BEFORE /decompose to help North Starr adapt its pipeline to what is being built.
Instalação
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Classify project type, recommend approach, identify needed agents, estimate complexity, and flag risks. Runs BEFORE /decompose to help North Starr adapt its pipeline to what is being built.
argument-hint
<requirement text, file path, or brief description>
Assess — Project Type Recommendation
Purpose
When a client gives a raw requirement, this skill classifies the project type and recommends the right approach BEFORE decomposition begins. It answers the questions that /decompose and chief-ai-po don't ask: what KIND of project is this, what agents will it need, and what's the right architecture approach?
Without /assess, the pipeline treats every project identically. With it, North Starr adapts its agent activation, pipeline configuration, and complexity expectations to the specific project type.
When to Use
Before /decompose — when a client gives a raw requirement and you need to understand what kind of project it is
Before /discover — when you want to validate your understanding of the project type before eliciting detailed requirements
On demand — when mid-project you realize the project type has shifted (e.g., what started as an automation pipeline now needs multi-agent orchestration)
For projects where the type is already clear and documented, skip directly to /decompose.
Input
The user provides one of:
Pasted text — a raw requirement, brief, or description
File path — a document (markdown, text, PDF) containing the requirement
Conversation summary — output from /discover or a prior discussion
Workflow
Step 1: Read & Understand the Requirement
Actions:
If a file path is provided, read the content (use PDF pagination for large PDFs)
If text is pasted, use it directly
Extract the core intent: what problem is being solved, for whom, at what scale
Identify any explicit constraints mentioned (budget, timeline, compliance, existing infrastructure)
Step 2: Classify Project Type
Evaluate the requirement against these project types:
Risk flags — check each. For every flag that applies, you MUST state (a) the concrete impact on this project and (b) a specific mitigation or next step. Do not list a risk without both.
Needs fine-tuning — domain-specific style or format that prompt engineering alone won't achieve
Needs existing infrastructure — depends on databases, APIs, or services not yet available
Needs credential provisioning — external API keys, OAuth flows, service accounts
High cost risk — large volume, expensive models, or open-ended generation
Novel problem — no established pattern in the team's experience
Multi-team dependency — requires coordination with other teams or external vendors
Example of a properly flagged risk:
Needs credential provisioning — Impact: Zendesk API requires OAuth2 service account; BUILD phase will block until credentials are provisioned. Mitigation: Request credentials in parallel with DESIGN phase; integration-planner will flag BLOCKED if missing at BUILD start.
