| name | cleanup-web |
| description | End-of-session cleanup pass for TypeScript, React, and web code. Use this skill whenever the user asks to "clean up", "polish", "tidy", "refactor", or "review" web/frontend work at the end of a coding session, or when they invoke this skill by name. Performs a holistic review of files modified during the session — simplification, type safety, React patterns, CSS modernization, and comment hygiene. Make sure to use this skill anytime the user signals they want to wrap up or finalize TypeScript/React/web work, even if they don't explicitly say "cleanup". Do NOT use for one-off edits, bug fixes, or active feature work. |
Evaluate the work done in this session and refactor it to a pristine state.
Disposition
- Propose, don't apply. Surface proposed changes with clear reasoning and evidence — show before/after, name the principle that motivates the change, and wait for approval before any edits land.
- No changes is a valid outcome. If the code is already clean, say so and stop. Do not invent work to justify the pass.
Scope
Operate only on files modified during this session. Use git status, git diff, your task log, or recent tool calls to identify them. Do not touch unrelated code.
If you can't identify the session's modified files with confidence, stop and ask.
Review skills
Each skill below represents a review lens. Every lens gets its own sub-agent.
| Lens | Skill | Focus |
|---|
| Simplification | simplify | Dead code, needless abstractions, unused params, over-engineered utilities, and helpers whose names do not add meaning. Do not inline single-use helpers that clarify call sites or hide non-trivial conditions. |
| TypeScript | typescript | Type soundness, pragmatic generics, discriminated unions over type assertions, unknown over any |
| Type-driven design | parse-dont-validate | Push checks into types; make invalid states unrepresentable; branded types where warranted |
| React effects | no-use-effect | Derived state over effects, event handlers over sync effects, key-resets over effect-driven resets, useSyncExternalStore over manual subscriptions |
| React performance | vercel-react-best-practices | Component boundaries, use client / use server placement, data fetching patterns, bundle impact, memoization |
| CSS | modern-css | Native CSS over JS workarounds, logical properties, container queries, modern selectors, no legacy hacks |
| Comment hygiene | code-comments | Strip "what" comments and AI narration; keep "why" comments only |
| Correctness | adversarial-review | Behavior changes, dropped guards or edge cases, async/effect timing, server/client boundary, stale callers — bugs the session introduced |
Approach
Dispatch one sub-agent per review lens, all in parallel. Each sub-agent:
- Loads its skill via the Skill tool — this is required before any review work
- Reads the diff — use
git diff (and git diff --cached if needed) to get the session's changes
- Reviews only through its own lens — do not duplicate another lens's concerns
- Returns structured findings — for each finding: file + location, the proposed change with before/after, the principle behind it, and the trade-off if any. If nothing warrants changing for this lens, say so and return empty findings.
Sub-agent prompt template (adapt the lens name and skill name per row):
You are reviewing TypeScript/React/web code changes from this session through the {lens} lens.
First, load the {skill} skill using the Skill tool — read it fully before reviewing.
Then run git diff to see what changed. Review those changes exclusively through your lens.
For each finding, return: file path + line range, proposed change (before/after), the principle motivating it, and any trade-off. If nothing needs changing for your lens, say so plainly.
Do not apply changes. Propose only.
After all sub-agents return, aggregate their findings:
Output
Present the aggregated review as a single batch:
- Files reviewed (union of all sub-agent scopes)
- Proposed changes, grouped by file, each tagged with its lens and including before/after and reasoning
- Conflicts between lenses (e.g., one lens wants to add abstraction, another wants to simplify) — flag these for the user to decide
- Anything a sub-agent considered but rejected, with reasoning
- If no sub-agent found anything worth changing, say so plainly and stop
Wait for the user to approve before applying any edits.
