One Claude Code Tip a Day: Use /simplify After the Feature Works

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The failure: cleanup sneaks into the feature patch

The riskiest moment in a Claude Code session often comes after the first success. The test is green, the browser flow works, and the diff is almost ready. Then you notice duplicate conditionals, an awkward helper name, or a component that now has three responsibilities. If you ask Claude to 'clean this up' inside the same feature thread, it may take the permission too broadly. Suddenly the patch that fixed the checkout bug also reorganizes validation, renames a hook, and moves code across files. The feature still sounds correct in the summary, but the review surface has doubled.

Today's habit is to use `/simplify` as a separate cleanup pass after the behavior is already proven. Treat it like a refactoring checkpoint, not like a magic broom. The useful sequence is: make the feature work, freeze the evidence, run `/simplify` against a narrow target, inspect the cleanup diff, then rerun the exact proof that made the feature trustworthy.

Freeze the proof before you simplify

Start by making Claude name the evidence you already have. For a realistic example, imagine you just added a team invitation limit to a SaaS dashboard. The focused API test passes, the browser rejects the eleventh invite, and `git diff` shows changes in the invite server action plus one test file. Before cleanup, ask Claude Code for a short checkpoint:

`Before we simplify, summarize the verified behavior, the exact commands that passed, and the files that are allowed to change during cleanup. Do not edit yet.`

That prompt matters because `/simplify` should not reopen the problem. It should reduce accidental complexity around a known-good change. If the proof is vague, cleanup becomes another implementation phase. If the proof is concrete, every later edit has to justify itself against that proof.

Run /simplify with a narrow target

The command is most useful when the target is explicit. Instead of asking for repo-wide cleanup, point it at the file or slice that became messy:

`/simplify apps/web/actions/invites.ts`

or, when the change spans a small component and a test:

`/simplify apps/web/components/invite-dialog.tsx tests/invite-limit.test.ts`

Then add the constraint in normal language: `Keep the verified behavior unchanged. Prefer removing duplication and clarifying names over changing architecture. If a cleanup would touch billing, auth middleware, or migrations, propose it instead of applying it.` The command gives Claude permission to look for simplification, but your constraint sets the boundaries. You are asking for a maintainer-quality cleanup, not a second feature implementation.

Review the cleanup diff like a behavior change

A good `/simplify` pass should make the diff easier to explain. It may inline a one-use helper, rename a misleading variable, collapse two branches that returned the same error, or move a repeated limit check into the existing server-side guard. It should not silently change the user-facing rule, alter test expectations to match a weaker behavior, or introduce a new abstraction because the model likes symmetry.

After Claude applies the cleanup, do not accept the summary first. Ask for the diff story:

`Show the cleanup diff grouped by intent. For each changed hunk, say whether it is behavior-preserving, readability-only, or test cleanup. Flag anything that could change runtime behavior.`

Then inspect `git diff` yourself. Look for deleted assertions, widened conditionals, renamed exports, and changes outside the target files. The most dangerous cleanup is the one that makes the patch look elegant by removing the ugly line that was actually enforcing the edge case.

Rerun the same proof, not a new story

The verification step should be boring. Run the same focused command that proved the feature before cleanup, plus any cheap static check that fits the project:

`npm test -- invite-limit`

`npm run lint -- apps/web/actions/invites.ts`

If the project has a frontend path, reopen the same browser scenario. Do not let Claude replace a failed focused test with a broader passing command. A broad green build is useful, but it does not prove the invite limit survived the cleanup. The rule is simple: cleanup must pass the original proof before it earns any new proof.

When the check fails, resist the prompt `fix it`. Make Claude compare cleanup against the verified baseline:

`The focused test passed before /simplify and fails now. Identify which cleanup hunk changed behavior, revert or correct only that hunk, and rerun the same test.`

Failure modes

Do not use `/simplify` before you know what works. Early in a bug hunt, simplification can erase useful evidence or make two hypotheses change at once. Do not aim it at the whole repository unless the task is intentionally a cleanup review. And do not accept a cleanup that only moves complexity into a new abstraction with a confident name. Fewer lines are not automatically simpler if the next maintainer has to jump through more files to understand the rule.

Also watch for test simplification. Claude may remove a repeated setup block in a way that hides the case you cared about, or it may merge two tests that should remain separate because they protect different failure modes. Test code can be cleaned, but not at the cost of diagnostic power.

Rule of thumb

Use `/simplify` only after the feature has evidence. Give it a narrow target, preserve the original proof, and review the diff as if it could break production. The best cleanup pass makes the verified change easier to maintain without making the reviewer re-litigate the whole feature. If you cannot state what must remain true after cleanup, you are not ready to simplify yet.