brain-jam-plan

Name: brain-jam-plan
Author: elb-pr

126stars7forks

How to install brain-jam-plan?

elb-pr/claudikins-kernel/brain-jam-plan

$npx -y skills add elb-pr/claudikins-kernel --skill brain-jam-plan

Installs into the current project.

Summary

Use when running claudikins-kernel:outline, brainstorming implementation approaches, gathering requirements iteratively, structuring complex technical plans, or facing analysis paralysis with too many options — provides iterative human-in-the-loop planning with explicit checkpoin

Files · 1

View on GitHub

SKILL.md

1	# Brain-Jam Planning Methodology
2
3	## Overview
4
5	Planning is an iterative conversation, not a production line. The human stays in the loop at every phase.
6
7	> "Go back and forth with Claude until I like its plan. A good plan is really important." — Boris
8
9	Core principle: Understand before solving. Ask before assuming. Recommend but let user decide.
10
11	## Trigger Symptoms
12
13	Use this skill when:
14
15	- Running the `claudikins-kernel:outline` command
16	- Requirements are unclear or keep changing
17	- Multiple valid approaches exist and you can't choose
18	- User wants involvement in decisions (not just receive a plan)
19	- Previous plans failed due to missed requirements
20	- Scope creep is a concern
21	- You're tempted to just start coding without a plan
22
23	## The Brain-Jam Process
24
25	### Phase 1: Requirements Gathering
26
27	One question at a time. Wait for the answer.
28
29	Key questions to answer:
30
31	1. What problem are we solving?
32	2. What does success look like?
33	3. What constraints exist?
34	4. What's explicitly OUT of scope?
35
36	Use `AskUserQuestion` with specific options — never open-ended unless necessary.
37
38	### Phase 2: Context Building
39
40	Before proposing solutions, understand the landscape:
41
42	- What exists already in the codebase?
43	- What patterns should we follow?
44	- What dependencies apply?
45	- What has been tried before?
46
47	### Phase 3: Approach Generation
48
49	Generate 2-3 distinct approaches. Each must include:
50
51	\| Element \| Purpose \|
52	\| ------- \| --------------------- \|
53	\| Summary \| 1-2 sentence overview \|
54	\| Pros \| Clear benefits \|
55	\| Cons \| Honest trade-offs \|
56	\| Effort \| low / medium / high \|
57	\| Risk \| low / medium / high \|
58
59	Always recommend one with reasoning. See [approach-template.md](references/approach-template.md).
60
61	### Phase 4: Section-by-Section Drafting
62
63	Draft one section at a time. Get approval before moving on.
64
65	Never batch approvals — each checkpoint is a chance to course-correct.
66
67	## Non-Negotiables
68
69	These rules have no exceptions:
70
71	One question at a time.
72
73	- Not "let me ask a few things"
74	- Not "quick questions"
75	- One question. Wait. Process answer. Next question.
76
77	Always present 2-3 approaches.
78
79	- Not "here's what I recommend"
80	- Not "the obvious choice is..."
81	- Present options. Recommend one. User decides.
82
83	Checkpoint before proceeding.
84
85	- Not "I'll assume that's fine"
86	- Not "continuing unless you object"
87	- Explicit approval. "Does this look right?" Wait for yes.
88
89	Never fabricate research.
90
91	- Not "based on my understanding"
92	- Not "typically in codebases like this"
93	- If you don't know, research or ask. Don't invent.
94
95	## Plan Quality Criteria
96
97	A good plan has:
98
99	- [ ] Clear problem statement
100	- [ ] Explicit scope boundaries (IN and OUT)
101	- [ ] Measurable success criteria
102	- [ ] Task breakdown with dependencies
103	- [ ] Risk identification and mitigations
104	- [ ] Verification checklist
105
106	See [plan-checklist.md](references/plan-checklist.md) for full verification.
107
108	## Output Format
109
110	Plans must include machine-readable task markers for `claudikins-kernel:execute` compatibility:
111
112	```markdown
113	<!-- EXECUTION_TASKS_START -->
114
115	\| # \| Task \| Files \| Deps \| Batch \|
116	\| --- \| ------------- \| -------------------- \| ---- \| ----- \|
117	\| 1 \| Create schema \| prisma/schema.prisma \| - \| 1 \|
118	\| 2 \| Add service \| src/services/user.ts \| 1 \| 1 \|
119
120	<!-- EXECUTION_TASKS_END -->
121	```
122
123	See [plan-format.md](references/plan-format.md) for complete structure.
124
125	## Anti-Patterns
126
127	Don't do these:
128
129	- Batching multiple questions together
130	- Proposing solutions before understanding requirements
131	- Presenting only one approach
132	- Skipping the verification checklist
133	- Continuing without explicit approval at checkpoints
134	- Fabricating research findings when data is sparse
135
136	## Rationalizations to Resist
137
138	Agents under pressure find excuses. These are all violations:
139
140	\| Excuse \| Reality \|
141	\| ----------------------------------------------------- \| ------------------------------------------------------------- \|
142	\| "I'll batch questions to save time" \| Batching causes missed requirements. One at a time. \|
143	\| "User knows what they want, skip brain-jam" \| Assumptions cause rework. Gather requirements explicitly. \|
144	\| "I'll propos

People who liked this also viewed

6 picks

Type

brain-jam-plan

126stars7forks

View on GitHub

How to install brain-jam-plan?

elb-pr/claudikins-kernel/brain-jam-plan

$npx -y skills add elb-pr/claudikins-kernel --skill brain-jam-plan

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Brain-Jam Planning Methodology
2
3	## Overview
4
5	Planning is an iterative conversation, not a production line. The human stays in the loop at every phase.
6
7	> "Go back and forth with Claude until I like its plan. A good plan is really important." — Boris
8
9	Core principle: Understand before solving. Ask before assuming. Recommend but let user decide.
10
11	## Trigger Symptoms
12
13	Use this skill when:
14
15	- Running the `claudikins-kernel:outline` command
16	- Requirements are unclear or keep changing
17	- Multiple valid approaches exist and you can't choose
18	- User wants involvement in decisions (not just receive a plan)
19	- Previous plans failed due to missed requirements
20	- Scope creep is a concern
21	- You're tempted to just start coding without a plan
22
23	## The Brain-Jam Process
24
25	### Phase 1: Requirements Gathering
26
27	One question at a time. Wait for the answer.
28
29	Key questions to answer:
30
31	1. What problem are we solving?
32	2. What does success look like?
33	3. What constraints exist?
34	4. What's explicitly OUT of scope?
35
36	Use `AskUserQuestion` with specific options — never open-ended unless necessary.
37
38	### Phase 2: Context Building
39
40	Before proposing solutions, understand the landscape:
41
42	- What exists already in the codebase?
43	- What patterns should we follow?
44	- What dependencies apply?
45	- What has been tried before?
46
47	### Phase 3: Approach Generation
48
49	Generate 2-3 distinct approaches. Each must include:
50
51	\| Element \| Purpose \|
52	\| ------- \| --------------------- \|
53	\| Summary \| 1-2 sentence overview \|
54	\| Pros \| Clear benefits \|
55	\| Cons \| Honest trade-offs \|
56	\| Effort \| low / medium / high \|
57	\| Risk \| low / medium / high \|
58
59	Always recommend one with reasoning. See [approach-template.md](references/approach-template.md).
60
61	### Phase 4: Section-by-Section Drafting
62
63	Draft one section at a time. Get approval before moving on.
64
65	Never batch approvals — each checkpoint is a chance to course-correct.
66
67	## Non-Negotiables
68
69	These rules have no exceptions:
70
71	One question at a time.
72
73	- Not "let me ask a few things"
74	- Not "quick questions"
75	- One question. Wait. Process answer. Next question.
76
77	Always present 2-3 approaches.
78
79	- Not "here's what I recommend"
80	- Not "the obvious choice is..."
81	- Present options. Recommend one. User decides.
82
83	Checkpoint before proceeding.
84
85	- Not "I'll assume that's fine"
86	- Not "continuing unless you object"
87	- Explicit approval. "Does this look right?" Wait for yes.
88
89	Never fabricate research.
90
91	- Not "based on my understanding"
92	- Not "typically in codebases like this"
93	- If you don't know, research or ask. Don't invent.
94
95	## Plan Quality Criteria
96
97	A good plan has:
98
99	- [ ] Clear problem statement
100	- [ ] Explicit scope boundaries (IN and OUT)
101	- [ ] Measurable success criteria
102	- [ ] Task breakdown with dependencies
103	- [ ] Risk identification and mitigations
104	- [ ] Verification checklist
105
106	See [plan-checklist.md](references/plan-checklist.md) for full verification.
107
108	## Output Format
109
110	Plans must include machine-readable task markers for `claudikins-kernel:execute` compatibility:
111
112	```markdown
113	<!-- EXECUTION_TASKS_START -->
114
115	\| # \| Task \| Files \| Deps \| Batch \|
116	\| --- \| ------------- \| -------------------- \| ---- \| ----- \|
117	\| 1 \| Create schema \| prisma/schema.prisma \| - \| 1 \|
118	\| 2 \| Add service \| src/services/user.ts \| 1 \| 1 \|
119
120	<!-- EXECUTION_TASKS_END -->
121	```
122
123	See [plan-format.md](references/plan-format.md) for complete structure.
124
125	## Anti-Patterns
126
127	Don't do these:
128
129	- Batching multiple questions together
130	- Proposing solutions before understanding requirements
131	- Presenting only one approach
132	- Skipping the verification checklist
133	- Continuing without explicit approval at checkpoints
134	- Fabricating research findings when data is sparse
135
136	## Rationalizations to Resist
137
138	Agents under pressure find excuses. These are all violations:
139
140	\| Excuse \| Reality \|
141	\| ----------------------------------------------------- \| ------------------------------------------------------------- \|
142	\| "I'll batch questions to save time" \| Batching causes missed requirements. One at a time. \|
143	\| "User knows what they want, skip brain-jam" \| Assumptions cause rework. Gather requirements explicitly. \|
144	\| "I'll propos

People who liked this also viewed

6 picks

Type