Decompose — Project Scope Analysis

Analyze project scope and determine whether to treat it as a single feature or split into multiple sub-features before entering the spec chain.

Core Principles

1. Lightweight: 3-5 rounds of questions, not a deep investigation
2. Boundary-focused: Only care about scope boundaries and dependencies
3. No demand validation: That is /idea's responsibility
4. No deep research: That is /prd's responsibility
5. Single is valid: Not every project needs splitting — a single-feature verdict is a good outcome

Workflow

Step 1: Read Context

Scan the project to understand what exists:

1. Use Glob to scan the project directory tree (top 3 levels)
2. Read the project README.md if it exists
3. Scan docs/ for existing specification documents and project manifests
4. Check if ideas/{feature-name}/draft.md exists — if found, read it for context on scope

Summarize what you learned in 2-3 sentences. Do not present this to the user — it is internal context for the interview.

Step 2: Scope Interview

Use AskUserQuestion to understand project boundaries. Ask 3-5 rounds of questions, adapting based on answers.

Round 1 — The Shape:

• What are the main functional areas or modules of this project? (e.g., "auth, payments, notifications" or "it's a single API endpoint")
• How big is this project in your mind — a single focused feature, or multiple related features?

Round 2 — Boundaries:

• Which parts could be developed and tested independently?
• Which parts depend on each other? (e.g., "payments needs auth to exist first")
• Are there shared foundations that multiple parts need? (data models, infrastructure, auth)

Round 3+ — Clarification (if needed):

• Follow up on anything unclear from rounds 1-2
• Stop when you can confidently propose a split structure

Do NOT force answers. If the user says "I'm not sure", use your judgment based on what you know.

Step 3: Split Decision

Based on the interview, determine: single or multi-split.

Split heuristics:

Signal	Verdict
Multiple distinct systems (backend + frontend + pipeline)	Multi-split
Repeated "and also..." in scope description	Multi-split
No single clear purpose — hard to name in one phrase	Multi-split
Would produce 10+ PRD requirement groups	Multi-split
Single cohesive system with tightly coupled components	Single
Fully specifiable in a few paragraphs	Single
No architectural decisions needed at the boundary level	Single
Too unclear even after interview — need PRD to discover structure	Single

Good split characteristics:

• Cohesive purpose — a clear goal or outcome
• Bounded complexity — 1-3 major components
• Clear interfaces — well-defined inputs and outputs
• Each split is substantial enough for its own PRD → SRS → Tech Design → Test Plan → Feature Spec chain

Step 4a: Single Feature Verdict

If the project is a single feature:

1. Inform the user: "This project is well-scoped as a single feature. Proceeding directly to the spec chain."
2. Return the verdict. Do NOT generate a manifest file.

Step 4b: Multi-Split — Generate Manifest

If the project should be split:

1. Present the proposed split structure to the user for confirmation
2. Use AskUserQuestion: "Here's my proposed breakdown. Does this look right, or would you change anything?"
3. If the user wants changes, adjust and re-confirm
4. Once confirmed, write the manifest to docs/project-{name}.md

Manifest format:

The file MUST start with a FEATURE_MANIFEST comment block, followed by human-readable content:

<!-- FEATURE_MANIFEST
{sub-feature-1}
{sub-feature-2}
{sub-feature-3}
END_MANIFEST -->

# Project: {name}

## Sub-Features

### 1. {sub-feature-1}
- **Description**: {what this sub-feature covers}
- **Dependencies**: {none, or list of sub-feature names it depends on}
- **Scope**: {brief scope summary}

### 2. {sub-feature-2}
- **Description**: ...
- **Dependencies**: ...
- **Scope**: ...

## Execution Order

{Ordered list with dependency and parallelism notes}

## Cross-Cutting Concerns

{Shared data models, conventions, infrastructure, or other things that span multiple sub-features}

FEATURE_MANIFEST rules:

• Must be at the TOP of the file (before any other content)
• One sub-feature per line, kebab-case (e.g., user-auth, payment-processing)
• Names become directory names under docs/ — each sub-feature gets docs/{name}/prd.md etc.
• This block is machine-parseable; the rest of the file is for humans

Step 5: Summary

Display the result:

If single:

Scope analysis complete: {name}
  Verdict: Single feature
  Next: Running spec chain (PRD → SRS → Tech Design → Test Plan → Feature Spec)

If multi-split:

Scope analysis complete: {name}
  Verdict: {N} sub-features
  Manifest: docs/project-{name}.md

  Sub-features:
    1. {sub-feature-1} — {one-line description}
    2. {sub-feature-2} — {one-line description}
    ...

  Next: Running spec chain for each sub-feature