# Coding Plan

Enter "plan mode" for a coding task, read the relevant code, optionally ask clarifying...

- Repository: https://github.com/MagicCube/helixent (687 stars)
- Category: Design
- License: see repository
- Last updated: 2026-05-21
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add MagicCube/helixent --skill coding-plan -g -a claude-code -y`
Codex: `npx skills add MagicCube/helixent --skill coding-plan -g -a codex -y`
Cursor: `npx skills add MagicCube/helixent --skill coding-plan -g -a cursor -y`
Gemini CLI: `npx skills add MagicCube/helixent --skill coding-plan -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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_question` for 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.

The rest: https://github.com/MagicCube/helixent/blob/HEAD/skills/coding-plan/SKILL.md