/self-review

name: self-review
description: Use when about to commit, finish a task, open a PR, summarize work for the user, or when the user asks for a review or summary — NOT just on autonomous commits, which are rare in OpenCode usage

Pre-Commit Self-Review

Overview

**Pause and read what you wrote as a stranger would before claiming completion.** This skill covers review of your own work. For domain-specific review of any code (security, correctness, API quality), invoke the matching domain skill.

Run the checklist in order. If you can't satisfy a step, fix it or call it out in your summary.

When to invoke

Invoke when you're about to:

• Run `git commit` (autonomous or otherwise)
• Tell your human partner "I'm done" or "ready for review"
• Open or update a pull request
• Summarize a chunk of work, hand off to another agent, or close out a task
• Be asked by your human partner to review, sanity-check, or hand off the change

In OpenCode and similar agent harnesses, commits are usually initiated by the user, not the agent. The trigger is therefore **the moment of completion**, not specifically the moment of `git commit` — whichever comes first.

Non-triggers — do NOT invoke for

• Mid-implementation edits: this skill fires at the end of a unit of work, not in the middle of one
• Single-line fixes — typo, comment, formatter-only change — where there is no review surface
• Exploratory or read-only tasks (reading code, answering a question, writing a summary with no code change)
• Routine save points during a long task where you are not yet claiming completion
• Reverts and mechanical undo operations

If the change is small but introduces real logic, **invoke anyway** — the checklist is short.

Self-review checklist

Run every step before you commit, hand off, or claim completion.

1. **Re-read the diff as a stranger, and scan ±20 lines around every hunk for unsafe code.** Open the diff fresh and read it top to bottom without context. If a section needs you to remember what you were thinking yesterday to make sense of it, the next reader will not have that memory — rename, comment, or restructure until the diff explains itself. Then, in the same pass, read the **20 lines above and below each hunk** in every touched file and look for these six unsafe patterns in the surrounding code, whether or not your change introduced them:

• **Hardcoded credentials.** String literals that look like API keys, OAuth client secrets, database passwords, JWT signing secrets, bearer tokens, private keys (`-----BEGIN`), or connection strings with embedded passwords — assigned to a variable, passed as an argument, or written into a config file.
• **String-built SQL, LDAP, or shell commands.** F-strings, `+` concatenation, or `.format()` building a query/command string with interpolated values; `subprocess.run(..., shell=True)` with non-constant input.
• **Unsafe deserialization on untrusted input.** `pickle.loads`, `yaml.load` without `SafeLoader`, `marshal.loads`, Java `ObjectInputStream`, PHP `unserialize`, .NET `BinaryFormatter` against data that crosses a trust boundary.
• **Swallowed exceptions.** Broad `except:` / `except Exception:` / `catch (Throwable)` blocks with `pass`, an empty body, or a comment-only body — the call site silently absorbs failures the caller cannot see.
• **TOCTOU patterns.** Check-then-use against the same path or resource (`if os.path.exists(p): open(p)`, `if user.has_permission(x): do(x)`) where the state can change between check and use.
• **Mutable default arguments.** `def f(x=[])`, `def f(x={})`, `def f(x=set())` — the default is shared across calls and accumulates state.

**Test fixtures, mocks, and example values inside `tests/`, `test_*.py`, `*.spec.*`, `fixtures/`, or files with names containing `mock`, `fake`, or `stub` are intentional test data, not unsafe code.** Skip them.

When you find one of these in the surrounding code (not in your diff), **surface it in your summary to the user — do not silently rewrite the file outside the scope you were asked to change.** Add an `Adjacent issues` line to your summary naming the file, line, and pattern (e.g. `Adjacent issues: src/billing/charge.py:142 — string-built SQL with f-string interpolation`). If the scan finds nothing, leave the line out. *(Rising, 97/58.)* 2. **Suspect your own code first.** Before you blame the framework, the library, or the flaky test, assume the bug is yours. It almost always is. Walk the code path with the failing input in mind; confirm assumptions about types, ordering, null cases, and shared state. Reach for "compiler bug" only after you have ruled out yours. *(Kelly, 97/9.)* 3. **Know what your next commit is.** State, in one sentence, what this commit does. If the sentence contains "and also" or "various", the commit is two commits. Split it. If you cannot name a clear, bounded change, you are committing speculation — throw the speculative parts away and re-scope. *(Bergh Johnsson, 97/47.)* 4. **Check for deliberate technical debt.** Did you take a shortcut to ship? Name it. File a follow-up note (issue, todo, line in your summary) so the debt is visible. Untracked debt accrues silent interest. *(Rose, 97/1.)* 5. **Clean the build before you leave it.** New compiler warnings, lint errors, or deprecation notices introduced by this change get fixed now, not later. A noisy build hides the warning that actually matters. *(Brodwall, 97/42.)* 6. **Audit the logs you added.** Every new log line: is its level right? Will it fire once per significant event, or per inner-loop iteration? Would you want to be paged for an ERROR-level message you wrote? If not, downgrade it. *(Brodwall, 97/90.)* 7. **Re-read the comments.** Header comments should let the next reader use the code without reading the body. Inline comments should explain *why*, not narrate *what*. Delete comments that have drifted from the code. Never paste anything into a comment you would not want quot