Compliance Attestation
Produces the harness's durable compliance evidence: a per-commit, SHA-keyed,
sha256-integrity-hashed attestation bundle committed under .claude/attestations/.
The per-run verdicts the harness already produces (gate-receipt.json, quality-card.json,
the Increment 2/3 *-verify.json outputs) are ephemeral — specs/reviews/ and all *.jsonl
are gitignored, and the verify outputs overwrite in place with no commit SHA or timestamp. This
skill aggregates them into one committed record per commit that an auditor can read and re-check.
When to use
- At
/gate or in CI, after the verify/gate outputs for a commit exist, to write the committed
evidence record — then commit .claude/attestations/<sha>.json and index.json.
- To re-check a stored attestation's integrity with
--verify <file> (corruption detection —
see the Integrity checksum bullet under How it works for what this does and does not prove).
- When a project must map the neutral clause taxonomy onto a real external standard.
Do not use
- To provision branch protection or deploy environments — that is
/provision (its protection
and environments modes, Increments 2/3). This skill only reads their outputs.
- To change gate behavior. It is purely additive read-and-record; it never mutates
gate-receipt,
quality-card, or the verify outputs.
How it works
node .claude/scripts/generate-attestation.js # write .claude/attestations/<sha>.json (+ index.json)
node .claude/scripts/generate-attestation.js --force # overwrite an existing record for this SHA
node .claude/scripts/generate-attestation.js --verify .claude/attestations/<sha>.json
node .claude/scripts/generate-attestation.js --json # print the bundle instead of a summary line
- Inputs — three sources (branch-protection verify, deploy-gate verify, gate receipt), each classified
fail-safe:
absent (file missing ⇒ recorded null), invalid (present but unparseable or missing a
boolean verdict ⇒ recorded {invalid:true} — never a silent pass), or pass/fail. Plus the control
inventory + per-control clause from harness-manifest.json, the .claude/state/*-baseline.* ratchets,
repo/commit from git, and the harness version from package.json. No client-specific identifiers are embedded.
status / compliant — status is compliant | non-compliant | not-evaluated. Any present source
that is failing OR invalid ⇒ non-compliant. All sources absent ⇒ not-evaluated. Only when at least one
source was evaluated and none is bad ⇒ compliant. compliant (boolean) is strictly status === "compliant",
so an all-absent run is not a green — sources_evaluated/sources_total record the coverage an auditor reads.
- Integrity checksum: the bundle is canonicalized (deep, stable key sorting) with its
integrity field
removed and hashed with sha256; --verify recomputes and compares, exiting non-zero on mismatch. This is a
corruption-detecting checksum, not authenticity — anyone with write access can rewrite the content and
its hash, so a --verify PASS means "not accidentally corrupted", not "genuine". Cryptographic authenticity /
non-repudiation requires signing (GPG/cosign/Sigstore) — a documented seam, not built here.
- Immutability: a record for a SHA is written once; a re-run is a no-op unless
--force. index.json is
{ entries, integrity } — deduped by commit_sha and itself integrity-checksummed; a corrupt/tampered index
fails loudly rather than silently discarding prior entries.
Where the records live
.claude/attestations/<sha>.json (immutable, one per attested commit) and .claude/attestations/index.json
({ entries, integrity }, deduped + integrity-checksummed) are committed under the tracked .claude/ tree —
they are the durable evidence, so commit them. specs/reviews/ stays ephemeral and is not the evidence store.
Remapping to a real standard
Each control resolves a standard_ref from .claude/templates/standard-map.json — a neutral clause
taxonomy (by_id overrides by_axis; an uncovered axis is recorded unmapped). To emit the client's
real evidence format (e.g. a "Section 9" clause map), drop a project-level standard-map.json at the repo
root or .claude/; it overrides the template default and its id is stamped into the bundle's
standard_ref so the record says which map produced it. The map is data — no client literals live in code.
When authoring or editing this skill, follow docs/prompting-standards.md.
1---2name: attestation3description: Generate a per-commit, durable compliance attestation (with a sha256 corruption-detecting integrity checksum) from the harness control inventory, the branch-protection/deploy-gate verify outputs, the gate verdict, and the ratchet baselines — then commit the record. Use at /gate or in CI to produce committed evidence for a commit, or to --verify a stored attestation's integrity checksum. Remappable to the client's evidence format via standard-map.json.4---56# Compliance Attestation78Produces the harness's durable compliance evidence: a per-commit, SHA-keyed,9sha256-integrity-hashed attestation bundle committed under `.claude/attestations/`.10The per-run verdicts the harness already produces (`gate-receipt.json`, `quality-card.json`,11the Increment 2/3 `*-verify.json` outputs) are ephemeral — `specs/reviews/` and all `*.jsonl`12are gitignored, and the verify outputs overwrite in place with no commit SHA or timestamp. This13skill aggregates them into one committed record per commit that an auditor can read and re-check.1415## When to use1617- At `/gate` or in CI, after the verify/gate outputs for a commit exist, to write the committed18 evidence record — then commit `.claude/attestations/<sha>.json` and `index.json`.19- To re-check a stored attestation's integrity with `--verify <file>` (corruption detection —20 see the **Integrity checksum** bullet under *How it works* for what this does and does not prove).21- When a project must map the neutral clause taxonomy onto a real external standard.2223## Do not use2425- To provision branch protection or deploy environments — that is `/provision` (its `protection`26 and `environments` modes, Increments 2/3). This skill only *reads* their outputs.27- To change gate behavior. It is purely additive read-and-record; it never mutates `gate-receipt`,28 `quality-card`, or the verify outputs.2930## How it works3132```33node .claude/scripts/generate-attestation.js # write .claude/attestations/<sha>.json (+ index.json)34node .claude/scripts/generate-attestation.js --force # overwrite an existing record for this SHA35node .claude/scripts/generate-attestation.js --verify .claude/attestations/<sha>.json36node .claude/scripts/generate-attestation.js --json # print the bundle instead of a summary line37```3839- **Inputs** — three sources (branch-protection verify, deploy-gate verify, gate receipt), each classified40 fail-safe: `absent` (file missing ⇒ recorded `null`), `invalid` (present but unparseable or missing a41 boolean verdict ⇒ recorded `{invalid:true}` — never a silent pass), or `pass`/`fail`. Plus the control42 inventory + per-control clause from `harness-manifest.json`, the `.claude/state/*-baseline.*` ratchets,43 repo/commit from `git`, and the harness version from `package.json`. No client-specific identifiers are embedded.44- **`status` / `compliant`** — `status` is `compliant` | `non-compliant` | `not-evaluated`. Any present source45 that is failing OR invalid ⇒ `non-compliant`. All sources absent ⇒ `not-evaluated`. Only when at least one46 source was evaluated and none is bad ⇒ `compliant`. `compliant` (boolean) is strictly `status === "compliant"`,47 so an all-absent run is **not** a green — `sources_evaluated`/`sources_total` record the coverage an auditor reads.48- **Integrity checksum**: the bundle is canonicalized (deep, stable key sorting) with its `integrity` field49 removed and hashed with sha256; `--verify` recomputes and compares, exiting non-zero on mismatch. This is a50 **corruption-detecting checksum, not authenticity** — anyone with write access can rewrite the content and51 its hash, so a `--verify` PASS means "not accidentally corrupted", not "genuine". Cryptographic authenticity /52 non-repudiation requires signing (GPG/cosign/Sigstore) — a documented seam, not built here.53- **Immutability**: a record for a SHA is written once; a re-run is a no-op unless `--force`. `index.json` is54 `{ entries, integrity }` — deduped by `commit_sha` and itself integrity-checksummed; a corrupt/tampered index55 fails loudly rather than silently discarding prior entries.5657## Where the records live5859`.claude/attestations/<sha>.json` (immutable, one per attested commit) and `.claude/attestations/index.json`60(`{ entries, integrity }`, deduped + integrity-checksummed) are committed under the tracked `.claude/` tree —61they are the durable evidence, so **commit them**. `specs/reviews/` stays ephemeral and is not the evidence store.6263## Remapping to a real standard6465Each control resolves a `standard_ref` from `.claude/templates/standard-map.json` — a neutral clause66taxonomy (`by_id` overrides `by_axis`; an uncovered axis is recorded `unmapped`). To emit the client's67real evidence format (e.g. a "Section 9" clause map), drop a project-level `standard-map.json` at the repo68root or `.claude/`; it overrides the template default and its `id` is stamped into the bundle's69`standard_ref` so the record says which map produced it. The map is data — no client literals live in code.7071When authoring or editing this skill, follow `docs/prompting-standards.md`.