Lightweight project decomposition skill. Analyzes project scope through a brief interview and determines whether the project should be treated as a single feature or split into multiple sub-features. For multi-split projects, generates a project manifest listing sub-features, dependencies, and execution order.
Analyzes project scope to determine if it should be developed as a single feature or split into multiple sub-features with dependencies.
npx claudepluginhub tercel/spec-forgeThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Analyze project scope and determine whether to treat it as a single feature or split into multiple sub-features before entering the spec chain.
Scan the project to understand what exists:
docs/ for existing specification documents and project manifestsideas/{feature-name}/draft.md exists — if found, read it for context on scopeSummarize what you learned in 2-3 sentences. Do not present this to the user — it is internal context for the interview.
Use AskUserQuestion to understand project boundaries. Ask 3-5 rounds of questions, adapting based on answers.
Round 1 — The Shape:
Round 2 — Boundaries:
Round 3+ — Clarification (if needed):
Do NOT force answers. If the user says "I'm not sure", use your judgment based on what you know.
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:
If the project is a single feature:
If the project should be split:
docs/project-{name}.mdManifest 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:
user-auth, payment-processing)docs/ — each sub-feature gets docs/{name}/prd.md etc.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