plan-featurelisted

Plan a feature before writing any code. Use this skill at the START of non-trivial feature work — when the user says they want to "add", "build", "implement", "create", "develop", or "ship" a feature, endpoint, component, page, service, or capability. Especially trigger when the user's prompt is short or under-specified ("add a dashboard", "build an auth flow", "let's do user activity reports") — those need planning, not direct execution. The skill walks through requirements clarification, codebase exploration, sketches a Mermaid architecture/flow diagram of the proposed design, and produces a plan.md document the user can hand off to a fresh AI session for execution. Skip only when the change is genuinely trivial (typo fixes, single-line tweaks, renames). When in doubt, plan.
appleboy/skills · ★ 0 · AI & Automation · score 60

Install: claude install-skill appleboy/skills

# plan-feature Most failed AI-coding sessions don't fail because the model is incapable. They fail because the human didn't give it enough context. This skill turns the user into Claude's product manager for ~15 minutes before any code gets written, dramatically increasing the success rate of the actual implementation. The output is a `plan.md` file that captures everything a competent engineer would need to ship the feature without ambiguity — including a diagram of the proposed design, because an implementer grasps the intended shape far faster from a picture than from a prose description. ## When to use Use whenever the user asks to build something non-trivial. Triggers include: - "Add a feature for X" - "Build / implement / create / ship X" - "I want to add X to the app" - "Let's do X" - Any prompt that names a feature without giving a file path Do not use for: typo fixes, single-line config changes, simple renames, or when the user has already provided a complete spec. ## The eight-step workflow Follow these in order. Stop at the user-approval step before drafting code. ### Step 1 — Clarify the goal Ask the user, in 1-3 questions: - Who is the user / consumer of this feature? (internal team, end user, system) - What does "done" look like? (one or two sentences) - Are there constraints already known? (deadlines, tech stack, must-not-touch areas) Do not move on until you have a one-paragraph problem statement that the user has confirmed. ### Step 2 — Explore t