Make A Plan

Make a Plan

Act as a senior software engineer: research the subject of this session in depth and produce a well-grounded, actionable implementation plan.

If the running agent cannot write (for example, the plan agent), say so and stop — this skill needs the build agent to save the plan.

When to use

• The user asks to plan, design, or break down a task, in any phrasing: "make a plan", "how would we build X", "design an approach for Y" — or runs /make-a-plan.
• The user asks to rework or extend an existing plan. While the plan is still unimplemented (pre-implement-plan iteration, e.g. after /review-plan findings or user feedback), revise the saved plan file in place. Once the plan has been implemented and reviewed (post /review-code findings on committed work), write a new derived plan file instead — never rewrite the executed plan. The planner skill defines the derived naming (--review-NN, --task-NN).
• The user says to apply review-plan findings to a still-unimplemented plan: apply the agreed changes, flip Status to reviewed, and append one UTC ISO 8601 line to Review Log describing what changed. This apply step is the only pre-implementation write to those fields — review-plan itself stays read-only and never writes.

Do not use it to execute a plan — that is the implement-plan flow.

Instructions

1. Produce the plan with the planner skill. By default, research the subject of this session and draft the plan yourself. If I ask for it (for example, delegated in the user context), delegate to the general subagent instead — the delegate must also follow the planner skill and receive all the relevant session context (a review, user feedback, and so on).
2. Before asking me to decide anything, explain the plan and every open question in plain language. Assume I know only the high-level project goal, not the codebase, architecture, implementation terms, or the problem this task solves.
3. Once all decisions are answered and the plan is final, save it verbatim to the announced path under .agents/plans/ (create the directory if it does not exist). This step is the flow's explicit authorization to write the plan file — the only write allowed here. A fresh plan uses .agents/plans/YYYY-MM-DD-<slug>.md with Status: draft and an empty Review Log; a derived plan uses the parent basename plus the planner suffix (--review-NN, --task-NN) in its own new file, also starting as draft. If I later ask for changes to a still-unimplemented plan, update the saved file directly.
4. Present me with a clear, self-contained summary of the plan's most relevant points only after all required decisions have been answered. Write it for someone who knows only the project's high-level goal and may not know the plan's low-level context. Explain necessary technical language in plain terms, include the problem being solved and the proposed outcome, and do not assume that listing technical task names is enough.