cm-planning

Name: cm-planning
Author: tody-agent

47stars23forks

How to install cm-planning?

tody-agent/codymaster/cm-planning

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

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Planning — Brainstorm + Write Plans
2
3	## TL;DR
4	- Use before any feature, behavior change, or 3+ step task
5	- Phase A (Brainstorm): clarify intent → 2-3 options → recommend → scope
6	- Phase B (Write): emit `openspec/changes/<name>/{design.md,tasks.md}`
7	- Handoff out: `.cm/handoff/plan.json` (goal, decisions, first 3 tasks)
8	- Next: `cm-tdd` or `cm-execution`
9
10	## When to Use
11	- Creating features, components, or functionality
12	- Modifying behavior; multi-step tasks; user-visible change
13	- Skip only for trivial single-line edits or pure questions
14
15	## Full Protocol
16
17	### Phase A: Brainstorm
18
19	1. Intent — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
20	2. Options — List 2-3 approaches with pros/cons. Recommend one with reasoning.
21	3. Scope — Must-have vs nice-to-have; edges to handle vs explicitly skip.
22	4. Design — Data flow, component boundaries, API contracts. UI work → `cm-ui-preview`.
23
24	Red flags (STOP): code before brainstorm; assuming intent; skipping scope; "it's simple."
25
26	### Phase B: Write Plan (OpenSpec format)
27
28	Write to `openspec/changes/<initiative-name>/`:
29
30	`design.md`
31	```markdown
32	# Design: [Goal]
33	## Context & Technical Approach
34	## Proposed Changes
35	### [Component/File]
36	## Verification
37	```
38
39	`tasks.md`
40	```markdown
41	# Implementation Checklist
42	- [ ] 1.1 ...
43	- [ ] 1.2 ...
44	- [ ] Verification testing
45	```
46
47	Plan rules: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.
48
49	### Step FINAL: Emit Handoff + Update Continuity
50
51	Write `.cm/handoff/plan.json`:
52	```json
53	{
54	"schema": "plan@1",
55	"goal": "...",
56	"decisions": ["..."],
57	"first_tasks": ["1.1", "1.2", "1.3"],
58	"openspec_path": "openspec/changes/<name>/"
59	}
60	```
61
62	Update `.cm/CONTINUITY.md`:
63	- Active Goal → plan goal
64	- Next Actions → first 3 tasks
65	- Current Phase → "planning"
66	- Working Context → key decisions
67
68	> Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).
69
70	## Integration
71
72	\| After planning... \| Use skill \|
73	\|---\|---\|
74	\| Complex initiative \| `cm-brainstorm-idea` (run BEFORE) \|
75	\| Need isolated workspace \| `cm-git-worktrees` \|
76	\| Execute the plan \| `cm-execution` \|
77	\| Tests first \| `cm-tdd` \|
78	\| UI/frontend \| `cm-ui-preview` \|
79
80	## Karpathy Discipline — Think Before Coding
81
82	Before writing the plan, surface what's uncertain instead of guessing:
83	- State assumptions explicitly. List them in the plan; mark each as "verified" or "needs confirmation".
84	- Multiple interpretations? Present them side-by-side with tradeoffs. Don't pick silently.
85	- Simpler path exists? Say so. Push back on over-scoped requests.
86	- Confused? Stop. Name the confusion. Ask. Cheaper than building the wrong thing.
87
88	Self-test: "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.
89
90	## Anti-Patterns
91	- ❌ Coding before plan exists
92	- ❌ Skipping handoff JSON (downstream skills lose context)
93	- ❌ Vague tasks ("refactor the code")
94	- ❌ Hidden assumptions — pick one interpretation without telling the user
95
96	## The Bottom Line
97	Think before you build. Document before you code. Emit handoff so the next skill picks up cold.

People who liked this also viewed

6 picks

Type

cm-planning

47stars23forks

View on GitHub

How to install cm-planning?

tody-agent/codymaster/cm-planning

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

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Planning — Brainstorm + Write Plans
2
3	## TL;DR
4	- Use before any feature, behavior change, or 3+ step task
5	- Phase A (Brainstorm): clarify intent → 2-3 options → recommend → scope
6	- Phase B (Write): emit `openspec/changes/<name>/{design.md,tasks.md}`
7	- Handoff out: `.cm/handoff/plan.json` (goal, decisions, first 3 tasks)
8	- Next: `cm-tdd` or `cm-execution`
9
10	## When to Use
11	- Creating features, components, or functionality
12	- Modifying behavior; multi-step tasks; user-visible change
13	- Skip only for trivial single-line edits or pure questions
14
15	## Full Protocol
16
17	### Phase A: Brainstorm
18
19	1. Intent — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
20	2. Options — List 2-3 approaches with pros/cons. Recommend one with reasoning.
21	3. Scope — Must-have vs nice-to-have; edges to handle vs explicitly skip.
22	4. Design — Data flow, component boundaries, API contracts. UI work → `cm-ui-preview`.
23
24	Red flags (STOP): code before brainstorm; assuming intent; skipping scope; "it's simple."
25
26	### Phase B: Write Plan (OpenSpec format)
27
28	Write to `openspec/changes/<initiative-name>/`:
29
30	`design.md`
31	```markdown
32	# Design: [Goal]
33	## Context & Technical Approach
34	## Proposed Changes
35	### [Component/File]
36	## Verification
37	```
38
39	`tasks.md`
40	```markdown
41	# Implementation Checklist
42	- [ ] 1.1 ...
43	- [ ] 1.2 ...
44	- [ ] Verification testing
45	```
46
47	Plan rules: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.
48
49	### Step FINAL: Emit Handoff + Update Continuity
50
51	Write `.cm/handoff/plan.json`:
52	```json
53	{
54	"schema": "plan@1",
55	"goal": "...",
56	"decisions": ["..."],
57	"first_tasks": ["1.1", "1.2", "1.3"],
58	"openspec_path": "openspec/changes/<name>/"
59	}
60	```
61
62	Update `.cm/CONTINUITY.md`:
63	- Active Goal → plan goal
64	- Next Actions → first 3 tasks
65	- Current Phase → "planning"
66	- Working Context → key decisions
67
68	> Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).
69
70	## Integration
71
72	\| After planning... \| Use skill \|
73	\|---\|---\|
74	\| Complex initiative \| `cm-brainstorm-idea` (run BEFORE) \|
75	\| Need isolated workspace \| `cm-git-worktrees` \|
76	\| Execute the plan \| `cm-execution` \|
77	\| Tests first \| `cm-tdd` \|
78	\| UI/frontend \| `cm-ui-preview` \|
79
80	## Karpathy Discipline — Think Before Coding
81
82	Before writing the plan, surface what's uncertain instead of guessing:
83	- State assumptions explicitly. List them in the plan; mark each as "verified" or "needs confirmation".
84	- Multiple interpretations? Present them side-by-side with tradeoffs. Don't pick silently.
85	- Simpler path exists? Say so. Push back on over-scoped requests.
86	- Confused? Stop. Name the confusion. Ask. Cheaper than building the wrong thing.
87
88	Self-test: "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.
89
90	## Anti-Patterns
91	- ❌ Coding before plan exists
92	- ❌ Skipping handoff JSON (downstream skills lose context)
93	- ❌ Vague tasks ("refactor the code")
94	- ❌ Hidden assumptions — pick one interpretation without telling the user
95
96	## The Bottom Line
97	Think before you build. Document before you code. Emit handoff so the next skill picks up cold.

People who liked this also viewed

6 picks

Type