Skip to content
Back to skills

Self Review

ASecurity

Use when finishing spec.md before writing test-definitions.md, or

  • 19 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 4, 2026
toolsgobashgit

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add TheMostlyGreat/mythos --skill self-review --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Self Review?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Self Review
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/themostlygreat-self-review/badge)](https://www.skillsdirectory.com/skills/themostlygreat-self-review)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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:

```bash
bun .safeword/hooks/write-review-stamp.ts spec "<why this spec needs no review>"
```

An empty reason does not clear the gate.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…