From role-pm
Translate PRD intent or roadmap asks into an implementation-ready capability doc that exposes constraints, interfaces, and unresolved decisions. Use after a spec is directionally approved, before engineering starts. Complements spec-draft at a different altitude.
npx claudepluginhub sitloboi2012/team-marketplace --plugin role-pmThis skill uses the workspace's default tool permissions.
A spec answers "what should we build?" — this answers **"what exactly must be true before implementation starts?"** It's the layer between PRD and engineering execution, and it's where hidden assumptions surface.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes competition with Porter's Five Forces, Blue Ocean Strategy, and positioning maps to identify differentiation opportunities and market positioning for startups and pitches.
Share bugs, ideas, or general feedback.
A spec answers "what should we build?" — this answers "what exactly must be true before implementation starts?" It's the layer between PRD and engineering execution, and it's where hidden assumptions surface.
Use this after /role-pm:spec-draft is directionally approved, before engineering invests real hours. If used in the other order, engineering discovers the blockers at implementation time, which is the most expensive place to find them.
One precise statement of the capability. No marketing language, no aspiration — just what this is.
Good: "The capability lets an authenticated user upload a PDF up to 50 MB, have it processed asynchronously, and download a structured JSON extraction within 10 minutes."
Bad: "An AI-powered document intelligence feature that empowers users to unlock insights from their documents."
Surface every constraint that must hold before or during implementation. Each constraint either has a documented resolution or becomes an open question the spec owner must resolve before engineering starts.
Categories to check:
For each constraint, write: what it is → why → how it must be satisfied. If the "how" is unknown, it becomes an open question.
The interface engineering will build against. Not implementation — contract.
Include:
This section is the answer to "what do we need to agree on before writing code?"
Hand off notes:
/team-core:task-breakdown or /role-pgm:project-planner depending on size# Capability: <name>
**Spec link:** <Notion PRD>
**Owner:** <PM>
**Status:** Ready for engineering review | Open questions blocking
## Capability statement (one sentence)
<precise restatement>
## Constraints
### Business rules
- <rule> — why — how satisfied
- ...
### Scope boundaries (non-goals)
- This does NOT <X>
- This does NOT <Y>
### Data
- <entity> — owner — lifecycle (created → ... → archived)
- ...
### Security
- <constraint> — how satisfied
- ...
### Performance SLOs
- <SLO> — target — measured how
### Dependencies
- <dependency> — owner — risk
## Implementation contract
### Inputs
- <input> — from — validation rules
### Outputs
- <output> — shape — guarantees
### Error modes
- <error> — trigger — caller action
### Invariants
- <invariant that must always hold>
### State machine (if applicable)
<states and transitions>
## Non-goals (reconfirmed)
- <non-goal>
## Open questions blocking implementation
- [ ] <question> — owner: <person> — needed by: <date>
## Next step
<task-breakdown | project-planner | revise spec>
/role-pm:spec-draft. This skill translates a spec, doesn't replace it./team-core:task-breakdown./role-pm:product-lens diagnostic or /role-ceo:office-hours.Methodology inspired by the Affaan M "product-capability" skill.