#Similar templates are where AI coding assistants get dangerous

A homepage variant, an archive template, a landing page, and a detail page can look 90% the same and still need different fixes. That is exactly where Claude Code and Cursor start “helpfully” copying the wrong pattern.

If a client site has multiple similar templates, how do you keep the MCP context narrow enough that Claude Code or Cursor doesn’t start ‘helpfully’ applying a fix pattern from one page type to another? You do it by treating context like a scalpel, not a folder dump. The model should see the one template, the one shared dependency, and the one override that actually matters. Not the whole theme. Not every near-duplicate file in the repo.

The mistake I see most often is broadening context because the bug feels familiar. The assistant sees a card grid, a hero block, a filter bar, and assumes the fix belongs everywhere. That’s how you get a “correct” change in the wrong place.

#Start with the smallest proof, not the biggest search

The smallest useful MCP context is usually one template file, the direct shared partials it imports, and the specific CSS or JS symbol that controls the bug. Anything beyond that is usually noise until the model has earned the right to see more.

For a typical WordPress or headless build, that might mean:

archive-product.php plus the one partial it calls
a single block template and the component override it uses
one JS module and the CSS class that toggles the broken state
the relevant schema or data mapper if the issue is field-level

If the bug is visual, I do not start by including the whole stylesheet. I include the exact selector chain, the component file, and the template instance where the bug shows up. If the bug is behavioural, I include the event handler, the DOM target, and the page type that reproduces it. That’s the difference between context narrowing and context blindness.

If you want a useful mental model, think in terms of dependency depth, not file count. Usually, three hops is enough:

The template that renders the page
The shared component or partial it calls
The one style or script symbol that actually drives the issue

Once you go past that, the model starts pattern-matching across templates instead of reading the specific one in front of it.

Key takeaway: narrow context until the assistant can explain the bug in the right template before it is allowed to edit anything.

#Prove the assistant is in the right template before it touches code

When two templates differ by one or two fields, I do not trust the model to “notice” the difference on its own. I make it prove the difference back to me.

A practical method that works:

Ask it to name the template file first
Ask it to list the fields or props that are unique to that template
Ask it to quote the exact selector, component, or function it will change
Ask it to state what it is not changing

That last one matters. If the assistant cannot say, “I am editing archive.php, not page.php, and I am leaving the shared card component alone,” it has not scoped the work properly.

This is the same discipline we use when content needs to stay grounded in one client’s actual offer instead of drifting into generic marketing copy. Our Blog Content Creation work only stays useful because it is tied to the real search intent, the real voice, and the real service boundaries. Code context needs the same restraint.

If the model is still fuzzy, I make it restate the render path in plain English:

“This page type uses template-home-variant.php”
“This archive uses the shared loop partial plus a template-specific hero”
“This detail page overrides the gallery, but not the meta block”

That sounds basic. It saves hours.

#The fix is not always in the file that looks broken

One of the nastier failure modes is when the assistant keeps “fixing” shared components even though the bug only exists in one template instance. That usually means the shared component is innocent, and the bug is coming from a single override, a conditional wrapper, or a template-specific class that changes layout only on that page type.

If the assistant keeps collapsing the issue into the shared component, stop it and inspect the rendered output. I want the actual DOM class names, the actual wrapper order, and the actual data shape for the broken page. In practice, the real fault is often one of these:

a template-specific modifier class overriding shared spacing
a conditional field missing only on one template
a JS selector too broad, catching all instances instead of one
a CSS rule that only breaks when a sibling block exists

That is why “shared” is not a synonym for “safe”. Shared code is where regressions spread fastest, but it is not always where the bug lives.

If you need a related playbook, DW Scoping Guardrails: Prevent Wrong Reuse Across Sites covers the same problem at site level, where the model starts borrowing patterns from the wrong client entirely.

#When the right fix spans shared code and one override, split the work

This is the part people get wrong. The assistant sees a defect that exists in both the shared component and one template-specific override, and it tries to “simplify” the change into one edit. That usually breaks one of the templates.

Do not let it.

Split the problem into two explicit layers:

Layer	What belongs here	What stays out
Shared code	Logic or markup used by both templates	Page-specific spacing, labels, or conditionals
Template override	The one-off fix for the affected page type	Behaviour that should apply globally

If you force the assistant to separate those layers before editing, it stops flattening the architecture into one broad patch. I will often ask for two diffs, not one. First the shared fix, then the override. If the shared layer is not genuinely shared, that becomes obvious immediately.

This is where Claude Code context scope matters more than raw capability. The model can usually see the dependency chain if you give it the chain. It fails when you give it too much and ask it to infer the boundary.

#The guardrail that actually works is a template fingerprint

If a site has dozens of near-duplicate templates, you cannot rely on memory or naming conventions alone. I use a lightweight fingerprint for each template before any edit:

template file name
unique fields or blocks
the shared partials it uses
the one or two selectors or functions that differ
the page type it should never affect

That fingerprint becomes the preflight check. Before the assistant makes a change, it has to repeat the fingerprint back accurately. If it mixes up archive and detail, or homepage and landing page, the context is too broad.

This is also how you stop the model from generalising a CSS or JS pattern from a similar page type that happens to be subtly wrong. The fingerprint makes the difference concrete. Without it, the model sees “same-looking page” and fills in the rest from memory.

For teams doing this all day, this belongs in the workflow, not in tribal knowledge. A lot of the value in Client Management is exactly that, one record per client with the relevant context attached, so you are not reconstructing the same boundary every time. The same principle applies inside a codebase. Keep the relevant context close to the work.

#Narrow context without blinding the model

The fear is that if you tighten context too much, the assistant will miss the real dependency chain. That fear is valid. Blind scoping is just as bad as broad scoping.

The way around it is to expand context only when the model can justify the next layer.

A sane escalation looks like this:

Start with the template that reproduces the bug
Add the direct partial or component it renders
Add the exact shared symbol involved in the bug
Only then add neighbouring templates if the bug crosses boundaries

That keeps the assistant from inventing patterns from the wrong template while still letting it see the actual call chain. If the site has dozens of similar templates, I would rather do two tight passes than one broad one. Broad context feels efficient. It usually produces the most expensive mistakes.

#Review strategy when the change is technically valid but wrong

The worst case is not a broken change. It is a technically valid change applied to the wrong template because the context was too broad. Those pass casual review. They even look neat in a diff.

My rollback strategy is simple:

review by template, not by file
check the rendered page type after each edit
compare the change against the fingerprint
revert anything that widens behaviour beyond the intended page type

If the assistant touched a shared component, I verify every template that consumes it. If it touched a template override, I verify that the shared component did not inherit the change by accident. This is where Cursor template fixes can go sideways fast, because a small refactor in one file can quietly alter three page types that share the same partial.

A good review question is blunt: “If I loaded the archive and the detail page side by side, would this change still make sense on both?” If the answer is no, the change probably belongs in the override, not the shared layer.

#The fastest way to keep context narrow is to define the negative space

Most people define scope by what the assistant should edit. Better to define it by what it must not touch.

Say it plainly:

not the homepage variant
not the archive template
not the shared card component
not the global stylesheet
not the JS that powers all listing pages

That negative space is what stops “helpful” cross-template reuse. It also makes review easier, because you can see whether the model drifted outside the fence.

If you are working inside Claude Code or Cursor, this is the habit that keeps you sane: ask for the smallest edit that can be proven against the right template, then expand only if the bug genuinely crosses a boundary. If a fix starts to look reusable, stop and ask whether it is reusable or just familiar.

That distinction saves client sites from the kind of regression nobody notices until a different page type breaks three days later.

#Do this next

Pick one broken template and write a one-paragraph scope note before you let the assistant edit anything. Include the template file, the unique fields, the shared partials, and the one thing it must not change. Then ask the model to restate that scope back to you before it touches code.

If you want the same discipline applied across your content and client-facing work, Established Plan is the faster path, it keeps blog posts, social posts, and newsletters grounded in your voice instead of scattered across tools.

If a client site has multiple similar templates, how do you keep MCP context narrow?