feature-spec
SolidCreates a complete product feature specification with acceptance criteria, scope, dependencies, and risks. Delegates to the Prometeo (PM) agent.
Install
Quality Score: 94/100
Skill Content
Details
- Author
- davepoon
- Repository
- davepoon/buildwithclaude
- Created
- 10 months ago
- Last Updated
- 4 days ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
implement-feature
Implements a feature from its specification. Reads the spec, designs architecture, writes code and tests. Delegates to the Forja (Dev) agent.
cspec
Create a structured specification with testable invariants for a new feature. Researches current best practices before writing invariants. Adapts format to workflow intensity.
specdd
Spec-driven development orchestrator that turns vague, top-of-mind feature requests into production-grade specifications before any code is written. ALWAYS use this skill whenever the user describes a feature, change, capability, screen, flow, or new component in plain language — even if they don't explicitly ask for a spec. Triggers on phrases like "build me", "make me", "add a feature", "I want to", "help me create", "implement", "let's build", "I need a", "can you make", "create a screen/page/component", or any new-feature request that lacks complete requirements (missing user stories, acceptance criteria, edge cases, error/empty/loading states, accessibility, or non-functional requirements). Interviews the user to fill gaps, applies UX/UI common sense, produces a structured spec + plan + tasks, then implements against the spec. Use this BEFORE writing any code for non-trivial features. Skip only for true one-liners (rename a variable, fix a typo, answer a research question) or work that is purely investig
project-specification
Transforms project briefs into testable specifications with user stories and acceptance criteria. Use after brainstorming, before planning.
spec
Write a feature spec — the "what & why" of a kandev product feature, before coding. Use ONLY for a product-feature surface (user-visible capability the app supports). Do NOT use for bug fixes, incident postmortems, refactors that preserve behavior, or infra-only work — those get ADRs (if a new convention emerged) and/or regression tests, not specs. Use when the user says "let's spec X" or starts a new product feature.