Cm planning

Skill tody-agent/codymaster/.cursor-plugin/skills/cm-planning

Vibe Coding Framework - Full SaaS Development Team from A-Z with Brain, Self Improvement, Auto Development

Install

npx -y skills add tody-agent/codymaster --skill cm-planning

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

You MUST use this before any creative work or multi-step task. Explores intent, requirements, and design before implementation. Then documents the plan before coding.

SKILL.md

3.4 KB, 839 tokens by cl100k_base, as published. Nobody here has run it

Planning — Brainstorm + Write Plans

TL;DR

Use before any feature, behavior change, or 3+ step task
Phase A (Brainstorm): clarify intent → 2-3 options → recommend → scope
Phase B (Write): emit openspec/changes/<name>/{design.md,tasks.md}
Handoff out: .cm/handoff/plan.json (goal, decisions, first 3 tasks)
Next: cm-tdd or cm-execution

When to Use

Creating features, components, or functionality
Modifying behavior; multi-step tasks; user-visible change
Skip only for trivial single-line edits or pure questions

Full Protocol

Phase A: Brainstorm

Intent — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
Options — List 2-3 approaches with pros/cons. Recommend one with reasoning.
Scope — Must-have vs nice-to-have; edges to handle vs explicitly skip.
Design — Data flow, component boundaries, API contracts. UI work → cm-design-system.

Red flags (STOP): code before brainstorm; assuming intent; skipping scope; "it's simple."

Phase B: Write Plan (OpenSpec format)

Write to openspec/changes/<initiative-name>/:

design.md

# Design: [Goal]
## Context & Technical Approach
## Proposed Changes
### [Component/File]
## Verification

tasks.md

# Implementation Checklist
- [ ] 1.1 ...
- [ ] 1.2 ...
- [ ] Verification testing

Plan rules: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.

Step FINAL: Emit Handoff + Update Continuity

Write .cm/handoff/plan.json:

{
  "schema": "plan@1",
  "goal": "...",
  "decisions": ["..."],
  "first_tasks": ["1.1", "1.2", "1.3"],
  "openspec_path": "openspec/changes/<name>/"
}

Update .cm/CONTINUITY.md:

Active Goal → plan goal
Next Actions → first 3 tasks
Current Phase → "planning"
Working Context → key decisions

Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).

Integration

After planning...	Use skill
Complex initiative	`cm-brainstorm-idea` (run BEFORE)
Need isolated workspace	`cm-execution`
Execute the plan	`cm-execution`
Tests first	`cm-tdd`
UI/frontend	`cm-design-system`

Karpathy Discipline — Think Before Coding

Before writing the plan, surface what's uncertain instead of guessing:

State assumptions explicitly. List them in the plan; mark each as "verified" or "needs confirmation".
Multiple interpretations? Present them side-by-side with tradeoffs. Don't pick silently.
Simpler path exists? Say so. Push back on over-scoped requests.
Confused? Stop. Name the confusion. Ask. Cheaper than building the wrong thing.

Self-test: "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.

Anti-Patterns

❌ Coding before plan exists
❌ Skipping handoff JSON (downstream skills lose context)
❌ Vague tasks ("refactor the code")
❌ Hidden assumptions — pick one interpretation without telling the user

The Bottom Line

Think before you build. Document before you code. Emit handoff so the next skill picks up cold.