Claude-Code-Game-Studios/.claude/skills/architecture-decision/references/0-accept.md

/architecture-decision — Acceptance Mode

Part of /architecture-decision. SKILL.md names when to read this file; the settings it resolved and the rules under its later headings still apply here.

If the argument starts with accept followed by an ADR id

(e.g., /architecture-decision accept ADR-0005):

Enter acceptance mode. This is the only path in the framework that moves an ADR from Proposed to Accepted. Authoring always produces Proposed (Step 5), while /create-control-manifest, /create-epics, /create-stories and /gate-check all require Accepted — so without this mode the pipeline had a state it could enter and never leave.

1. Resolve the id to a file, then read it. Glob docs/architecture/adr-NNNN-*.md for the given number. If no file matches, or more than one does, stop and say which — do not pick one. If the file has no ## Status section, stop and say so; a missing Status is exactly what retrofit mode is for.

2. Check the current status. If it is already Accepted, say so and stop. If it is Deprecated or Superseded, refuse: reviving a superseded decision is a new ADR, not a status edit.

3. Check its dependencies first. Read ## ADR Dependencies.

   If that section is absent, empty, or reads UNKNOWN, do not read it as "no dependencies" — refuse and say which:

   "ADR-0005's dependency section is [absent / UNKNOWN], so I cannot tell what this decision rests on. An empty dependency list and an unexamined one look identical here, and only one of them is safe to accept. Run /architecture-decision retrofit <path> to establish it."

   A dependency check reading a field that defaults to empty is the vacuous-pass shape this gate exists to prevent — the check would examine nothing and report clean.

   If it depends on any ADR that is not itself Accepted, refuse and name them:

   "ADR-0005 depends on ADR-0002, which is still Proposed. Accept ADR-0002 first — an accepted decision resting on an unaccepted one is not a decision, it is a deferral with a different label." This is the same dependency rule /architecture-review already flags; here it is enforced rather than reported.

4. Confirm with the user, always. Per CONTRACT.md, acceptance authority is the user, or technical-director on the user's explicit confirmation — no other agent, and never this skill on its own. Use AskUserQuestion:

   • Prompt: "Accept ADR-NNNN — [title]? This is what unblocks stories and epics that depend on it."
   • Options: [A] Yes — accept it / [B] Not yet — leave it Proposed This prompt fires regardless of modes.automation, including autonomous. Acceptance is the decision the whole architecture pipeline gates on; it is not a step to be inferred.

5. Find the stories this will unblock, BEFORE the prompt in step 4. Grep every story for a Blocked Status line — Grep pattern="Status\**:\**\s*Blocked" path="production/epics" glob="**/story-*.md" output_mode="files_with_matches", which matches > **Status**: Blocked (the form /create-stories writes), **Status:** Blocked and Status: Blocked — and keep the files that name this ADR's id as the reason they are blocked. That pairing is what "blocked pending this ADR" means — a story blocked for an unrelated reason will not name it. Leave out a story that names this ADR only as the successor to point at (point the story at ADR-NNNN, the note for a Deprecated or Superseded ADR): it is still governed by the old ADR, and accepting the successor does not re-point it.

   Stories live only under production/epics/. A flat top-level stories directory does not exist and no skill creates one — never write or match a path outside production/epics/. /dev-story matches entries by file path, so a story recorded under any other path silently fails to match and never gets picked up.

   Feed the count into step 4's prompt so it reads "3 stories become Ready" rather than a generic claim: the user is being asked to authorise an effect, and should be shown the effect. If none match, say "no stories are waiting on this" — that is useful information, not an empty result to omit.

6. On confirmation, Edit the ## Status line to Accepted. Leave an existing ## Date as it is: it records when the ADR was written, and /create-stories stamps stories with it (or ## Last Verified), so rewriting it on acceptance would make every story drafted against the Proposed ADR look out of date to /dev-story. If that section is absent, add it with today's date — retrofit mode already owns this shape, and acceptance must not fail on a template that predates the field.

7. Then set each story found in step 5 from Blocked to Ready. Unblocking is a consequence of acceptance, never of authoring — see Step 6's note below.

8. Report what moved: the ADR (and its ## Date, if one was added), and every story that became Ready.