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.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
Kill zombie dev servers and test processes. Use when ports are blocked, processes are hanging, or test runners won't start.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。