Human Checkpoint

A checkpoint is consent, not a formatting step. It binds a named human Decision to the exact Artifacts and constraints reviewed before execution may continue.

Inputs

• DECISIONS.md.
• UNITS.csv and STATUS.md for the active checkpoint.
• Artifacts declared by the locked Pipeline for that checkpoint.

Outputs

• Updated DECISIONS.md.
• A checkpoint Decision in the Run ledger.

Steps

1. Identify the pending checkpoint

Inspect STATUS.md, UNITS.csv, and the active runner message. Select the first blocked HUMAN Unit and its C* identifier. If multiple checkpoints appear active or the checklist is missing, stop and repair the projection before approving anything.

Completion criterion: exactly one pending checkpoint and its owning HUMAN Unit are identified.

2. Review the declared Artifacts

Read the locked Pipeline's checkpoint contract and inspect every named Artifact. Record requested constraints or scope changes in the checkpoint block before approval; do not silently modify reader-facing content as part of sign-off.

Completion criterion: the reviewer can name the Artifacts inspected and any constraints attached to the Decision.

3. Record approval through the adapter

Use the Pipeline adapter so the Markdown checkbox and machine Decision ledger remain synchronized:

uv run python scripts/pipeline.py approve \
  --workspace workspaces/<name> \
  --checkpoint <C*>

Do not infer approval from chat silence, a completed Artifact, or an existing but unchecked checklist item.

Completion criterion: DECISIONS.md contains [x] Approve C* and the Run ledger records checkpoint.approved for the same checkpoint.

4. Hand execution back to the Runner

Resume through the Pipeline adapter. The Harness may complete the HUMAN Unit and expose the next eligible Unit; this Skill does not execute downstream semantic work itself.