plan-write
Write an implementation plan (`docs/plans/<slug>/plan.json`, RFC 0030) for a change before any code exists, in conversation with the person, check it with `plan:render`, and revise it from their revie
Files1
View on GitHubSKILL.mdpackages/cli/templates/agent/core/skills/plan-write/SKILL.md
GitHubPlan Writing Skill
You write the plan in this session, the person reviews and approves it, and
plan-implement builds it. Never run plan:approve: approving is the
person's decision, made after reading the page.
1. Get the prompt and follow it
bunx guren plan "<the request>" --print-prompt
Quote the request: an unquoted word starting with - is read as a flag.
Follow the prompt it prints. When it has you ask the person, ask in whatever
way your client offers and wait for the answers before you write the JSON. If
the change needs no plan, make it the usual way.
2. Check it until nothing fails
bunx guren plan:render docs/plans/<slug>/plan.json --json
Run it until no check has "status": "fail", then tell the person:
- where the page is (
pathin the output), which is what they review - the questions still open, each with the option the plan assumes
- the warnings you left, and why
3. Revise
Before the first review, edit plan.json directly. After a review, apply the
person's changes and the page's exported feedback to a copy of the plan,
leaving baseline as it is, and record them:
bunx guren plan:revise docs/plans/<slug>/plan.json \
--edited <copy> --message "<what changed and why>" --feedback - <<'EOF'
<the feedback JSON the person pasted>
EOF
- Keep the copy, and any saved
feedback.json, outside the repository:plan:approveandplan:nextcount every untracked file under the app root as uncommitted work. --feedback -reads standard input, so feed the pasted JSON in with a heredoc as above: your shell is not a terminal the person types into, and a bare-waits for input that never comes.- Apply each answer (the option picked, and any text written) to the elements
its
affectsnames, then remove the question from the copy;plan:reviserefuses a copy that keeps an answered question. - An element the feedback approved is locked unless
--reopens "<why>"says why it changes. - Feedback applies to the page it came from: render again after every change, report as in step 2, and have the person review the new page.
- After approval, the plan changes only through
plan:revise, and the person approves it again.
4. Hand off
The person approves the plan with:
bunx guren plan:approve docs/plans/<slug>/plan.json
It stamps the plan against a clean working tree. Once they have approved it
and committed the plan with its approvals.json and revisions/, the
plan-implement skill builds it step by step.