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.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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.
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.
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:
When I…, I want…, so I can…), not a restated feature.out_of_scope line — no
silent scope creep, no orphan capability.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.
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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Run comprehensive code audit for architecture, dead code, and test quality. Use when reviewing overall codebase health, checking for architectural violations, or before marking a feature complete.
The English summary is being prepared. Showing the original description.
Behavior-first feature development — use when building new capabilities, continuing feature work, or when work introduces new state or multiple user flows. Discovers desired behavior through examples and scenarios before implementation. Do NOT use for bug fixes, typos, or small isolated changes.
The English summary is being prepared. Showing the original description.
Use when the user wants to explore options, weigh approaches, or think through uncertainty before committing to a direction. Collaborative brainstorming and rubber ducking — divergence-first thinking partner.
The English summary is being prepared. Showing the original description.
Kill zombie dev servers and test processes. Use when ports are blocked, processes are hanging, or test runners won't start.
The English summary is being prepared. Showing the original description.
Root cause debugging before fixes. Use when investigating bugs, diagnosing test failures, troubleshooting unexpected behavior, or when previous fix attempts failed. Enforces investigate-first discipline.
The English summary is being prepared. Showing the original description.
Extract tacit knowledge through non-obvious microquestions — things only the user knows that can't be found in code, docs, or research. Use when you're about to guess at intent, context, or constraints during SAFEWORD's understanding flow. Also use when user says 'ask me', 'what do you need to know', or when another skill (bdd, brainstorm, debug) needs user context before proceeding. Do NOT use for questions answerable by reading the codebase or searching the web.
The English summary is being prepared. Showing the original description.