Help us improve
Share bugs, ideas, or general feedback.
From spx-legacy
ALWAYS invoke this skill when breaking down a PRD into capabilities. NEVER decompose PRDs without this skill.
npx claudepluginhub outcomeeng/claude --plugin spx-legacyHow this skill is triggered — by the user, by Claude, or both
Slash command
/spx-legacy:decomposing-prd-to-capabilitiesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<objective>
Translate product intent into implementation-ready capability plans that expose constraints, interfaces, and unresolved decisions. Useful when multi-service work needs explicit contracts before coding.
Transforms PRD intent, roadmap requirements, or product discussions into implementation-ready capability plans that expose constraints, invariants, interfaces, and unresolved decisions before multi-service work begins.
Analyzes PRD into atomic features with Gherkin acceptance criteria, performs product/architecture/QA analysis, generates dependency graphs, MVP features, and project plans from specs.
Share bugs, ideas, or general feedback.
You must understand:
<quick_start>
</quick_start>
Read the PRD and ask: "What should this product be CAPABLE of doing?"
| Look for | Examples |
|---|---|
| Core functionality areas | "Generate documents", "Manage user identities" |
| Cross-cutting concerns | "Analytics", "Notifications", "Audit logging" |
| Infrastructure needs | "Test harness", "CLI tooling" |
| Integration points | "Third-party API integration", "Export/import" |
A capability is what the product CAN DO.
Examples of good capability names:
NOT capabilities:
A single capability is valid. The tree grows organically.
spx/
├── product.prd.md
└── 21-core.capability/ ← Start with one
└── 21-first-feature.feature/
└── 21-first-story.story/
Later, you might add:
spx/
├── product.prd.md
├── 13-test-infrastructure.capability/ ← Discovered dependency
├── 21-core.capability/
└── 54-advanced.capability/ ← Added as product grows
Lower BSP = dependency. Order by what depends on what.
| Pattern | BSP Strategy |
|---|---|
| Infrastructure (test harness, tooling) | Low BSP (10-20) |
| Core functionality | Mid BSP (21-50) |
| Advanced/optional features | High BSP (54-80) |
| Improvements/polish | Highest BSP (76-99) |
| Scenario | Formula | Example |
|---|---|---|
| First capability | 21 | 21-core.capability/ |
| Insert before 21 | floor((10+21)/2) = 15 | 15-infra.capability/ |
| Insert between 21 and 54 | floor((21+54)/2) = 37 | 37-new.capability/ |
| Append after 54 | floor((54+99)/2) = 76 | 76-advanced.capability/ |
Capabilities with the same BSP can be worked on in parallel:
37-users.capability/ ← Same BSP = parallel
37-billing.capability/ ← Same BSP = parallel
37-reports.capability/ ← Same BSP = parallel
For each capability, create:
spx/NN-{slug}.capability/
├── {slug}.capability.md
└── tests/ # Created when starting implementation
Use the template from /managing-spx:
# Capability: {Name}
## Purpose
{What this product ability delivers and why it matters to users}
## Success Metric
- **Baseline**: {Current state}
- **Target**: {Expected improvement}
- **Measurement**: {How to track}
## Requirements
{Prose from PRD, focused on this capability's scope}
## Test Strategy
{Overview of how this capability will be tested—can span multiple levels}
## Outcomes
{Capability-level outcomes, if any—remember Principle 11}
## Architectural Constraints
{ADRs and PDRs that constrain this capability}
Note on Outcomes: A capability may have its own outcomes (high-level integration/E2E scenarios) OR it may have no direct outcomes—just features underneath. Both are valid.
For each capability:
□ Represents what the product CAN DO
□ Is a coherent cross-cutting area
□ Has clear boundaries with other capabilities
□ BSP reflects actual dependencies
□ Can be decomposed into ≤9 features (if needed now)
PRD excerpt:
"Hardware engineers need to configure SPI peripherals, generate Verilog, and verify on real FPGAs."
Analysis:
| Product ability | Capability? |
|---|---|
| "SPI Peripheral Support" | YES - what the library CAN DO |
| "Code Generation" | YES - distinct ability |
| "FPGA Verification" | MAYBE - could be part of code gen or separate |
Possible structures:
Option A: Start small
spx/
├── spi-library.prd.md
└── 21-spi-peripherals.capability/
Option B: Separate concerns
spx/
├── spi-library.prd.md
├── 13-test-infrastructure.capability/
├── 21-spi-peripherals.capability/
└── 54-fpga-verification.capability/
Both are valid. Start with A, grow to B as needed.
PRD excerpt:
"Users need to register, log in, reset passwords, and manage their profiles. Support OAuth and magic links."
Analysis:
This is ONE capability: "Identity and Authentication Management"
spx/
├── auth-system.prd.md
└── 21-identity-auth.capability/
├── 21-registration.feature/
├── 37-login.feature/
├── 54-password-reset.feature/
└── 76-oauth.feature/
NOT separate capabilities for login, registration, etc.—those are features.
PRD excerpt:
"Customers browse products, add to cart, checkout with payment, track orders."
Analysis:
| Product ability | Capability |
|---|---|
| Product catalog | 21-catalog.capability/ |
| Shopping cart | 37-cart.capability/ |
| Payment processing | 37-payment.capability/ |
| Order fulfillment | 54-fulfillment.capability/ |
Note: cart and payment are parallel (same BSP)—neither depends on the other.
<anti_patterns>
| Anti-pattern | Why wrong | Correct level |
|---|---|---|
| "User Login" | Too small | Feature |
| "Parse Config" | Too small | Story |
| "Sprint 1" | Timeline, not functionality | Not a container |
| "Customer Journey X" | Journey, not ability | May span capabilities |
| "API Endpoint /users" | Implementation detail | Story |
| Signal | Problem |
|---|---|
| Capability name is a verb phrase | Might be a feature or story |
| Capability fits in 1-2 features | Might be too small |
| Capability name includes "and" | Might be multiple capabilities |
| Can't identify what product CAN DO | Needs clarification |
</anti_patterns>
<success_criteria>
Decomposition complete when:
</success_criteria>