audit
無料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.
日本語の概要は準備中です。原文の説明を表示しています。
Verify ticket completion criteria — use when finishing a ticket, before marking work done, or checking acceptance criteria. Runs tests, build, lint, scenarios, and dependency drift checks.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Prove a ticket meets its criteria. Works with or without an active ticket.
This skill is required at the done-gate (ticket 147). The line below appends a session-scoped entry to .safeword-project/skill-invocations.log so the done-gate hook can verify /verify was actually invoked. Bash injection runs at render time — hand-writing verify.md cannot produce this entry.
!PROJECT_DIR="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}" && mkdir -p "$PROJECT_DIR/.safeword-project" && echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) ${CLAUDE_SESSION_ID} verify" >> "$PROJECT_DIR/.safeword-project/skill-invocations.log" && echo "[skill-invocation-log] verify ✓" || echo "[skill-invocation-log] FAILED — done-gate will block"
If you see [skill-invocation-log] FAILED above, or no verify ✓ line at all: STOP. Do not run /verify manually — that line is the only proof the done-gate accepts. Report the failure to the user (most likely cause: Claude Code's bash permission denied the injection) and ask them to resolve it before re-invoking /verify.
# Find in_progress tickets, excluding epics
for f in .safeword-project/tickets/*/ticket.md; do
[ -f "$f" ] || continue
grep -q "^status: in_progress" "$f" && ! grep -q "^type: epic" "$f" && echo "$f"
done | head -1
If a ticket is found, read it to get:
parent: field (if any)If no ticket is found, skip scenario validation (step 3) and parent check (step 4).
Run these in sequence, reporting each result:
/lint to auto-fix style issues first# Full test suite
bun run test 2>&1
# Build check
bun run build 2>&1
The /lint command handles linting with auto-fix. Report any remaining unfixable errors.
.safeword-project/tickets/{id}-{slug}/test-definitions.md- [ lines- [x] linesIf any unchecked [ ] remain, list them.
If ticket has parent: field:
children: arraystatus:Compare package.json dependencies against ARCHITECTURE.md:
ARCHITECTURE.md does not exist, skip this checkARCHITECTURE.md contentpackage.json dependencies and devDependencies keys@scope/ prefix for matching — but check both full name and short name)ARCHITECTURE.md mentions the package name (case-insensitive)"Dependency \{name}` not documented in ARCHITECTURE.md"`Do NOT flag:
@types/* packages (type-only, not architectural)devDependencies that are tooling (eslint plugins, prettier plugins, test utils) — only flag deps that represent architectural choicesStructure the report in three sections, in this order. Empty sections are hidden entirely — no "None" placeholders, no empty headers.
The Status section uses the existing Verify Checklist format. Format with these EXACT patterns (the done-gate hook validates them):
## Verify Checklist
**Test Suite:** ✓ X/X tests pass (or ❌ N failures)
**Build:** ✅ Success (or ❌ Failed)
**Lint:** ✅ Clean (or ❌ N errors)
**Scenarios:** All N scenarios marked complete (or ❌ X/Y complete, or ⏭️ Skipped — no ticket)
**Dep Drift:** ✅ Clean (or ⚠️ N undocumented deps, or ⏭️ Skipped — no ARCHITECTURE.md)
**Parent Epic:** {id} (siblings: X/Y done) or N/A
**Reconcile:** ✅ No pattern deviation (or ⚠️ N deviations, M missing uplevel ticket — soft, never blocks)
Reconcile is soft — it never blocks the done gate. If the work introduced a pattern that diverges from existing siblings (see .safeword/guides/architecture-guide.md → Survey & Reconcile), confirm the ticket carries a reconcile record and every deviation has an uplevel follow-up ticket; flag any that don't. Use N/A when the work conformed or introduced no new pattern.
Done-gate evidence patterns (the stop hook validates these literal phrases — do not move or rename):
✓ X/X tests pass — proves test suite ranAll N scenarios marked complete — proves scenarios checkedAudit passed — proves /audit ran (run /audit separately)Without all three patterns in Status, the done phase will hard block.
Only include this section when there are spec, scope, or value questions the USER must answer.
Implementation-path questions (which approach, which pattern, which library) do NOT go here — they belong in "Agent's next actions" because the agent owns implementation choices.
Borderline classification examples:
Hard cap of 5 items per section. If more exist, list the top 5 (most load-bearing) and add:
- N others, see test-definitions.md
Decisions section is hidden when empty — no "None" placeholder. Do not surface the section at all if zero decisions exist.
Only include this section when there are concrete forward actions the agent will take. Each action must be concrete and falsifiable — not vague exploration ("look into X"), but a specific verb + object the agent will execute ("add integration test for R7.3 covering 404-on-uncovered-PATCH").
Hard cap of 5 items per section. If more exist, list the top 5 and add:
- N others, see test-definitions.md
Actions section is hidden when empty — no "None" placeholder.
When all Status checks pass AND zero decisions AND zero actions, collapse the entire report to a single-line verdict:
Ready to mark done.
No sections, no ceremony. Single line.
This command verifies ticket criteria (the done gate). Use it before marking any feature ticket complete. It also works without a ticket for quick project health checks (tests + build + lint + dep drift).
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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.
日本語の概要は準備中です。原文の説明を表示しています。