32d313b0c8
Add the planning/review command suite for opencode and align the planner skill with it: - /make-a-plan (build agent): researches the session subject, drafts the plan with the planner skill, asks open questions, then saves the final plan to .opencode/plans/. - /review-plan: reviews a plan with the plan-review skill; on approval suggests /implement-plan, on request changes /make-a-plan. - /review-code: reviews a diff, PR, or code change with the code-review skill; suggests /make-a-plan for substantive findings. All commands run as the build agent with explicit read-only rules that expire when the command's work is done, so follow-up requests need no agent switching. The planner skill no longer writes the plan file on its own: it saves only when a command or the user explicitly instructs it, and it suggests /review-plan and /implement-plan as next steps. AI-assisted-by: omen-alpha
4.5 KiB
description, agent
| description | agent |
|---|---|
| Investigate the chosen task, produce an implementation plan, and save it | build |
Act as a senior software engineer: research the subject of this session in depth and produce a well-grounded, actionable implementation plan.
Instructions
- Produce the plan with the
plannerskill. By default, research the subject of this session and draft the plan yourself. If I ask for it (for example,delegatedin the arguments), delegate to thegeneralsubagent instead — the delegate must also follow theplannerskill and receive all the relevant session context (a review, user feedback, and so on). - 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.
- Once all decisions are answered and the plan is final, save it verbatim to the
announced path under
.opencode/plans/(create the directory if it does not exist). This step is this command's explicit authorization to write the plan file — the only write allowed here. If I later ask for changes, update the saved file directly. - 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.
Hard rule — read-only while planning
While this command runs, act read-only: research with read-only tools only. Never edit source files, never run builds, tests, linters, or any command that modifies state, and never commit. The single allowed write is the plan file in step 3. This rule expires when I approve the plan or move on to another task; then you act as a normal build agent again.
When the plan contains open questions, do not show them as bare technical questions or assume that I understand the technical language or technical words used in the plan. For each question, first explain:
- What part of the user problem the decision affects.
- The relevant concept from the beginning, with a small concrete example.
- What each available option would make the system do.
- The practical benefits, costs, risks, and user-visible consequences of each option.
- Which option the planner recommends and why.
Only after that explanation, use the question tool to ask the decision with clear,
non-technical option labels. Put the recommended option first and mark it as
(Recommended). Group related questions when their context is shared, but do not ask a
question whose meaning has not already been explained.
If I say that I do not understand a question or its choices, do not treat my previous
answer as valid. Explain the concepts again from the high-level project goal, use a more
concrete example, explain the implications, and ask the question again with the
question tool. Repeat this until I can make an informed choice. If one answer creates
new design consequences or additional decisions, explain those consequences before
asking any new question.
Distinguish clearly between requirements already fixed by the roadmap or existing architecture and choices that actually require my input. Do not ask me to choose an implementation detail when the plan can resolve it safely without changing the public behavior. If there are no decisions that require my input, say so and present the summary.
IMPORTANT: Under no circumstances execute the plan. Wait for the user to review it after all possible questions have been answered. The final summary must explain the problem being solved, the proposed behavior, the main user-visible workflow, important constraints and risks, what is deliberately out of scope, and the path where the plan is saved. Never assume that a short list of task names is enough context. End the final response by suggesting the next steps, in this order:
/review-plan— to get a second opinion on the plan before executing it./implement-plan— to execute the plan from the current session context.
These are suggestions, not a required pipeline — any instruction from me overrides them (for example, asking you to implement the plan directly).
User input, overrides and additional context
$ARGUMENTS