Menu
Self-review your own work before committing. Fight entropy, ensure quality, leave the codebase better than you found it.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | self-review |
| description | Self-review your own work before committing. Fight entropy, ensure quality, leave the codebase better than you found it. |
| disable-model-invocation | true |
| allowed-tools | ["Read","Edit","Glob","Grep","Bash","Agent"] |
You just finished some work. Before committing, step back and review it with a critical eye.
The goal is NOT to rubber-stamp what you did. The goal is to catch the shortcuts, the entropy, the "good enough" choices that erode a codebase over time. Every quick fix has a cost in maintainability. Fight that.
Gather all changes. Run git status to see the full picture — staged, unstaged, and untracked files. Then run git diff for unstaged changes, git diff --cached for staged changes, and read any new untracked files. Read every changed file fully — not just the diff hunks, but the surrounding context.
Read the quality standards. Read these docs and review your work against each one:
docs/engineering/contributing/quality/code-quality.mdxdocs/engineering/contributing/quality/documentation.mdxdocs/engineering/contributing/quality/testing/index.mdxdocs/engineering/contributing/quality/testing/unit-tests.mdxdocs/engineering/contributing/quality/testing/integration-tests.mdxdocs/engineering/contributing/quality/testing/anti-patterns.mdxFix violations. For every violation you find, fix it — don't just report it. If a fix would be too large or risky, flag it explicitly with what's wrong and why you're not fixing it now.
Fight entropy. Look at the code you touched and the code around it. Did you leave it better than you found it? Did you introduce complexity that isn't justified? Did you take a shortcut that a future reader will curse? If something nearby is already broken or messy and your change made it worse or left it as-is when a small improvement was obvious, fix it.
Look for refactoring opportunities. Actively ask yourself: what can be refactored in or around the code you touched to make it easier to maintain long term? Duplicated logic that should be extracted, unclear abstractions that should be simplified, tangled responsibilities that should be separated. Don't just preserve the status quo — improve it.
Report. After fixing everything, give a brief summary of what you changed and what you flagged.
Before you're done, ask yourself the three questions from the quality guide:
If any answer is no, go back and fix it.
Generate or update CLI commands in cmd/api/ from the OpenAPI spec and Go SDK. Use when the API spec changes or new endpoints are added.
Write or review UX microcopy for dashboard interfaces. Use when reviewing button labels, errors, empty states, dialogs, helper text, tooltips, toasts, onboarding, or any user-facing product copy.
Structural refactoring pass on changed code. Use after implementing a feature to improve code structure, reduce duplication, and clean up APIs without changing behavior.
Use this skill when writing, editing, reviewing, or improving documentation in this repository. Activates for tasks involving content in `docs/product/` or `docs/engineering/`, MDX/Markdown files, or any documentation-related request.
Reviews restate handler code in svc/ctrl/worker to find restate client calls (service calls, state access, sleep, etc.) incorrectly placed inside restate.Run, restate.RunVoid, or restate.RunAsync closures. Use when reviewing restate handlers, checking restate.Run usage, or auditing worker service code.