/make

description: Create structured implementation plan in docs/plans/
argument-hint: describe the feature or task to plan
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion, Task, EnterPlanMode, TaskCreate, TaskUpdate, TaskList

Implementation Plan Creation

create an implementation plan in `docs/plans/yyyymmdd-<task-name>.md` with interactive context gathering.

custom rules loading

before starting, run this command via Bash tool to check for user-provided custom rules:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/resolve-rules.sh planning-rules.md ${CLAUDE_PLUGIN_DATA}

if the output is non-empty, treat it as additional instructions that supplement (not replace) the built-in rules below. apply custom rules alongside the command's own instructions throughout the planning process — they may influence plan structure, testing approach, naming conventions, or other aspects of plan creation. custom rules content is guidance for creating the plan, not content to embed verbatim in the output plan file.

rules management

when the user asks to add, show, or clear custom planning rules, handle these operations:

• **show rules**: run `bash ${CLAUDE_PLUGIN_ROOT}/scripts/resolve-rules.sh planning-rules.md ${CLAUDE_PLUGIN_DATA}` and display the output. if the output is empty, tell the user no custom rules are configured at either level. otherwise, to determine the source, check if `.claude/planning-rules.md` exists and is non-empty (project-level) — if not, the output came from user-level. tell the user which level it came from.
• **add/update project rules**: write content to `.claude/planning-rules.md` in the current working directory.
• **add/update user rules**: first check if `$CLAUDE_PLUGIN_DATA` is set (run `echo "$CLAUDE_PLUGIN_DATA"`). if empty, tell the user that user-level rules require the plugin to be installed from the marketplace and offer project-level instead. if set, write content to `$CLAUDE_PLUGIN_DATA/planning-rules.md`.
• **clear project rules**: delete `.claude/planning-rules.md`.
• **clear user rules**: if `$CLAUDE_PLUGIN_DATA` is set, delete `$CLAUDE_PLUGIN_DATA/planning-rules.md`. if not set, tell the user user-level rules are not available.

project-level rules (`.claude/planning-rules.md`) take precedence over user-level rules (`$CLAUDE_PLUGIN_DATA/planning-rules.md`). when both non-empty files exist, only project-level rules are loaded. empty files are treated as absent and fall through to the next level. see `${CLAUDE_PLUGIN_ROOT}/references/custom-rules.md` for full documentation on the rules mechanism.

**CRITICAL: this skill must NEVER modify its own files (commands, skills, agents, scripts, references, hooks, plugin.json). the ONLY files it may create or modify for rules management are `.claude/planning-rules.md` and `$CLAUDE_PLUGIN_DATA/planning-rules.md`. if the user asks to change the skill's behavior, create a plan for it — do not edit skill files directly.**

step 0: parse intent and gather context

before asking questions, understand what the user is working on:

1. **parse user's command arguments** to identify intent:

• "add feature Z" / "implement W" → feature development
• "fix bug" / "debug issue" → bug fix plan
• "refactor X" / "improve Y" → refactoring plan
• "migrate to Z" / "upgrade W" → migration plan
• generic request → explore current work

2. **gather relevant context quickly** — use direct tool calls (Read, Glob, Grep), NOT an Explore agent. keep discovery under 30 seconds:

**for feature development:**

• glob for files matching the feature area (e.g., `**/*auth*`, `**/*cache*`)
• read 1-3 most relevant files to understand existing patterns
• check project structure with a quick `ls` of key directories

**for bug fixing:**

• grep for error messages or function names mentioned in the request
• read the specific file(s) involved
• check `git log --oneline -5` for recent changes

**for refactoring/migration:**

• glob for files matching the area being refactored
• read 2-3 key files to understand current structure
• grep for imports/references to identify dependencies

**for generic/unclear requests:**

• check `git status` and `git log --oneline -5`
• read README.md or CLAUDE.md for project overview
• `ls` the top-level directory structure

**CRITICAL: do NOT launch an Explore agent or read more than 5 files in this step. the goal is a quick scan, not exhaustive analysis. if more context is needed, ask the user in step 1.**

3. **synthesize findings** into a brief context summary (3-5 bullet points):

• what the project is and primary language/framework
• which files/areas are relevant to the request
• key patterns or conventions observed

step 1: present context and ask focused questions

show the discovered context, then ask questions **one at a time** using the AskUserQuestion tool:

"based on your request, i found: [context summary]"

**ask questions one at a time (do not overwhelm with multiple questions):**

1. **plan purpose**: use AskUserQuestion - "what is the main goal?"

• provide multiple choice with suggested answer based on discovered intent
• wait for response before next question

2. **scope**: use AskUserQuestion - "which components/files are involved?"

• provide multiple choice with suggested discovered files/areas
• wait for response before next question

3. **constraints**: use AskUserQuestion - "any specific requirements or limitations?"

• can be open-ended if constraints vary widely
• wait for response before next question

4. **testing approach**: use AskUserQuestion - "do you prefer TDD or regular approach?"

• options: "TDD (tests first)" and "Regular (code first, then tests)"
• store preference for reference during implementation
• wait for response before next question

5. **plan title**: use AskUserQuestion - "short descriptive title?"

• provide suggested name based on intent