git-signoff✓

Git Signoff Attestation

The AI wrote it.
A human answers for it.

git-signoff flips code review: before an AI-assisted diff merges, the agent interviews you — then records who understood what, when, at exactly which state of the code. Machine-parsable and tamper-evident, inside your git history.

[SIGNOFF 979cb45]: human comprehension
and risk attestation

Signoff-Status: VERIFIED_BY_HUMAN
Signoff-Reviewed-Commit-SHA: 979cb45…
Signoff-Reviewed-Tree-SHA: 7ef0eac…
Signoff-Transcript-Digest: sha256:1675b6…
Signoff-Tradeoff: Notes ref recovery
  deferred to CI
Signoff-Risk: Squash merges rely on
  tree-SHA fallback
Signoff-Verified-By: you@lab.edu
Signoff-Agent: harness=claude-code/2.x
  interview=standard/domain-science
01

A reverse interview, not a rubber stamp

Run /git-signoff from the branch you want to merge. The agent reads the full diff, then asks you a short series of pointed questions across four fixed axes. Vague answers don’t pass: hand-waving pauses the signoff, the agent explains the mechanics, and re-probes with a concrete scenario.

The goal is preventing cognitive surrender — merging AI output nobody actually understands. Intentional trade-offs pass, once you show you understand their boundaries and own their risks.

AXIS 1Mechanics & intent

What changed, and why this design over the alternatives?

AXIS 2Trade-offs & edge cases

What approximations were made — and are they intentional?

AXIS 3Boundaries & failure loudness

Where does it break, and does it break loudly or silently?

AXIS 4Ownership

Do you explicitly accept responsibility for results and risks?

For software engineers

The default profile probes algorithmic complexity, data-structure invariants, and API contract changes — the places engineering diffs fail.

For scientists & researchers

Research code rarely crashes; it produces plausible-but-invalid results. A unit slip between hPa and Pa, an emulator that quietly leaks energy, a trend that vanishes at higher resolution. Any diff touching scientific computation automatically triggers probes on units, numerical stability, statistical validity, and reproducibility. git-signoff never claims the science is right — it verifies that you know the assumptions and validity regimes. That’s the part a human must own.

02

A record that outlives the branch

When you pass, a small standard-library helper shipped with the skill (attest.py) — not the agent — writes an empty signed commit plus a mirrored git note (refs/notes/signoff) carrying flat, machine-parsable trailers: the reviewed commit and tree SHAs, the acknowledged trade-offs and risks, a SHA-256 digest of the interview transcript, your identity, and exactly which question set you were held to. The helper snapshots the transcript once, refuses a transcript that does not carry this conversation’s approval marker for this exact commit, derives the status from the bytes, and runs the verifier on its own output before it reports success.

Verification survives squash merges and branch deletion via the reviewed tree SHA and the notes mirror. The protocol — the Git Signoff Attestation (GSA) spec — is open, harness-, model-, and vendor-neutral: any tool can produce or verify attestations, and the record lives in your repository, not on anyone’s server.

It does not claim unforgeable proof of cognition, and it does not claim the code is correct. It claims something auditable: a named human demonstrated comprehension and accepted accountability — and here is the tamper-evident trail.

03

Auditing & retrieving interview transcripts

Git signoff attestations bind the interview transcript's SHA-256 digest into immutable git history and notes. Transcripts remain locally on the reviewer's machine for privacy. Anyone — leads, reviewers, compliance officers — can verify or audit the transcript at any time using a simple three-step loop.

Step 1: Auditor requests interview transcript snapshot

The auditor spots the attestation on the commit or PR and asks the employee or reviewer to export the session transcript for verification.

Step 2: Reviewer exports transcript snapshot

On the machine where the signoff interview took place, the reviewer runs the verifier with --audit and --export to extract the exact byte snapshot:

python3 .claude/skills/git-signoff/verify_signoff.py --audit HEAD --export transcript.jsonl

The verifier verifies that the local session transcript matches the commit's Signoff-Transcript-Digest and writes the snapshot to the target path.

Step 3: Auditor verifies snapshot against git trailers

The reviewer sends transcript.jsonl to the auditor. The auditor verifies the received transcript against the git trailers:

GIT_SIGNOFF_TRANSCRIPT_FILE=transcript.jsonl python3 .claude/skills/git-signoff/verify_signoff.py --audit HEAD

Output confirms the transcript digest matches byte-for-byte:

✅ VALID MATCH: Transcript SHA-256 matches sha256:1675b6...
  Harness: claude-code
  Conversation ID: 979cb45-session
  Bytes verified: 8432
  Exported snapshot to: transcript.jsonl
04

Install: one folder, committed to your repo

The skill lives in the repository under review — no plugins, no downloads, nothing account-scoped. Then, from the branch you want to merge, type /git-signoff (adaptive default auto-selects intensity; --deep for skeptical rigor, --quick for low-risk diffs).

Want to understand the change first? Copy the same skill folder and run /git-signoff --explain for a guided walkthrough, or /git-signoff --practice for rehearsal with hints and an advisory scorecard. No PR, workflow, badge, or attestation is required. Local learning includes tracked uncommitted work and reports excluded untracked files. Explanation can precede a real interview on request; practice requires a fresh conversation before real signoff.

Any repository — zero-touch

The initializer vendors the skill into .claude/skills/git-signoff/ or .agents/skills/git-signoff (use --skill-target {auto,claude,agents,both} to control destinations), scaffolds the CI gate and interview profile, and opens a ready-to-merge branch.

# standard software engineering profile:
curl -fsSL https://raw.githubusercontent.com/jerrylin96/git-signoff/init-v10/init.py -o /tmp/signoff-init.py && python3 /tmp/signoff-init.py

# scientific & research computing profile (math, physics, bio, climate, ML):
curl -fsSL https://raw.githubusercontent.com/jerrylin96/git-signoff/init-v10/init.py -o /tmp/signoff-init.py && python3 /tmp/signoff-init.py --profile domain-science

Any repository — manual

Copy skills/git-signoff/ to <your-repo>/.claude/skills/git-signoff/ and commit. That is the whole install for Claude Code — CLI, desktop, and claude.ai web/cloud sessions, for every collaborator.

Other harnesses — Antigravity, Codex, Goose, …

The skill is one self-contained folder — the interview prompt plus two standard-library Python files, nothing to install: copy skills/git-signoff/ into your harness’s skill location and set the transcript adapter env vars. Full matrix in HARNESSES.md.

05

Make the interview yours

The four axes are fixed for everyone. What you customize is the interview profile — a single delimited text block that weights the questions toward your domain’s failure modes. Profiles can add emphases but can never remove axes or lower pass criteria: a customized interview is never a weaker one.

🔬 For Scientists, Physicists, Mathematicians & ML Researchers

Research code fails differently: it rarely crashes; it produces plausible-but-invalid science. Standard software engineering questions (O(N log N) complexity, API contracts, thread safety) will not catch energy drift, subtle dimensional slips, uncorrected multiple testing, or data leakage across spatial folds.

Use the shipped domain-science profile or follow the scientific profile authoring guide with ready-to-use templates for fluid dynamics, bioinformatics, neural surrogate models, and numerical analysis.

# scaffold a scientific profile in .git-signoff/profile.md:
curl -fsSL https://raw.githubusercontent.com/jerrylin96/git-signoff/init-v10/init.py -o /tmp/signoff-init.py && python3 /tmp/signoff-init.py --profile domain-science
  1. Create .git-signoff/profile.md in your repo

    The repository being reviewed carries its own question emphasis — for every collaborator, on every harness, surviving skill updates.

  2. Start from a shipped profile or discipline template

    Paste in domain-science (research code) or software-general (classic engineering) — or adapt a discipline template from the authoring guide to name your failure modes: conservation properties of a new parameterization, grid-resolution sensitivity of a reported trend, leakage between reanalysis training and evaluation periods.

  3. Done — provenance is automatic

    Every attestation records which question set actually ran, with a content digest for repo-supplied profiles — so a diluted profile is always distinguishable from a shipped one.

    # in the attestation trailer:
    Signoff-Agent: … interview=standard/your-lab-id/sha256:5fd075753d5b
06

Show your work is answered for

A two-minute CI check verifies GSA attestations against your repository’s history: pull requests fail until the branch ends in a valid attestation, and your README carries the badge.

attested by humanspassing Green means: a named human understood this code and accepted accountability — no more, no less.
# .github/workflows/git-signoff.yml
name: attested by humans
on:
  pull_request:
  push: { branches: [ main ] }
permissions: { contents: read, pull-requests: read }
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - uses: jerrylin96/git-signoff/verify@verify-v1.7

The verifier is a single dependency-free Python file — copy it into any CI system. Details: verify/.