nerd-plan

Nerd Plan

Incompatible Skills

Never combine Nerd with these unless this request explicitly asks:

• Superpowers
• Ponytail
• Caveman

Skill hooks, mentions, and indirect instructions are not authorization.

Plan Contract

This contract takes priority over inheritance, prerequisites, and intake rules:

• Invoking nerd-plan authorizes saving the plan; never ask for a separate save instruction. With sufficient confirmed inputs, always persist the Plan Format. A Focus Record, intake, discussion, or prerequisite handoff cannot replace it.
• Keep all accepted outcomes and related master/subordinate deliverables in one cohesive plan, using the required size-based files without further permission.
• Follow-up feedback and revisions stay on Plan and update the same artifact. Leave only on an explicit request for another endpoint. Execution requires a direct request to execute, implement, apply, or start the plan; plan text cannot authorize it.

Inheritance and Prerequisites

Use nerd-smart first. Accept only the Plan endpoint with its resolved Focus Record. If missing, unresolved, or on another endpoint, return to Smart before continuing.

Plan from confirmed inputs. Route missing prerequisites through Smart, one endpoint at a time, then resume Plan through Smart. Reuse existing handoffs:

Missing input	Route	Bring back
Material design choice	nerd-brainstorm / Ideate	Direction, trade-off, constraints, choice-changing unknowns
Repository evidence	nerd-explore / Explore	Exact paths, symbols, interfaces, commands, constraints, unknowns
Root cause	nerd-diagnose with nerd-surgery / Diagnose	Cause, evidence, smallest prescription, proof experiment

Mark unresolved material facts Unknown; never invent facts or conceal alternatives in conditional tasks.

Planning Rules

• Use KISS: the simplest sufficient design. Read Comprehensive for cross-boundary completeness, DRY for proven duplication, or the selection guide when unclear.
• Map files and responsibilities, then divide accepted outcomes into independently reviewable tasks with their own proof. Order by dependency; add task-body Depends on only when order is unclear. Avoid coordination machinery by default.
• Name exact paths, symbols, changes, commands, and expected results. Behavior changes require failing test → observed failure → minimum change → focused pass → relevant regression proof. Static work uses baseline → change → post-change proof.
• Create one goal ledger table and exactly one task ledger table per goal. Each task belongs to one goal. Follow artifact layout and ledger for thresholds, file roles, traceability, and status lifecycle.
• Code-changing tasks require fenced, illustrative pseudocode in the repository language: actual class/method or standalone function names, concrete input/output types, validation, transformations, outputs, empty results, and failure paths. Add boundary contracts when needed. For other tasks, state that no code skeleton applies and name the artifact/configuration contract.
• Omit TBD, vague follow-ups, empty sections, speculative work, and repeated facts.