Fix the whole pattern, not one instance

Find every occurrence, patch the full surface, and write the rule down so the drift does not come back.

May 12, 2026 · 2 min read · 351 words
.md

A command for turning a one-off fix into a consistent sweep. Instead of patching the instance in front of you, it finds every occurrence across the project and applies the same fix to all of them, then records the new rule.

commands/apply-everywhere.md
---
description: Don't fix narrowly. Look holistically across the entire project for re-org, re-architecture, cleanup, simplification, consistency fixes, and
---
 
Apply a fix/pattern consistently across the entire codebase.
 
Steps:
 
1. Identify the target pattern/issue precisely (quote a representative example with file:line).
2. Grep/enumerate EVERY occurrence across all modules/tables/views/components — don't sample, don't take shortcuts.
3. Apply the fix uniformly to all of them, following established conventions.
4. Look for adjacent re-org/re-architecture/simplification/consistency wins surfaced by the sweep.
5. Update docs, AGENTS.md code rules, and patterns to reflect the change.

Enumerate, don't sample#

Step 2 is the whole point — "don't sample, don't take shortcuts." A fix that lands in some places and not others is worse than no fix, because the inconsistency hides which behavior is correct.

Capture the rule#

Step 5 makes the sweep stick. Once a pattern is applied everywhere, recording it in AGENTS.md means the next agent enforces it instead of reintroducing the old shape.

When it pays off#

Use this for naming migrations, repeated config flags, generated-client fallout, shared UI behavior, and old helper contracts that survived in more than one module. The command is overkill for a typo.

The important evidence is the enumeration. Before editing, the agent should be able to say how many matches exist and why each one is or is not in scope. That is what keeps a sweep from becoming a drive-by refactor.

Was this useful?

React if it helped; comment if you have a concrete question, correction, or field note.

-

Discussion (0)

Practical notes, bug stories, and disagreement with receipts are welcome.

No comments yet. A useful first comment is usually a field note: what failed, what held, or what you would check before shipping this idea.
Start the discussion
Markdown is supported. Keep it concrete and useful.