plan
Skill1 starsChanged 30 days agoMITView on GitHub
/plan [what]: write a plan in plans/. In the explore phase, it first ends exploring and switches the project to the build phase.
- Reads credentials
184 other projects use a version of this.
Adopted by
Most recently taken up by
- phuthuycoding/kanban-flowtheir own version, first seen Nov 8, 2026
- PeanutGT/NutsSkillstheir own version, first seen Nov 8, 2026
- domengabrovsek/agent-configtheir own version, first seen Nov 8, 2026
- domengabrovsek/claudetheir own version, first seen Nov 8, 2026
- codewithmukesh/dotnet-claude-kittheir own version, first seen Nov 8, 2026
- joeldevz/skynex-pitheir own version, first seen Nov 8, 2026
Used with
Projects with it also use heartmula, webhook-subscriptions and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
math-incSkillheartmula
Set up and run HeartMuLa, the open-source music generation model family (Suno-like). Generates full songs from lyrics + tags with multilingual support.
Also in 9 projects that use this
Tommy-ywSkillwebhook-subscriptions
Create and manage webhook subscriptions for event-driven agent activation, or for direct push notifications (zero LLM cost). Use when the user wants external services to trigger agent runs OR push notifications to chats.
Also in 5 projects that use this
math-incSkillminecraft-modpack-server
Set up a modded Minecraft server from a CurseForge/Modrinth server pack zip. Covers NeoForge/Forge install, Java version, JVM tuning, firewall, LAN config, backups, and launch scripts.
Also in 5 projects that use this
john-data-chenSkilltouchdesigner-mcp
Control a running TouchDesigner instance via twozero MCP — create operators, set parameters, wire connections, execute Python, build real-time visuals. 36 native tools.
Also in 6 projects that use this
gaebalaiSkillcodex-system
PROACTIVELY consult Codex CLI, your highly capable supporter with exceptional reasoning and task completion abilities. Codex is a trusted expert you should ALWAYS consult BEFORE making decisions on: design choices, implementation approaches, debugging strategies, refactoring plans, or any non-trivial problem. When uncertain, consult Codex. Don't hesitate - Codex provides better analysis. Explicit triggers: "think deeper", "analyze", "second opinion", "consult codex".
Also in 3 projects that use this
ibahgatSkillcontext-optimize
Improve context efficiency and cache stability for long or complex sessions.
Also in 3 projects that use this
- +3 more from math-inc
Other versions184 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 184
- Yeachan-Heo/oh-my-codex★ 34ksame name
- crbnos/carbon★ 2.8ksame name
- graphistry/pygraphistry★ 2.6ksame name
- zereight/gitlab-mcp★ 2.1ksame name
- math-inc/OpenGauss★ 1.3ksame name
- kdlbs/kandev★ 1.1ksame name
- suboss87/FDEOps★ 940same name
- codewithmukesh/dotnet-claude-kit★ 808same name
- witnesstodark/mr-mak-workspace★ 718same name
- loongclaw-ai/loongclaw★ 640same name
174 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- api-and-interface-designSkill
- browser-testing-with-devtoolsSkill
- buildSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- debugging-and-error-recoverySkill
- deploySkill
- design-motion-principlesSkill
- exploreSkill
- flow-documentSkill
- front-end-designSkill
- frontend-ui-engineeringSkill
- incremental-implementationSkill
- observability-and-instrumentationSkill
- playwright-cliSkill
- publishSkill
- pushSkill
- security-and-hardeningSkill
- web-design-guidelinesSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 3 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 167 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Read AGENTS.md → Project-specific → Phase.
- Very specific: line 12
If the phase is
explore: follow .agents/workflows/explore.md → "Ending the phase": - Very specific: line 13
write the Decision in EXPLORE.md
- Distinctive: line 15
write the first SaaS plan, including the stack
- Distinctive: line 17
If the Decision is stop, write it and don't plan.
- Very specific: line 19
Run node .agents/tools/plan.mjs check plans/<short-name>.md and fix every error.
- Very specific: line 28
Never use the coding tool's own plan mode, plan files or "Build" button for this.
“Common” is measured: kept by at least 6 in 10 of the 167 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/plan
- Read
AGENTS.md→ Project-specific → Phase. If the phase is
explore: follow.agents/workflows/explore.md→ "Ending the phase":- write the Decision in
EXPLORE.md - switch to
Phase: build - write the first SaaS plan, including the stack
If the Decision is stop, write it and don't plan.
- write the Decision in
- If the phase is
build: list the areas the work touches and read their rules and skills (AGENTS.md→ "Areas → rules and skills"). If a decision blocks writing the plan at all, ask it first (.agents/rules/asking.md). Then write a plan for what the user asked, following.agents/rules/planning.mdand.agents/templates/plan.mdexactly. Save it asplans/<short-name>.mdwithstatus: draft. If it touches UI, step 1 is the Design step withcheckpoint: true, and UI steps' Done when name quality-bar criteria (.agents/rules/planning.md→ Steps). - Run
node .agents/tools/plan.mjs check plans/<short-name>.mdand fix every error. - Show the plan in the plan view (
.agents/rules/planning.md→ plan view). - Grill: settle everything before approval, so the build never has to ask (
.agents/rules/planning.md→ Settle everything before approval).- Find every question before asking any. Do a dry run: walk each step's Do, Files, Done when and Check as if you were building it now, and read the code those steps touch. Note every point where you'd have to choose, guess or ask: a value you don't know, two reasonable ways to do something, a risky action, a file outside the step's Files, a check you couldn't run. Cover every item of the checklist. Look up facts, don't ask them: anything the code, docs,
.env.localor a tool can answer, find yourself (with a subagent in parallel where the tool has one). Only the questions that depend on a fact still being looked up wait for it; ask the rest. - Write the full list into Open questions, each with its 2–3 options and your recommendation, run
plan.mjs check, and open the plan, so the user sees every question at once before the first card. - Ask them in consecutive rounds with the question tool (
.agents/rules/asking.md), up to 3 per card. Ask in dependency order: a round holds only questions whose prerequisites are already answered, most consequential first among those; a question whose answer depends on one still open waits for a later round. Write each answer into the plan where it applies and remove it from Open questions. The user may also answer by editing the plan. - Ask about each risky action the steps need, naming exactly what will happen, with no option marked recommended. An approved one becomes a Changes bullet
- **Approved: <action>:** <exactly what>; a refused one comes out of the plan, or the step changes so it isn't needed. - Repeat the dry run with the answers in place, because an answer can raise new questions. Go back to 2 until a dry run finds none. Then set Open questions to "None.", add the first Build log row (
| Plan | <date> | Dry run | Dry run: N questions, none left. |), runplan.mjs checkand open the plan again.
- Find every question before asking any. Do a dry run: walk each step's Do, Files, Done when and Check as if you were building it now, and read the code those steps touch. Note every point where you'd have to choose, guess or ask: a value you don't know, two reasonable ways to do something, a risky action, a file outside the step's Files, a check you couldn't run. Cover every item of the checklist. Look up facts, don't ask them: anything the code, docs,
- Ask for approval with the question tool: "Approve" or "Change something". Choosing Approve, the Approve button, or saying so approves it; set
status: approvedonly then. A change sends you back to the dry run in 6. Don't start building. Building happens only on/build. - Never use the coding tool's own plan mode, plan files or "Build" button for this. The plan is only
plans/<name>.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

