blockmatic Purpose and inputs
Use the requested outcome, existing plan or issue, relevant implementation, rules, and technical docs. Planning alone does not authorize implementation or Git changes.
Steps
- State goals, non-goals, acceptance criteria, and 3–5 material assumptions. Resolve consequential ambiguity; continue with reversible details already covered by the request.
- Inspect the affected packages, their README and scripts, and existing behavior. For durable decisions, load FIRST in the repository's prescribed order and use one primary station.
- Divide work into the smallest complete user-visible slices. For each, name likely files, dependencies, an observable acceptance condition, and the existing command or manual check that proves it.
- Put uncertain dependencies early. Include error paths, compatibility, generated sources, and recovery where relevant. Use a diagram only when relationships need one.
- Save to the existing plan location or the user's chosen destination. Include Goals, Assumptions, ordered tasks, Risks/Open Questions, and References (rules, skills, docs). Do not create another backlog or overwrite another task's unfinished plan.
Verification
- Each slice has a result a reviewer can observe and a concrete verification method.
- Dependencies and consequential unresolved decisions are explicit.
- Commands come from inspected scripts; generated outputs have an owning source.
- The plan is reviewable without reconstructing this conversation.
Handoff
Return the plan location, unresolved decisions, and first implementable slice. If the user also requested implementation, continue within that authorization; otherwise finish with the plan. Do not create a branch or scaffold code just to plan.