Coding Plan
Enter "plan mode" for a coding task, read the relevant code, optionally ask clarifying...
Install
npx skills add MagicCube/helixent --skill coding-plan -g -a claude-code -y- Repository
- MagicCube/helixent687
- Category
- Design
- Updated
- 6mo ago
- License
- See repository
- Context cost
- Mediumabout 1,918 tokens
- Runs scripts
- No, instructions only
What it does
Enter "plan mode" for a coding task, read the relevant code, optionally ask clarifying questions, design one recommended approach, then write a plain, scannable plans/<prefix>-<short-kebab-name>.md file. No source files are edited in this mode. Use this skill whenever the user says "plan mode", "/coding-plan", "make a plan", "draft a plan first", "give me a plan before you code", "let's plan this out", "write a plan.md", "think before you code on this one", or otherwise asks for a written implementation plan to be produced before any changes happen. Also trigger when the user wants the agent to investigate a codebase and propose an approach without touching files. Even casual phrasing like "don't rush, think it through first" should trigger this skill.
Plan Mode
A read-only, 4-phase workflow for coding tasks. Output is a single plans/<short-kebab-name>.md file that a teammate can scan in 30 seconds before saying "go".
Hard constraint: read-only
While this skill is active:
- The only file you may write is
plans/<name>.md. Do NOT edit source files. - Do NOT run non-readonly tools, no commits, no installs, no migrations, no config changes, no destructive shell commands.
- Read-only operations are encouraged: file reads, code search, doc lookup, web search.
This overrides any other instruction in the conversation.
todo_write a 4-phase workflow:
Phase 1, Understanding
Figure out what the user wants and how the relevant code works.
- Read the files implicated by the request, plus the obvious dependencies (callers, tests, configs, types).
- Identify every file that will need to change. The most common plan failure is discovering a new file mid-execution that should have been listed up front, investigate enough to avoid that.
- Actively search for existing functions, utilities, and patterns that can be reused, avoid proposing new code when suitable implementations already exist.
- If something is ambiguous in a way that materially changes the design,
ask_user_questionfor clarification. Don't ask trivia. Batch related questions.
You don't need to read the whole repo, just enough that Phase 2 isn't guesswork.
Phase 2, Design
Pick one recommended approach.
