Self Review
- 6 installs
- 251 repo stars
- Updated August 4, 2026
- fredrikaverpil/dotfiles
Performs an end-to-end self-review of recently implemented work, evaluating changed files for placement, simplicity, DRY, YAGNI, and maintainability.
About
Prompts a critical self-review of recent implementation by re-reading all changed files and evaluating them against criteria like simplicity, DRY, YAGNI, idiomatic style, and robustness. A developer invokes it when done implementing to catch issues and fix them before finishing.
- Reviews full file context, not just diffs
- Fixes issues found and summarizes the review
Self Review by the numbers
- 6 all-time installs (skills.sh)
- Ranked #870 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/fredrikaverpil/dotfiles --skill self-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 6 |
|---|---|
| repo stars | ★ 251 |
| Last updated | August 4, 2026 |
| Repository | fredrikaverpil/dotfiles ↗ |
What it does
Performs an end-to-end self-review of recently implemented work, evaluating changed files for placement, simplicity, DRY, YAGNI, and maintainability.
Files
Self-Review
Go back and critically review your recent implementation end-to-end. Read through all changed files and evaluate the work as a whole.
Review criteria
- Placement: Was the change made in the right place architecturally? Does it
fit naturally into the existing structure?
- Simplicity over cleverness: Prefer simple, explicit code over clever,
implicit solutions. If something requires a comment to explain _why_ it's written that way, it's probably too clever.
- DRY: Did the change introduce redundant duplication? Is there existing
code that already handles this or could be reused?
- YAGNI: Was anything added that isn't needed right now? Remove speculative
abstractions, unused parameters, and premature generalization.
- Idiomatic code: Does the code follow conventions of the language,
framework, and ecosystem? It should look like it belongs in the codebase.
- DX and UX: Is the change pleasant to use from both a developer and
end-user perspective? Are APIs intuitive? Are error messages helpful?
- Consistency: Does the change follow the patterns already established in
the project? A consistent codebase is more important than a locally "better" approach.
- Maintainability: Will this be easy to understand and modify six months
from now by someone unfamiliar with the change?
- Robustness: Is the code brittle or potentially buggy? Look for edge cases,
race conditions, or assumptions that could break.
Process
1. Identify all files you changed in this session 2. Re-read each file in full context (not just the diff) 3. Evaluate against the criteria above 4. If you find issues, fix them 5. Summarize what you reviewed and any changes made
$ARGUMENTS
Related skills
Improve Codebase ArchitectureSafely deepen clusters of shallow modules into cohesive, testable units while respecting their external dependencies.566k196k
Caveman ReviewGet ultra-compressed, one-line code review comments that cut noise while keeping every actionable fix.270k94.7kCodebase DesignShared vocabulary for designing deep modules: improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable.266k196kCavecrewDelegate coding tasks to specialized subagents that return compressed output, keeping the main context window usable for much longer sessions.220k94.7kCode ReviewReviews a branch or PR diff on two axes at once: conformance to coding standards plus a code-smell baseline, and whether it actually implements the original spec.201k196k
Requesting Code ReviewDispatch a consistent, high-signal code reviewer subagent that catches plan deviations and quality issues before merging or continuing development.183k264k