# Self Review

> Self-review after implementation - surface missed work, simplification opportunities, and idiomatic improvements

- Skill: `mahdtech/self-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mahdtech/self-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mahdtech/self-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: MAHDTech (https://skillmd.com/u/mahdtech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mahdtech/self-review

---


# Self-Review

Post-implementation reflection pass. Run after completing a task to catch loose ends and simplify before calling it done.

## Instructions

1. **Determine scope** - use the current branch diff unless the user specifies otherwise:
   - `git diff <base-branch>...HEAD --name-only` (the branch your work targets)
   - Fall back to staged changes if no branch diff exists
2. **Read all changed files in full** before reviewing.
3. **Answer each question below.** For every finding, cite `file_path:line_number` and fix it directly.
4. **If everything looks good**, say so briefly - don't invent busywork.

## Questions

### 1. Anything left undone?

- Are there TODOs, FIXMEs, or HACKs introduced in this diff that should be resolved now?
- Did you skip something the user asked for?
- Are there commented-out code blocks or placeholder values that shouldn't ship?
- Are there missing error cases, edge cases, or validations at system boundaries?
- Are there fallback/legacy code paths? If so, **ask the user explicitly** whether to keep, remove, or flag them - don't assume backward compatibility is wanted.

### 2. More idiomatic?

- Does the code follow the language's conventions and standard library patterns?
- Are there manual implementations of things the standard library or existing dependencies already provide?
- Does naming follow the project's existing conventions (check surrounding files)?
- Are there language-specific antipatterns? (e.g., Python: bare `except`, mutable default args; Go: exported names that shouldn't be; JS/TS: `any` types that should be narrowed)

### 3. More modular?

> Scope: this is a light post-diff pass over what you just changed. For a deeper, staged cleanup - untangling oversized modules, collapsing duplicated logic across the codebase, reducing engineering debt - reach for `/sculpt-code` instead.

- Are there functions doing more than one thing that should be split?
- Is there duplicated logic across the diff that should be extracted?
- Are responsibilities in the right files/modules, or did something land in the wrong place?
- **Counter-check:** Don't extract abstractions for one-time code. Three similar lines is fine.

### 4. Simpler?

- Can any code path be removed or collapsed? (dead branches, unreachable conditions)
- Are there over-engineered patterns? (unnecessary factories, abstractions with one implementation, config for things that won't change)
- Can complex conditionals be simplified or inverted for early returns?
- Is there defensive code for impossible states? (internal callers you control, framework guarantees)

## Output

For each question where you find something actionable:

- Show the finding with `file_path:line_number`
- Apply the fix directly
- One-line explanation of what changed and why

If nothing actionable is found, say: "Clean - nothing to follow up on."