plan-feature

Guide for plan mode. This skill defines the orchestration workflow for test-first implementation planning.

Mode Check

This skill requires plan mode. Before doing anything else, check the current mode:

• ExitPlanMode is in the deferred tools list → not in plan mode → stop immediately and tell the user:

  "This skill (/plan-feature) requires plan mode. Enter plan mode first: use /plan or press Shift+Tab to toggle."

• ExitPlanMode is NOT in the deferred tools list (i.e., directly callable) → in plan mode → proceed.

Task Type Check

If the user's request is to investigate or fix a bug rather than implement a new feature, change a specification, or refactor, use ExitPlanMode immediately and guide the user to invoke the /fix-bug skill instead. The rest of this skill applies to feature implementation, spec changes, and refactoring only.

Plan Mode Workflow

Step 1: Initial Understanding

Launch Explore agents to understand the codebase relevant to the task.

TBD items: If the requirements or specifications explicitly contain the text "TBD" for any item, treat that item as non-existent — do not design or implement it. Only ask the user via AskUserQuestion if the TBD item is a prerequisite that cannot be deferred without blocking the overall design.

Step 2: Implementation Design (Plan Agent)

Launch a Plan agent to design the class/method structure. Include the following instruction in the Plan agent prompt:

Design the class/method seams with testability in mind:

• Prefer small, focused public interfaces
• Test through the same seam production code uses. Tests should exercise the same public/internal API that production callers go through. Do not promote a private method or widen visibility merely to reach it from a test — by default, private stays private.
• Sanctioned exception (reduce combinatorial coverage): When a method takes 3 or more parameters — a heuristic for the real trigger, which is that several independent conditions combine so exhaustive coverage cost explodes (this can also happen with fewer parameters that each take many values, and may not apply when the extra parameters don't drive branching) — extract the cohesive sub-logic (a pure computation or decision that depends on only 1–2 of those inputs) into its own unit. Prefer a standalone class or pure function when the logic stands on its own; fall back to an internal method on the same class only when it cannot be cleanly separated from instance state. Give the extracted unit internal (not public) visibility when it need not be reachable outside the assembly — the narrowed visibility is a consequence of the extraction, not the goal.
• Inject dependencies via interfaces so they can be replaced with test doubles
• Avoid hidden static/global state and new calls inside constructors for external dependencies

Naming: If any class or public method name explicitly specified by the user is a poor fit for what the spec describes, propose a more appropriate alternative using AskUserQuestion before finalizing the design. Accept the user's final choice without further challenge.

TBD items: Any item explicitly marked "TBD" in the requirements or spec must be excluded from the design. Skip it silently unless it is structurally required to complete the design (in which case, ask via AskUserQuestion).