check-yourself

Files (1)

• SKILL.md

SKILL.md (first lines)

# Check Yourself

Run this at every task-boundary event in a multi-step workflow.

## Explicit Trigger Enumeration

Invoke after each of these events — not "proactively when it feels right":

- A step in a multi-step plan is marked complete.
- A dispatched subagent returns (DONE / DONE_WITH_CONCERNS / BLOCKED).
- A Skill-tool invocation returns.
- A `/proceed` gate is passed. **Every literal `/proceed`** — not "every
  conceptual section." If 4 `/proceed`s arrive across parts of one section,
  that's 4 boundaries, not 1. Back-to-back `/proceed`s without an intervening
  `/check-yourself` = overdue; invoke before responding to the second one.
- A test-run (pytest / ruff / uv run) completes.
- A file-write lands on a durable artifact (spec, plan, SKILL.md, CHANGELOG).

If any of the above happened since the last `/check-yourself`, invoke now.
System-reminders about stale task tracking are a sign you are overdue — don't
batch the catch-up, run the skill each boundary.

## Steps

**Pre-step — re-verify stale external state.** If the boundary's reflection
depends on external state read earlier in the session (git status, test counts,
file sizes, staging state), re-run the underlying tool call first — don't trust
the earlier snapshot. Numbers decay, especially when a human collaborator is
active in parallel.

1. **Update the task list.** Display the current ` ◼` / ` ✔` task list (at the
   bottom) to the user in the terminal, marking off whatever was just completed.
   If no task list exists yet, create one from the current plan.
   - Some sessions gate `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` off
     the tool surface entirely (a GrowthBook experiment flag; legacy `TodoWrite`
     can be absent too). When those tools are absent, "the current task list" is
     whatever Markdown ◼/✔ list or table the agent is already maintaining by
     hand — Step 1 still applies the same way, just against that Markdown state
     instead of a tool call. State once, the first time you notice the tools are
     gone, that you're tracking state in Markdown instead; don't repeat the
     caveat at every later boundary.

2. **Run /remember.** Invoke the `remember` skill to save session state for
   clean continuation.
3. **Run /checkpoint-save.** Invoke the `checkpoint-save` skill to persist
   resumption context.
4. **Update core repo docs.** Update `README.md`, `CHANGELOG.md`, `ROADMAP.md`,
   etc. as appropriate and, especially, if the files already exist and/or the
   changes are extensive and/or the project/effort is lengthy/sizeable.

- Use existing docs' style(s), or otherwise best practices in the appropriate
  SWE discipline(s).

5. **Verification-before-completion (conditional — skip unless ALL three
   hold).** Invoke `superpowers:verification-before-completion` **only** at a
   shipping-ready boundary, not at mid-flight boundaries. The trigger is
   objective, not a feeling.

   Run these checks in order. If any fails, **skip this step** and do not invoke
   `superpowers:verification-before-completion`:

   ```
   a. `git status` — nothing unstaged and no untracked files related to the
      active work (ignored files are fine).
   b. `git log origin/<current-branch>..HEAD` — empty output (all local
      commits are pushed). If the branch has no upstream, this check fails
      by default: push first, or skip.
   c. The current boundary is a "claim complete / ship" boundary: PR is
      about to be opened, or user has said work is done, or implementation
      is being declared finished. Mid-iteration test passes do NOT qualify.
   ```

   If all three hold → invoke `superpowers:verification-before-completion`.
   Otherwise skip silently; it will fire on a later `/check-yourself` once the
   work actually reaches the shipping boundary.

   **Why conditional:** the trigger enumeration above fires many times per task
   (every test-run, every durable file-write). Running
   verification-before-completion at every such boundary is noise and defeats
   the "before completion" semantics. The gate is whether the work has
   physically reached a ship-able state — staged, committed, pushed — not
   whether it subjectively feels done.

6. **Print resume footer (conditional — pause boundary only).** Step 3 always
   runs `/checkpoint-save`, so `/checkpoint-save`'s own Step 8 footer prints
   once on every `/check-yourself` invocation. **Re-printing the footer at the
   very end of `/check-yourself` is gated narrowly to pause boundaries** —
   otherwise the footer floods every test-run / subagent-return / file-write
   boundary, which is exactly the noise the "skip at non-pause boundaries" rule
   below forbids.

   **Gate:** print the footer here only if the triggering boundary was a
   `/pause` invocation. Concretely, scan the most recent user turn for any of
   these signals:
   - The literal token `/pause` (slash command).
   - A `<command-name>/pause</command-name>` block (CLI-injected).
   - A `Skill(skill="pause")` invocation in the parent agent's recent tool
     calls.

   If none match, **skip Step 6 entirely** — `/checkpoint-save`'s mid-response
   footer is sufficient at non-pause boundaries.

   When the gate fires, print at the very bottom of `/check-yourself`'s output
   (after the pause summary table):

   ````markdown
   **Next session, from a fresh terminal:**

   ```bash
   cd <ABSOLUTE-PATH-TO-CWD>
   ```

   Then in Claude Code:

   ```
   /checkpoint-resume
   ```

   Fallback if it doesn't auto-trigger: `Resume from CHECKPOINT.md`

From laurac8r/claude-damn, MIT.

More from laurac8r/claude-damn