| name | self-review |
| description | Use when finishing spec.md before writing test-definitions.md, or when the review gate asks for a spec review — self-reviews the just-authored spec inline and earns its Tier 1 review stamp. Your own inline pass; do not spawn a sub-agent. |
| allowed-tools | * |
Self-Review
Review the artifact you just authored, then earn its review stamp so the next
step is unblocked. This is Tier 1 — a cheap, inline floor. You review your
own work; no sub-agent is spawned. The independent check is Tier 2 (the fork
review at each phase exit), not this.
Earn the stamp
The line below runs the stamp-earning step at render time. It binds a
review:<scope> stamp to the active ticket's spec.md at its current
content and appends it to .safeword-project/skill-invocations.log, where the
per-asset gate reads it back. Invoking this skill is what writes the stamp —
hand-editing the log is the gameable floor this tier deliberately accepts.
!PROJECT_DIR="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}" && CLAUDE_PROJECT_DIR="$PROJECT_DIR" bun "$PROJECT_DIR/.safeword/hooks/write-review-stamp.ts" spec
If you see [skill-invocation-log] FAILED above, or no ✓ line at all: STOP.
The stamp was not written and the gate will keep blocking. Most likely the bash
injection was denied or no in_progress ticket was found — report it to the user
and resolve before retrying.
Review the spec (do this now, with the stamp written)
The stamp records that a review was invoked; the actual scrutiny is yours. Read
the active ticket's spec.md and check, against personas.md and the ticket's
scope / out_of_scope frontmatter:
- Every JTBD resolves to a real persona and reads as a genuine job (
When I…, I want…, so I can…), not a restated feature.
- Each JTBD carries ≥1 Acceptance Criterion stating an observable, product-
level guarantee — not an implementation detail.
- The ACs cover the ticket's scope and stop at its
out_of_scope line — no
silent scope creep, no orphan capability.
- Nothing leaks implementation (file names, function names, libraries) into
spec-level prose.
If the review surfaces a fix, edit spec.md and re-invoke /review — the
content-bound stamp goes stale on any edit, so the gate correctly re-blocks
until the corrected spec is re-reviewed. That is the point: a review that
changes the artifact must be re-earned.
Skip valve
If the artifact is genuinely trivial to review (boilerplate, a docs-only
change), log a skip with a reason instead of a review — it clears the same gate
and records why:
bun .safeword/hooks/write-review-stamp.ts spec "<why this spec needs no review>"
An empty reason does not clear the gate.
