Becoming an AI Power User

5.4Infrastructure and Learning Systems

They keep one home for their standards so tested improvements can reach every project

Developing

Copying a rule into every project means improving it once requires fixing it everywhere

A rule copied into several project setups is easy to improve unevenly. You change how research summaries should handle uncertainty in one project and overlook a second. The same request then produces different results because the projects have different instructions. Keeping one authoritative version gives you a clear place to make the correction and a clear version to check elsewhere.

A master recipe binder helps explain the arrangement. Cooks who read the binder use its current recipe; a cook using yesterday's photocopy does not. A project pointer has the same condition: the assistant must be able to open the source and must do so at the right time. One home simplifies updating a rule; verified loading carries that update into the work.

This arrangement separates two jobs: deciding which version is authoritative and getting that version to the place that uses it.

When a project can access the source, a pointer lets it use the rule without maintaining a separate manual copy. Keep a short note that names the rule and its accessible location, then verify that the tool reads it. Where direct access is unavailable, use a maintained copy with a recorded source version and a way to refresh it.

One source edit reaches projects through verified loading

For the summary rule, add a requirement to distinguish missing information from conflicting evidence. Then start a fresh research task and a fresh client-update task that both use the rule. Ask each assistant to identify the source it read, and check whether its output makes that distinction. A running conversation may still contain the old version. Refresh or restart it according to the tool's behavior.

Keep a revision history alongside the authoritative source. One folder alone does not record past edits. A notes app with version history or a version-control system can preserve them. Ask the agent to explain a change before replacing a standard, save the prior version, and test both on relevant examples when an improvement is uncertain.

Keep requirements independent of the model that attempts them

A new model does not automatically change what a good result means. If a summary must separate evidence from inference, that requirement can stay while the model changes. Yet standards can improve too: a stronger model may suggest a better check or expose a weak assumption. Keep requirements separate from model settings to support testing either kind of change deliberately.

Copies creep back in, so a regular check is how you keep one home honest

An unmanaged copy can miss the next update. A generated copy may be necessary in a tool that cannot reach your canonical folder. Give that copy a source, a version, and a refresh method. The problem to catch is an independent rule whose relationship to the authoritative version has become unclear.

Ask your agent to inspect the projects in scope and classify their rules as direct references, intentionally maintained copies, or independently edited duplicates. Check access before replacing a duplicate with a pointer. If two versions disagree, preserve both until you determine whether the difference is an error or a legitimate project-specific exception.

Shared standards need a verified route into each project

Establish a shared standard and verify its use across projects

Claude identifies the authoritative rules, checks how each project can load them, and proposes direct references or maintained copies. You resolve conflicting versions and test a shared update.

Copy the promptUse the copy button above the box.
Paste it in Claude or CodexMake sure your active project is enabled.
Answer the questionsGive clear answers so it understands what you want made.
Test it to see if it worksTry the output and refine until it does what you need.

Problem: Separately maintained copies of a shared standard can diverge. Intent: I want one authoritative source and a verified way for the projects I choose to use it. Ask where the standards currently live and which projects should use them. Read the actual rules in those locations. If you lack access, ask for the contents or a supported connection before proposing replacements. 1. Inventory shared rules, duplicated versions, conflicts, and deliberate local exceptions. Show the passages behind each finding. Ask me to resolve genuine ambiguity; do not invent a preference or require a change when the versions already serve their intended purposes. 2. Propose the authoritative source. Group connected rules in short, clearly named files. Show any inferred personal standards with their source evidence and ask me to confirm them before saving. Preserve existing versions until the source is complete and the chosen projects can use it. 3. Establish a supported loading method for each project. Use a reference or import where it works. Where direct access is unavailable, retain a maintained copy with its source version and refresh method. Specify what the assistant should do if a required standard is unavailable. 4. If the evidence reveals a useful improvement, propose it and preserve the prior version. Test the intended standard in fresh tasks in the chosen projects, including a case that already worked. Report which version each task loaded and whether its output applies the requirement. If no revision is justified, test distribution of the existing standard. 5. Provide a drift check for unmanaged duplicates, stale maintained copies, and broken references, with review triggers suited to the work. Work only in the locations I identify. State any loading or test step you cannot perform. Do not infer successful distribution from editing the source alone.

Shared standards can fail through stale copies or broken references

Check shared standards for stale copies and broken references

Claude checks the listed projects for unmanaged duplicates, stale maintained copies, and broken references. You review proposed repairs while preserving deliberate project-specific rules.

Copy the promptUse the copy button above the box.
Paste it in Claude or CodexMake sure your active project is enabled.
Answer the questionsGive clear answers so it understands what you want made.
Test it to see if it worksTry the output and refine until it does what you need.

Problem: Projects using my shared standards may have stale copies or broken references. Intent: I want to check whether the projects I choose receive and apply the intended versions. Ask for the authoritative source location and the projects to inspect if I have not supplied them. Read the actual standards and project instructions. If access is missing, ask for the contents or a supported connection and distinguish accessible material from what remains unverified. 1. Classify each project's loading method: direct reference, import, intentionally maintained copy, independently edited duplicate, or local exception. 2. Report the version each project uses, access failures, and differences from the authoritative rule. Show the source passages and distinguish confirmed exceptions from unresolved differences. 3. Propose repairs for broken loading, stale copies, or accidental duplication where the evidence supports them. Preserve deliberate exceptions. Replace a copy with a pointer only when that project can read the source through a supported method. 4. After I approve a repair, apply it in the listed projects and test a fresh task. Report the version loaded and whether the output applies the standard. Leave any unverified condition explicit. Inspect and report without an additional approval step. Change only the listed projects after I approve the proposed repairs. Do not revise the authoritative standards during this sweep.

References

2 sources

1
How Claude remembers your project View source
Anthropic · 2026 · Claude Code documentation; checked September 4, 2026
Claude Code distinguishes startup-loaded imports from rules or skills loaded for relevant tasks.
Verify how instructions reach the model and whether a fresh task receives the revised version.
These are current product mechanics, not a universal contract for other assistants. Access restrictions and session state can affect loading.
2
How Claude Code uses prompt caching View source
Anthropic · 2026 · Claude Code documentation; checked September 4, 2026
Prompt caching matches a request prefix against content the service recently processed. Claude Code documentation describes this as an exact prefix match, with no separate cache for each file.
Keeping a standard in one file helps organize its source. Cache savings depend on the requests that actually reach the model, so a stable file location alone does not establish a cache hit.
This describes current Claude Code mechanics. Other tools, configuration changes, and session state can produce different behavior.