plan-feature

Solid

Pre-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).

Data & Documents 44 stars 3 forks Updated today MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%
55
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Plan Feature Two-phase pre-implementation planning: clarify requirements via interview, then compile a complete PRD. ## Phase 1: Discovery Help clarify requirements and scope through structured questioning. ### Interview Framework The interview is a fog-of-war walk across four quadrants of the unknown. Open by listing the **known knowns** (what the user has already decided), then work the questions below to surface **known unknowns** (open questions they're aware of), **unknown knowns** (constraints they hold but haven't said — the questions in 2–4 exist to shake these loose), and close by hunting **unknown unknowns** ("what would surprise us mid-build? what reference implementation should we read first?"). A discovery that ends with all four quadrants visited produces a PRD that doesn't get re-planned in week two. ### Goal Quality Bar (gate before interviewing) Before opening the interview questions below, try to state the goal in one line that answers five things: - What's true when this is done? - What evidence shows it — a command, a test, a metric, a reviewed artifact? - What threshold counts as success — pass/fail, or a number? - What's explicitly out of scope, where that would matter? - What's the stop condition — the point where you ask the user instead of guessing? If a clean one-liner falls out, skip straight to Phase 2's clarifying questions — the interview below exists for when it doesn't. Reject pure activity goals — "make progress," "keep investigati...

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

AI & Automation Listed

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.

0 Updated 1 months ago
ohyesgocool
AI & Automation Listed

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.

2 Updated 1 months ago
ralvarezdev
Code & Development Featured

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.

263 Updated today
testdouble