Skip to content
Back to skills

Gz Adr Closeout Ceremony

ASecurity

Use to run an ADR's closeout ceremony through to the operator's attestation.

  • 9 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 19, 2026
documentationpythonrustgobashsqltestinggitdocumentation

Works with

  • cli

Security analysis

A100/100

Scanned October 19, 2026

npx -y skills add tvproductions/gzkit --skill gz-adr-closeout-ceremony --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Gz Adr Closeout Ceremony?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Gz Adr Closeout Ceremony
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tvproductions-gz-adr-closeout-ceremony/badge)](https://www.skillsdirectory.com/skills/tvproductions-gz-adr-closeout-ceremony)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

SKILL.md
---
name: gz-adr-closeout-ceremony
persona: pipeline-orchestrator
description: Use to run an ADR's closeout ceremony through to the operator's attestation.
category: adr-audit
compatibility: GovZero v6 framework; provides runbook walkthrough for human ADR attestation
metadata:
  skill-version: "7.21.1"
  govzero-framework-version: "v6"
  govzero-author: "GovZero governance team"
  govzero-spec-references: "docs/governance/GovZero/charter.md, docs/governance/GovZero/audit-protocol.md"
  govzero-gates-covered: "Gate 5 (Human Attestation)"
  govzero_layer: "Layer 2 - Ledger Consumption"
lifecycle_state: active
owner: gzkit-governance
last_reviewed: 2026-10-17
model: opus
---

# gz-adr-closeout-ceremony

Execute the ADR closeout ceremony by driving the CLI state machine.

**Authority:** `docs/governance/GovZero/audit-protocol.md`

---

## The Ceremony Contract

```
THE CEREMONY IS NOT COMPLETE UNTIL THE HUMAN ATTESTS AND THE REPO IS SYNCED.
```

Running walkthrough commands is not completion. Passing quality checks is not completion. Printing a summary is not completion. The ceremony exists to produce a **human attestation decision backed by structured evidence**, then persist that decision to the ledger and sync it.

**Violating the spirit of this contract is violating it.**

### Rationalization Prevention

These thoughts mean STOP — you are about to break the ceremony:

| Thought | Reality |
|---------|---------|
| "All checks passed, the ADR is done" | Checks passing is evidence. The human decides. You do not. |
| "Let me summarize the walkthrough results" | Present them in the evidence template. Do not interpret them. |
| "The human acknowledged each step, so they've attested" | Acknowledgment is not attestation. Wait for the explicit `--attest` decision. |
| "I'll skip the walkthrough since OBPIs already passed" | The walkthrough is the human's verification surface. You do not skip it for them. |
| "The CLI errored, I'll work around it" | CLI errors are signals. Diagnose the cause. Do not reimplement step logic. |
| "I can close the issues and sync later" | Later means never. The ceremony runs to completion NOW. |
| "The human said 'looks good'" | "Looks good" is not an attestation value. Ask for Completed, Completed-Partial, or Dropped. |

---

## Persona

**Active driver:** `pipeline-orchestrator` — read `.gzkit/personas/pipeline-orchestrator.md` and adopt its behavioral identity before executing this skill. Closeout is a sequenced ceremony (read evidence → present → attest → persist); the ceremony-as-checkbox anti-trait — "treating the attestation ceremony as a formality to rush through rather than a genuine decision point" — is literally what this skill exists to prevent. Present evidence; do not interpret it. The human decides. You do not.

## Persona Dispatch

Closeout is read-only ceremony work — the driver synthesizes attestation evidence from three independent subagent reads. Dispatch each as a fresh-context subagent so the driver isn't scoring its own scoring (the `optimistic-bias` failure mode `spec-reviewer`'s anti-traits name):

| Persona | Function in this ceremony | Invoked at |
|---|---|---|
| `spec-reviewer` | Independent re-verification of each OBPI's claimed REQ coverage against brief and tests, against ledger proof | Before assembling the evidence packet (after CLI walkthrough, before human attestation step) |
| `quality-reviewer` | Independent assessment of the ADR-package structural coherence: do the closed OBPIs form a coherent capability, or is there integration drift? | Before assembling the evidence packet |
| `narrator` | Composes the evidence packet in operator-value framing — what the operator gains, not what the agent did; what decision the human is being asked to make, with precise citations | When rendering the attestation surface to the human |

Personas not dispatched: `implementer` (no code written — closeout reads completed work; if it surfaces a defect, file a GHI via `/ghi-author`).

**This ceremony has no artifact channel for these dispatches** — they are unattested and undisclosed (GHI #770's named residual), and the receipt machinery that would record them is not yet authored (GHI #846; `ADR-pool.obpi-pipeline-dispatch-attestation` is Superseded into ADR-0.0.73, which delivered no receipts). Treat the mandate as binding on you, not as something a gate will catch.

Persona doctrine reference: ADR-0.0.11-persona-driven-agent-identity-frames (Validated).

## Trust Model

**Layer 2 — Ledger Consumption:** This skill orchestrates human attestation using ledger proof.

- **Reads:** Ledger entries, audit reports, ADR/OBPI files
- **Writes:** Attestation records, status updates via CLI commands
- **Does NOT re-execute (CLI layer):** The ledger-consumption layer trusts Layer-1 proof and never re-runs receipts. Independent re-verification is performed by the `spec-reviewer` persona-dispatch step (§ Persona Dispatch above), not by the CLI.
- **Requires:** Human attestation before finalizing

---

## When to Use

- Human invokes "ADR closeout ceremony" (or equivalent: "begin closeout", "closeout ADR-X.Y.Z")
- Human is ready to witness and attest to ADR completion
- All OBPIs are believed to be complete

## When NOT to Use

- For individual OBPI completion — use `gz-obpi-pipeline` instead
- When OBPIs are still in progress — complete them first
- For audit-only checks without ceremony — use `gz adr audit-check`

---

## Architecture

The ceremony is driven by `src/gzkit/commands/closeout_ceremony.py` (state model in `src/gzkit/commands/ceremony_state.py`), which provides:

- **Step sequencing** — deterministic step ordering via `CeremonyStep` enum
- **Foundation skip** — `FOUNDATION_SKIP_STEPS` automatically skips RELEASE_NOTES and RELEASE steps for 0.0.x ADRs
- **State persistence** — ceremony state saved in `.gzkit/ceremonies/<ADR-ID>.json`
- **Walkthrough discovery** — commands extracted from OBPI briefs and command docs
- **Turn locks** — prevents step skipping

**The agent MUST drive the ceremony through CLI commands, not by reimplementing
step logic in prose.** The CLI handles all conditional logic (Foundation skips,
lane-specific steps, step ordering). The agent's role is to:

1. Run the CLI command for each step
2. Present the output using the evidence template
3. Wait for human acknowledgment
4. Advance via CLI

---

## Procedure

### Step 1: Initialize

When the human says "ADR closeout ceremony" (or equivalent), start the ceremony:

```bash
uv run gz closeout ADR-X.Y.Z --ceremony
```

This initializes the ceremony state machine and outputs the Step 2 summary.
Present the output to the human. Do not interpret or claim outcomes.

**If resuming an interrupted ceremony:** The same command resumes from the last completed step. Check the current state first:

```bash
uv run gz closeout ADR-X.Y.Z --ceremony --ceremony-status
```

**Abort if:** ADR not found, no OBPIs exist, or ceremony state is corrupt (see Error Recovery).

### Step 2: Advance Through Steps

After the human acknowledges each step, advance:

```bash
uv run gz closeout ADR-X.Y.Z --ceremony --next
```

The CLI outputs the content for the next step. Present it and wait for acknowledgment.

**Repeat this cycle for each step.** The CLI handles:

- Which step comes next
- Skipping Foundation-excluded steps (RELEASE_NOTES, RELEASE for 0.0.x)
- What content to present at each step

### Step 3: Docs Alignment Check

When the CLI presents the docs alignment checklist (CLI Step 3), the human confirms
documentation parity. Advance via `--next` after acknowledgment.

**If the human identifies doc gaps:** Do not advance. Fix the documentation, run `uv run mkdocs build --strict` to verify, then re-present the checklist. Only advance after the human confirms parity.

### Step 4: Walkthrough Execution

When the CLI presents walkthrough commands (CLI Steps 4-5), run them one at a time. The CLI enforces this cadence at Step 5 EXECUTE: each `--next` advances `walkthrough_index` by one and the renderer presents exactly one demo command per turn (GHI #260).

- Run ONE command, show output, STOP and WAIT for acknowledgment
- Advance with `--next` after the human acknowledges — the CLI then presents the next demo
- The ceremony only moves to Step 6 ATTESTATION after the final demo has been presented and acknowledged

**Auto-mode override.** Auto mode's "prefer action over planning, minimize interruptions" framing does NOT apply inside the walkthrough. Step 5 is an operator-paced observation surface — do not batch demo commands into parallel tool calls to save turns.

**Evidence-gathering ARB checks are separate from the demos.** The Evidence Summary Template (§ below) lists the canonical ARB-wrapped invocations (`uv run gz arb ruff`, `uv run gz arb step --name unittest -- uv run unittest-parallel -t . -s tests --buffer`, `uv run gz arb typecheck`, `uv run gz arb step --name mkdocs -- uv run mkdocs build --strict`) as evidence-template population — these are not discovered demo commands and must NOT be interleaved with the per-demo `--next` loop. Run them when gathering evidence for the Step 6 attestation prompt (either right before the prompt or during pre-ceremony preparation), never mixed into the Step 5 one-at-a-time sequence. Heavy-lane ceremony fail-closes on missing receipt IDs per `AGENTS.md` § Attestation, so bare (non-ARB) invocations do not satisfy the evidence requirement.

**Bound fidelity gate at the EXECUTE→ATTESTATION edge (ADR-0.0.73, OBPI-0.0.73-04).** When the final demo is acknowledged and `--next` advances from Step 5 EXECUTE to Step 6 ATTESTATION, the CLI automatically runs the **bound fidelity gate** — the SAME standalone gate the audit ceremony invokes (one gate, two consumers — `assert_fidelity_for_ceremony`). It parses the ADR Decision's `## Fidelity Assertions` block and RUNS each assertion against the committed tree — a detached worktree at HEAD, so uncommitted files cannot satisfy it and its commands cannot write to the live checkout; no buildable worktree fails closed (GHI #1156). This is the bound replacement for the old prose 'Demonstrate Value' step — you do not narrate value; the gate exercises the ADR's thesis. A failed assertion **blocks the transition** (PolicyBreachError). An ADR with no `## Fidelity Assertions` block is **flagged with a warning** but does not hard-block in-flight (graceful migration, OBPI-0.0.73-04); author a block before closeout, since presence is enforced at ADR closeout per ADR-0.0.73 Boundary Invariant #4.

**If a walkthrough command fails:** See Error Recovery. Do not skip it. Do not advance past it. Fix it or escalate.

### Step 5: Attestation

When the CLI presents the attestation prompt (CLI Step 6), present the **Evidence Summary** (see template below), then wait for the human's decision:

```bash
uv run gz closeout ADR-X.Y.Z --ceremony --attest "Completed"
```

Valid attestations:
- `"Completed"` — ADR work is finished; all claims verified
- `"Completed - Partial: [reason]"` — Subset accepted, remainder deferred
- `"Dropped - [reason]"` — ADR rejected; does not advance

**Human requests corrections:** This is a rejection. Record the feedback, identify which ceremony steps need re-execution, and return to the appropriate step. Do NOT record a partial attestation when the human wants fixes. See Rejection Loop-Back below.

### Step 6: Closeout Pipeline

When the CLI presents CLI Step 7, run the closeout pipeline:

```bash
uv run gz closeout ADR-X.Y.Z
```

This handles quality gates, attestation recording, version bump, and closeout form.
After it completes, advance the ceremony:

```bash
uv run gz closeout ADR-X.Y.Z --ceremony --next
```

### Step 7: GitHub Issues

When the CLI presents CLI Step 8, review the ADR's open issues and close each one that the closeout resolves:

```bash
gh issue list --search "ADR-X.Y.Z" --state open
```

**GHI closure discipline (cross-reference):** Close each issue through
`ghi-close`, one GHI, one disposition, one comment. Its dead-letter doctrine
binds here: every GHI close MUST cite a real, registered destination
(commit SHA, ADR ID in `gz adr report`, OBPI brief ID, or higher-numbered open
GHI). A close comment pointing to an unregistered ADR draft or a vague
"route to the team" is a dead-letter and is forbidden. If no destination exists
at closeout time, leave the GHI open with a blocker comment and note it in
the closeout summary. See `.gzkit/skills/ghi-close/SKILL.md` § Doctrine —
NEVER, EVER, EVER dead-letter a GHI for the binding rule.

Then advance via `--next`.

### Step 8: Release Steps (CLI-Driven)

The CLI automatically handles Foundation vs non-Foundation:

- **Foundation (0.0.x):** Steps 9-10 are skipped automatically by `FOUNDATION_SKIP_STEPS`
- **Non-Foundation:** The CLI presents two release steps, and both hand over

For non-Foundation releases the ceremony's release work ends at the version bump. The entry, the changelog and the publication belong to the `gz-patch-release` skill (operator ruling 2026-10-11; `.gzkit/rules/changelog-release-notes.md`, release-notes rule 3):

```text
Steps 9 and 10: run gz-patch-release from its "Hand-over from closeout" section. Write no entry here.
```

After each step, advance via `--next`.

**The sync-before-release order depends on the bump filing its own evidence (GHI #739).** `audit_version_release` runs inside the sync and fails a declared version with no matching `vX.Y.Z` tag, so `gz closeout` writes `docs/releases/RELEASE-v{version}.md` at bump time as accepted in-flight evidence. If that manifest is missing, the sync refuses on a `version_release` violation — write it rather than reordering the ceremony (a tag created before the bump commit points at a tree lacking the bump).

### Step 9: Completion (Two-Sync Pattern)

When the CLI outputs the ceremony completion summary (CLI Step 11), present it to the human, then run the **two-sync pattern** to commit the closeout cleanly. This mirrors `gz-obpi-pipeline`'s Stage 5 — every governance artifact must land in two reviewable commits.

```bash
uv run gz git-sync --apply   # Sync 1 — closeout artifacts
uv run gz git-sync --apply   # Sync 2 — residue check; commonly a no-op
```

**Why two syncs:**

1. The first sync makes the human attestation, receipt, and walkthrough evidence durable before any derived state is rebuilt.
2. The second sync is the mechanical check that no post-closeout hook, per-OBPI `gz obpi sync` sweep, or derived-state refresh left uncommitted artifacts. In the common case sync 2 is a no-op because the closeout pipeline emits derived-state reconciliation atomically with the attestation event; sync 2 exists to catch the exceptional case where it did not.

If sync 1 fails, the ceremony is paused — fix the failing gate, re-run sync 1. **Never** skip sync 2: skipping it risks leaving a derived-view artifact uncommitted, which is the same failure family as #129 (canon green, derived view stale).

The ceremony is done.

#### Fallback / Degraded Mode

If `gz git-sync` is unavailable (network failure, gh outage, dirty submodule):

1. Stop the ceremony at the failed sync. Do not advance.
2. Capture the exact error output and the ceremony state file path (`.gzkit/ceremonies/<ADR-ID>.json`).
3. Hand off to the human with a one-line summary plus the resume command:
   `uv run gz closeout ADR-X.Y.Z --ceremony` (re-attaches to the persisted state).
4. Do **not** manually commit closeout artifacts or hand-edit the ledger as a workaround. The ceremony resumes cleanly once sync is restored.

---

## Evidence Summary Template

Present this template at Step 5, before requesting attestation. Every field is mandatory. The human cannot make an informed attestation decision without structured evidence.

```
## ADR Closeout Evidence: ADR-X.Y.Z

**1. ADR Intent**

<What was this ADR's purpose? 1-2 sentences from the ADR document.>

**2. OBPI Completion Status**

| OBPI | Status | Attestor | Date |
|------|--------|----------|------|
| OBPI-X.Y.Z-01 | Completed | <name> | <date> |
| OBPI-X.Y.Z-02 | Completed | <name> | <date> |

**3a. Product Demos — the yielded product**

The ADR's outcome, demonstrated. Every row is a concrete invocation that exercises the capability the ADR delivered — actual diagnosis runs against real files, the `--json` form, auto-chain trigger output, intrinsic-attestation paths, etc. `--help` is the weakest possible product demonstration; reach for it only when no richer demo exists. Brief-side `## Demo` / `## Examples` sections feed this table directly through the walkthrough discovery (GHI #427).

| Demo Command | Result | Notes |
|--------------|--------|-------|
| `uv run gz <verb> <real-args>` | <observed outcome> | <one-line operator-value framing> |
| `uv run gz <verb> <real-args> --json` | <observed outcome> | <one-line operator-value framing> |
| <brief-specific demo> | <observed outcome> | <one-line operator-value framing> |

**3b. Quality Evidence — construction housekeeping**

Cite canonical ARB-wrapped invocations with receipt IDs. These prove the codebase is healthy; they are not the ADR's product. Heavy-lane attestation fail-closes on missing receipt IDs per `AGENTS.md` § Attestation; bare (non-ARB) commands do not satisfy this requirement. The canonical invocations are locked by `CANONICAL_STEP_COMMANDS` in `src/gzkit/canonical_steps.py`.

| Command | Result | Receipt ID | REQ Bindings | Notes |
|---------|--------|------------|--------------|-------|
| `uv run gz arb ruff` | Pass | `arb-ruff-...` | REQ-X.Y.Z-NN-MM | <summary> |
| `uv run gz arb step --name unittest -- uv run unittest-parallel -t . -s tests --buffer` | Pass | `arb-step-unittest-...` | REQ-X.Y.Z-NN-MM | <N> unit tests |
| `uv run behave features` | Pass | n/a (no canonical ARB wrapper) | n/a | <M> behave scenarios (closeout = full suite) |
| `uv run gz arb typecheck` | Pass | `arb-step-typecheck-...` | REQ-X.Y.Z-NN-MM | <summary> |
| `uv run gz validate --documents` | Pass | n/a | n/a | <summary> |
| `uv run gz arb step --name mkdocs -- uv run mkdocs build --strict` | Pass | `arb-step-mkdocs-...` | REQ-X.Y.Z-NN-MM | <summary> |

**4. Documentation Alignment**

- [ ] Runbook updated
- [ ] Command docs current
- [ ] ADR document reflects final state

**5. Open Issues**

| Issue | Status | Disposition |
|-------|--------|-------------|
| #<N> | Open/Closed | Resolved by closeout / Deferred to ADR-X.Y.Z |

**6. Awaiting attestation.** Provide: "Completed", "Completed - Partial: [reason]", or "Dropped - [reason]".
```

---

## Error Recovery

| Failure Point | Action | Retry Limit |
|---------------|--------|-------------|
| `--ceremony` init fails (ADR not found) | Verify ADR path exists, check `gz adr status`, report to human | 0 — fix config |
| `--next` fails (step logic error) | Check `--ceremony-status` for current step. Report CLI error to human. Do not reimplement step logic. | 1 — retry after status check |
| Walkthrough command fails (non-zero exit) | Show the error output to the human. Diagnose: is it a code bug, config issue, or environment problem? Fix if possible, re-run the command. | 2 — fix and retry, then escalate to human |
| Walkthrough command produces unexpected output | Present output as-is to the human. Do not interpret. Let the human decide if it's acceptable. | 0 — human decides |
| `gz closeout ADR-X.Y.Z` pipeline fails | Show error. Check if quality gates failed (`gz lint`, `gz test`). Fix failing gates, re-run. | 2 — fix gates, then escalate |
| `gh issue close` fails | Verify issue exists and is open (`gh issue view <N>`). Retry with correct number. | 1 |
| `gz git-sync` fails | Do not proceed past the sync step. Diagnose: lint failures, test failures, merge conflicts. Fix and re-sync. | 2 — fix and retry, then escalate |
| Ceremony state corrupt | `--ceremony-status` shows inconsistent state. Re-initialize: `gz closeout ADR-X.Y.Z --ceremony` (resumes from last completed step). | 1 — re-init |
| Human is unresponsive at attestation | Do nothing. Wait. Do not infer attestation from silence. | 0 — wait indefinitely |

**On any unrecoverable failure:** Report the failure clearly to the human with the exact error output. Do not attempt to work around the CLI. The ceremony is paused — state is persisted in `.gzkit/ceremonies/` and can be resumed in a new session.

---

## Rejection Loop-Back

When the human requests corrections instead of attesting:

1. **Record the feedback** — note exactly what the human wants fixed
2. **Identify the scope** — is it a code fix (return to OBPI pipeline), a doc fix (fixable in ceremony), or an evidence gap (re-run walkthrough)?
3. **Execute the fix:**
   - **Code fix needed:** The ceremony cannot fix code. Advise the human to re-open the relevant OBPI via `gz-obpi-pipeline --from=verify`. Pause the ceremony.
   - **Doc fix needed:** Fix the documentation, run `uv run mkdocs build --strict`, re-present the docs alignment step.
   - **Evidence gap:** Re-run the relevant walkthrough commands, update the evidence template, re-present to the human.
4. **Re-present attestation** — after fixes, present the updated Evidence Summary Template and wait for the human's decision again.
5. **Bound the loop** — if the human rejects a third time, escalate: "Three correction cycles completed. Should we continue fixing, defer this ADR, or drop it?"

---

## Ceremony State

State is persisted at `.gzkit/ceremonies/<ADR-ID>.json` by the CLI. The `CeremonyState` model in `src/gzkit/commands/ceremony_state.py` is the authority for its fields; read the current step with `--ceremony-status` rather than from the file.

**Resumption:** `gz closeout ADR-X.Y.Z --ceremony` checks for existing state and resumes from the last completed step. The agent does not need to re-run completed steps.

**Concurrent ceremonies:** Each ADR has its own state file. Multiple ADR ceremonies can run in separate sessions without interference.

---

## CLI Reference

> See references/cli-reference.md for the full command table.

---

## Ceremony Rules

One-sided directives. Each row states the required behavior and names the failure shape it prevents.

1. **Drive the ceremony through CLI commands** (`--ceremony`, `--next`, `--attest`). The CLI state machine is authoritative — never reimplement step logic in prose, ad-hoc Python, raw SQL, or heredoc code, and never manually skip or add steps (the CLI handles Foundation skips and ordering).
2. **Present CLI output without interpreting or concluding.** Evidence is presented; outcomes are not claimed. Passing checks are evidence, not a verdict.
3. **Use the Evidence Summary Template** before requesting attestation. Every field populated; no freeform substitution.
4. **Use only runbook/manpage-documented gzkit commands** for the walkthrough — no undocumented flags, no improvised invocations.
5. **Run walkthrough commands one at a time and wait for acknowledgment** between each — even in auto mode — and keep the evidence-gathering ARB checks out of the per-demo sequence (Step 4).
6. **Wait for explicit human attestation.** Silence, "ok", or "looks good" is not attestation; ask "Completed, Completed-Partial, or Dropped?" and never auto-close based on passing checks.
7. **Record attestation only through `uv run gz closeout ADR-X.Y.Z`.** Never hand-edit the ledger, never substitute "Completed - Partial" for what the human intended as a rejection (follow the Rejection Loop-Back procedure).
8. **Stop on any failed walkthrough command.** Fix the root cause or escalate; do not advance, and do not work around CLI errors by reimplementing the step in prose.
9. **Review and close related GitHub Issues after attestation, each through `ghi-close`.** Unlinked closure leaves evidence orphaned.
10. **Run `uv run gz git-sync --apply` before `gh release create` (non-Foundation) and after ceremony completion.** An unsynced attestation is a dangling ceremony.

---

## ADR Folder Structure (Canonical)

> See references/folder-structure.md for the expected directory layout.

---

## References

- Ceremony code: `src/gzkit/commands/closeout_ceremony.py`
- Ceremony state model: `src/gzkit/commands/ceremony_state.py`
- Step renderers: `src/gzkit/commands/ceremony_steps.py`
- Audit protocol: `docs/governance/GovZero/audit-protocol.md`
- Gate definitions: `docs/governance/GovZero/charter.md`
- Release tag rule: `docs/governance/GovZero/adr-lifecycle.md`
- Runbook: `docs/user/operator_runbook.md`
- Pipeline skill (behavioral reference): `.gzkit/skills/gz-obpi-pipeline/SKILL.md`

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.