self-review

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.

Stakes set depth. Tier 2 may never run — review as if your stamp is the last word before code gets built on this spec, because often it is. Cheap floor means fast, not shallow.

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 skill-invocations.log under the project namespace root, 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 no [skill-invocation-log] ... ✓ line appears above, run this fallback before stopping:

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

The review stamp is content-bound and uses the normalized runtime identity.

If the automatic line and fallback both print [skill-invocation-log] FAILED, or still do not print ✓: STOP. The stamp was not written and the gate will keep blocking. Most likely the bash injection was denied, no in_progress ticket was found, or Bun could not run the installed helper — 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 numbered Rule (or legacy Acceptance Criterion) stating an observable, product-level invariant — not an implementation detail.
• The criteria 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 --skip "<why this spec needs no review>"

Skip is the explicit --skip flag, quoted as one argument — free text after the artifact is rejected, and an empty reason does not clear the gate.