implementation-planning

Name: implementation-planning
Author: neuromechanist

37stars7forks

How to install implementation-planning?

neuromechanist/research-skills/implementation-planning

$npx -y skills add neuromechanist/research-skills --skill implementation-planning

Installs into the current project.

Summary

Use this skill when the user asks to \"plan this feature\", \"write an implementation plan\", \"design before coding\", \"think through the approach\", \"review this plan\", or before any multi-file change, architectural decision, experiment with a go/no-go outcome, or strategic

Files · 1

View on GitHub

SKILL.md

1	# Implementation Planning
2
3	Plans that a different (or weaker) model could execute without re-deriving
4	your reasoning, with success criteria fixed before any result is seen.
5
6	## Model handoff
7
8	Use the strongest available model for problem framing, macro architecture,
9	irreversible decisions, and plan approval. In Codex this is Sol; in Claude it
10	is Fable when available, otherwise Opus. After the architecture is approved, a
11	bounded phase planner may expand it on the intermediate tier (Codex Terra;
12	Claude Sonnet when no design choice remains). Write the resulting brief so a
13	clear-task worker (Codex Luna or Claude Sonnet) can implement it without
14	reconstructing design intent. See `agent-fanout` for the full routing and
15	escalation policy.
16
17	## Pick the register (by stakes, not size)
18
19	\| Situation \| Register \|
20	\| --- \| --- \|
21	\| Hard to reverse after shipping; touches privacy, auth, what data leaves the device, or public contracts; strategic pivot \| Heavyweight: full plan document, user approval gate before executing (plan mode where available). \|
22	\| Known engineering backlog; the work is clear, there is just a lot of it \| Lightweight: tracked issues carrying the full spec (template below); no separate plan document. \|
23	\| Single ordinary change \| No formal plan; the engineering-loop skill's step order is the plan. \|
24
25	The dividing line is reversibility and blast radius, not effort. A large
26	backlog of clear fixes needs no plan document; a small change to what an
27	external partner receives does.
28
29	## Heavyweight plan: required sections
30
31	```markdown
32	# Plan: <title> (issue #N)
33	## Context
34	[The evidence forcing this work, with numbers. What the previous phase or
35	investigation proved.]
36	## What already exists to reuse (do not rebuild)
37	[Named files/functions. Every plan must check this before proposing new code.]
38	## Approach
39	[The design, and one paragraph on why this and not the leading alternative.]
40	## Files
41	[New and modified, explicit paths.]
42	## Decision gate (set BEFORE looking at results)
43	[Crisp pass/fail: "X ships as default if metric A >= threshold on every
44	case AND metric B does not regress; if it fails, honest conclusion + named
45	fallback. No adoption of a non-passing candidate."]
46	## Prerequisites (user actions)
47	[Only the human can do these: account registrations, credentials, hardware.]
48	## Agent budget
49	[How many subagents this plan will spawn, worst case; see agent-fanout cap.]
50	## Open judgment calls
51	[Every ambiguity you resolved unilaterally, as a flagged list the reviewer
52	can veto. Silence on ambiguity is a defect.]
53	## Verification
54	[How each deliverable is proven: commands, thresholds, who runs them. For a
55	behavior-preserving refactor, the FIRST deliverable is the pin/
56	characterization test captured against the original code, per the
57	engineering-loop skill.]
58	```
59
60	## Lightweight register: the issue IS the plan
61
62	```markdown
63	## Symptom
64	[User-visible behavior, verbatim if reported.]
65	## Root cause
66	[file:line, what is wrong, the fixture/test/commit that proves it.]
67	## Fix
68	[Concrete, scoped change. DECIDED POLICY lines for any foreseeable ambiguity.]
69	Refs: #A, #B.
70	```
71
72	An implementer (human or agent) executes from the issue alone; that is the
73	test of whether it is written well enough.
74
75	For GitHub issue bodies, keep each paragraph on one source line and separate
76	paragraphs with blank lines. Do not apply sentence- or clause-level semantic
77	line breaks inside a GitHub paragraph. Semantic line breaks remain the default
78	for other prose source.
79
80	## Non-negotiable planning rules
81
82	1. Verify load-bearing claims. Before presenting any plan, list the 3-5
83	facts that would break it if wrong, and re-check each one directly against
84	source or live state, even when a trusted subagent supplied them.
85	2. Pre-register gates. Success/failure thresholds are written before the
86	experiment or implementation runs. Re-running with adjusted parameters
87	without disclosing that the original gate failed is prohibited.
88	3. Check sibling documents. Open issues, ADRs, and plan files in the same
89	tracker may carry constraints on your deliverable that your source
90	document does not restate. Surface contradictions before code starts.
91	4. Reuse before rebuild. The "already exists" section is mandatory;
92	check the codebase and past research before proposing new modules.
93	5. Separate decisions from details. Batch every decision that needs the
94	user (hard to reverse, quoted to third parties, spends real money or
95	days of compute) into ONE structured question with 2-4 labeled options,
96	o

People who liked this also viewed

6 picks

Type

implementation-planning

37stars7forks

View on GitHub

How to install implementation-planning?

neuromechanist/research-skills/implementation-planning

$npx -y skills add neuromechanist/research-skills --skill implementation-planning

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Implementation Planning
2
3	Plans that a different (or weaker) model could execute without re-deriving
4	your reasoning, with success criteria fixed before any result is seen.
5
6	## Model handoff
7
8	Use the strongest available model for problem framing, macro architecture,
9	irreversible decisions, and plan approval. In Codex this is Sol; in Claude it
10	is Fable when available, otherwise Opus. After the architecture is approved, a
11	bounded phase planner may expand it on the intermediate tier (Codex Terra;
12	Claude Sonnet when no design choice remains). Write the resulting brief so a
13	clear-task worker (Codex Luna or Claude Sonnet) can implement it without
14	reconstructing design intent. See `agent-fanout` for the full routing and
15	escalation policy.
16
17	## Pick the register (by stakes, not size)
18
19	\| Situation \| Register \|
20	\| --- \| --- \|
21	\| Hard to reverse after shipping; touches privacy, auth, what data leaves the device, or public contracts; strategic pivot \| Heavyweight: full plan document, user approval gate before executing (plan mode where available). \|
22	\| Known engineering backlog; the work is clear, there is just a lot of it \| Lightweight: tracked issues carrying the full spec (template below); no separate plan document. \|
23	\| Single ordinary change \| No formal plan; the engineering-loop skill's step order is the plan. \|
24
25	The dividing line is reversibility and blast radius, not effort. A large
26	backlog of clear fixes needs no plan document; a small change to what an
27	external partner receives does.
28
29	## Heavyweight plan: required sections
30
31	```markdown
32	# Plan: <title> (issue #N)
33	## Context
34	[The evidence forcing this work, with numbers. What the previous phase or
35	investigation proved.]
36	## What already exists to reuse (do not rebuild)
37	[Named files/functions. Every plan must check this before proposing new code.]
38	## Approach
39	[The design, and one paragraph on why this and not the leading alternative.]
40	## Files
41	[New and modified, explicit paths.]
42	## Decision gate (set BEFORE looking at results)
43	[Crisp pass/fail: "X ships as default if metric A >= threshold on every
44	case AND metric B does not regress; if it fails, honest conclusion + named
45	fallback. No adoption of a non-passing candidate."]
46	## Prerequisites (user actions)
47	[Only the human can do these: account registrations, credentials, hardware.]
48	## Agent budget
49	[How many subagents this plan will spawn, worst case; see agent-fanout cap.]
50	## Open judgment calls
51	[Every ambiguity you resolved unilaterally, as a flagged list the reviewer
52	can veto. Silence on ambiguity is a defect.]
53	## Verification
54	[How each deliverable is proven: commands, thresholds, who runs them. For a
55	behavior-preserving refactor, the FIRST deliverable is the pin/
56	characterization test captured against the original code, per the
57	engineering-loop skill.]
58	```
59
60	## Lightweight register: the issue IS the plan
61
62	```markdown
63	## Symptom
64	[User-visible behavior, verbatim if reported.]
65	## Root cause
66	[file:line, what is wrong, the fixture/test/commit that proves it.]
67	## Fix
68	[Concrete, scoped change. DECIDED POLICY lines for any foreseeable ambiguity.]
69	Refs: #A, #B.
70	```
71
72	An implementer (human or agent) executes from the issue alone; that is the
73	test of whether it is written well enough.
74
75	For GitHub issue bodies, keep each paragraph on one source line and separate
76	paragraphs with blank lines. Do not apply sentence- or clause-level semantic
77	line breaks inside a GitHub paragraph. Semantic line breaks remain the default
78	for other prose source.
79
80	## Non-negotiable planning rules
81
82	1. Verify load-bearing claims. Before presenting any plan, list the 3-5
83	facts that would break it if wrong, and re-check each one directly against
84	source or live state, even when a trusted subagent supplied them.
85	2. Pre-register gates. Success/failure thresholds are written before the
86	experiment or implementation runs. Re-running with adjusted parameters
87	without disclosing that the original gate failed is prohibited.
88	3. Check sibling documents. Open issues, ADRs, and plan files in the same
89	tracker may carry constraints on your deliverable that your source
90	document does not restate. Surface contradictions before code starts.
91	4. Reuse before rebuild. The "already exists" section is mandatory;
92	check the codebase and past research before proposing new modules.
93	5. Separate decisions from details. Batch every decision that needs the
94	user (hard to reverse, quoted to third parties, spends real money or
95	days of compute) into ONE structured question with 2-4 labeled options,
96	o

People who liked this also viewed

6 picks

Type