plan-feature
SolidPre-implementation planning — interview to clarify scope, then compile into a PRD. Triggers "help me figure out", "vague scope", "define requirements" (discovery phase); "PRD", "requirements document", "product spec", "feature spec", "write requirements" (PRD phase).
Install
Quality Score: 87/100
Skill Content
Details
- Author
- darkroomengineering
- Repository
- darkroomengineering/cc-settings
- Created
- 8 months ago
- Last Updated
- today
- Language
- TypeScript
- License
- MIT
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
plan-feature
Product-owner + architect planning agent: take a rough brief (a few paragraphs on what to build), study the actual codebase first, frame the feature by what the USER achieves, challenge the brief and ask only the clarifying questions that genuinely block planning (with a recommendation each), audit every proposed UI element against "less is more", verify the design is buildable against real code (file:line), then produce a phased, executable plan — summary of what changes, summary of how, then small technically-elaborate phases a coding agent can pick up and run without extra context. The plan is saved as a markdown file for handoff. One deliberate pause: the clarifying-questions gate. Everything else runs end-to-end. Use when: planning a new feature, "plan this", "create a plan for", "how should we build X", turning a product idea into an implementation plan, before starting any multi-phase build.
feature-planner
Upstream feature planning — requirement clarification, constraint discovery, design outline, vertical-slice task breakdown ordered by risk. Hands off to grill-with-docs and tdd. Use when starting new feature work from a vague request and no plan exists yet; if a plan or design already exists, use grill-with-docs to stress-test it instead.
plan-a-feature
Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation. Produces a feature specification focused on system behaviors, not implementation detail. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features — use project-documentation. Does not design the contract for an interface — use design-an-api. Does not research open-ended options before there is a feature to specify — use research.