// 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 checkpoints and trade-off presentation
Use when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation, verification, and human checkpoints; prevents runaway parallelization and context death
Use when running claudikins-kernel:ship, preparing PRs, writing changelogs, deciding merge strategy, or handling CI failures — enforces GRFP-style iterative approval, code integrity validation, and human-gated merges
Use when running claudikins-kernel:verify, checking implementation quality, deciding pass/fail verdicts, or enforcing cross-command gates — requires actual evidence of code working, not just passing tests
| name | brain-jam-plan |
| description | 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 checkpoints and trade-off presentation |
| allowed-tools | ["Read","Grep","Glob","TodoWrite","WebSearch","Skill","mcp__plugin_claudikins-tool-executor_tool-executor__search_tools","mcp__plugin_claudikins-tool-executor_tool-executor__get_tool_schema","mcp__plugin_claudikins-tool-executor_tool-executor__execute_code"] |
Planning is an iterative conversation, not a production line. The human stays in the loop at every phase.
"Go back and forth with Claude until I like its plan. A good plan is really important." — Boris
Core principle: Understand before solving. Ask before assuming. Recommend but let user decide.
Use this skill when:
claudikins-kernel:outline commandOne question at a time. Wait for the answer.
Key questions to answer:
Use AskUserQuestion with specific options — never open-ended unless necessary.
Before proposing solutions, understand the landscape:
Generate 2-3 distinct approaches. Each must include:
| Element | Purpose |
|---|---|
| Summary | 1-2 sentence overview |
| Pros | Clear benefits |
| Cons | Honest trade-offs |
| Effort | low / medium / high |
| Risk | low / medium / high |
Always recommend one with reasoning. See approach-template.md.
Draft one section at a time. Get approval before moving on.
Never batch approvals — each checkpoint is a chance to course-correct.
These rules have no exceptions:
One question at a time.
Always present 2-3 approaches.
Checkpoint before proceeding.
Never fabricate research.
A good plan has:
See plan-checklist.md for full verification.
Plans must include machine-readable task markers for claudikins-kernel:execute compatibility:
<!-- EXECUTION_TASKS_START -->
| # | Task | Files | Deps | Batch |
| --- | ------------- | -------------------- | ---- | ----- |
| 1 | Create schema | prisma/schema.prisma | - | 1 |
| 2 | Add service | src/services/user.ts | 1 | 1 |
<!-- EXECUTION_TASKS_END -->
See plan-format.md for complete structure.
Don't do these:
Agents under pressure find excuses. These are all violations:
| Excuse | Reality |
|---|---|
| "I'll batch questions to save time" | Batching causes missed requirements. One at a time. |
| "User knows what they want, skip brain-jam" | Assumptions cause rework. Gather requirements explicitly. |
| "I'll propose solutions while gathering requirements" | Solutions bias requirements. Understand first, solve second. |
| "User implied preference, don't need alternatives" | Implied ≠ decided. Always present 2-3 options. |
| "This is simple, don't need checkpoints" | Simple plans still fail. Checkpoints catch errors early. |
| "I already know the right approach" | Your confidence isn't approval. User decides. |
| "Alternatives will confuse them" | Confusion means requirements are unclear. Clarify. |
| "I'll get approval for multiple sections at once" | Batched approvals hide problems. One section, one checkpoint. |
All of these mean: Follow the methodology. No shortcuts.
If you're thinking any of these, you're about to violate the methodology:
All of these mean: STOP. Return to methodology. Ask, don't assume.
| Situation | Reference |
|---|---|
| Context collapse mid-plan | session-collapse-recovery.md |
| Endless iteration loop | iteration-limits.md |
| Research taking too long | research-timeouts.md |
| Approaches contradict each other | approach-conflict-resolution.md |
| User abandons plan | plan-abandonment-cleanup.md |
| Requirements keep changing | requirement-stability.md |