Update Spec

---
name: update-spec
description: Records an approved change to specified behavior in the spec and plan, with a dated note. Use when an approved spec needs to change: a decision during planning, execution, review, debugging or PR feedback would alter behavior the spec describes, or the user changes a requirement.
---

# Update Spec

The spec is what the plan, the reviewers and prove-done check against, so when specified behavior changes, the spec changes with it, alongside the code. This is a small edit to an approved spec: it applies once your partner has chosen to continue to planning. A new goal or feature goes back to the `dietpowers:brainstorm` skill.

Ask your partner one question at a time, in plain text; do not use the AskUserQuestion tool, because some clients show only the tool's question and drop the text around it. Put what your partner needs to answer in the same message: the problem and why it matters, then the options, recommended first, each with a short bold label in words (never numbers or letters) and a one-line reason. End with a line naming those labels in the same order, such as `Reply with **new PR**, **straight to main**, or **drop it**.`, and make the question the last thing in the message, after any tool use. Your partner may answer with an option, their own alternative, a question or an aside. Keep messages short: lead with the decision, then only the detail needed to answer it. Before a stretch of work that takes more than a moment, such as dispatching a reviewer, writing a spec or plan, or fixing findings, say in one line what you are about to do; after your partner answers, say what comes next before starting it.

When you find something worth doing later that this work does not include, add it as an item to `.dietpowers/trackers/open-items.md`, following `## Open items` in `${CLAUDE_PLUGIN_ROOT}/shared/trackers.md`, and say so in one line.

Before your first commit of the spec or plan for this piece of work, check the plan's `Commits:` line or your partner's earlier answer. If neither settles it, ask once: "I'll work on branch `<name>`. May I commit the spec and plan to it as we go? Nothing is pushed or merged without asking. Reply with **yes** or **no**." Whatever the answer, move the work to that branch; never commit to `main` or `master`. If your partner declines, the spec and plan are held back: wherever a step says to commit them, leave them on disk; the `dietpowers:finish-branch` skill proposes those commits at the end. Code is always committed.

1. If there is no approved spec, say so and stop.
2. State the change in one sentence and name the spec sections it touches. If it alters the goal or adds a feature, ask your partner whether to add it as an open item and carry on (recommended), or to pause the current work and start it now with the `dietpowers:brainstorm` skill. If they pause, note in the plan the task where work stopped.
3. Get your partner's approval, recommending an option with a reason. If the change came from your partner, confirm your one-sentence reading of it. If your partner declines, edit nothing, and have the calling skill drop the change; if the work cannot go on without it, the calling skill stops and asks your partner how to proceed. In a review, record the finding as rejected by your partner.
4. Edit only the affected sections and keep them consistent: Constraints, Inputs and failure behavior, Success criteria, References. If there is a plan, update its Global Constraints and References where they copy what you changed, and the matching tasks and their Tests.
5. Under each section you edited, add a note in this form: `> **Changed YYYY-MM-DD:** what changed (from X to Y). Why: ... Approved by ...`. When one change touches several sections, give the full note in the main one and a one-line note pointing to it in the others.
6. Commit the spec and plan edits with the code change that needs them, or on their own before it if the code comes later. If that code is already committed, commit the edits on their own and say so in the `Changed` note. Name the change in the commit message. If spec and plan commits are held back, leave the edits on disk, even though the code change is committed.

Terminal state: return to the skill you were in and continue from where you stopped.