Give each file a clear job
A project instruction file can preserve conventions across sessions. In Claude Code, CLAUDE.md supplies persistent context; the documentation expressly distinguishes that context from enforced configuration. A rule written in prose is therefore not equivalent to a permission control. Consult the current documentation for how files are discovered and loaded in your setup. [source]
The following layout is a proposed organization for a fictional project, not a requirement imposed by a particular product. Other applications may require explicitly attaching these files or using their project-instruction feature.
| File or folder | Purpose |
|---|---|
| Project instructions | Stable task conventions and source-handling rules |
| Current status | Completed work, unresolved questions, next step |
| Sources | Original records with stable identifiers |
| Outputs | Versioned drafts and reviewed deliverables |
| Checks | Known failures and examples with expected results |
A folder structure helps people find information. It does not create an agent, scheduler, retrieval service, or access boundary.
Keep the standing instructions short and specific
Purpose: Maintain the fictional Alder chronology.
Sources: Use identified originals; label summaries as derived material.
Dates: Preserve ranges, conditions, and disagreements.
Outputs: Save a new draft version; retain source IDs and locations.
Review: Report inaccessible material and unresolved source conflicts.
Actions: Prepare proposals only; no external communications.
State: Record the current output version and the next unfinished step.Each line answers a recurring question. Avoid loading every temporary fact or every historical correction into the standing instructions. Store task-specific detail where the current assignment can retrieve it. Do not store passwords or API credentials in these files.
Test changes instead of trusting an instruction audit
After a model change, ask for proposed revisions with a reason for each. Classify the existing instructions as stable requirements, output preferences, temporary state, or workarounds for observed failures. Remove an obsolete workaround only after checking the task it was meant to protect.
For example, a rule requiring every chronology row to retain conditions may look repetitive beside a general accuracy instruction. Test a conditional delivery date before removing it. The appropriate question is whether the output remains dependable, not whether the new model claims it no longer needs the rule.
Change one meaningful element at a time, preserve the previous version, and compare results on both known failures and fresh examples. Do not let an automatic cleanup silently remove authorization limits or source-preservation requirements.
Write a handover that can be checked
Long-running systems can use durable progress artifacts to recover context across sessions. [source] In this proposed project, record the input versions, output location, completed items, open questions, and next action. Link to the artifact itself. “Chronology finished” is insufficient if the output is missing or six inputs remain unread.
A later session should reconcile the handover with actual files. A status note is a useful guide, not a substitute for evidence of completion.
Try it: two instructions conflict
The standing file says to preserve unknown dates. A newer task template says every row must contain a precise date. What should happen before processing the record?
Check your understanding
Resolve the conflict deliberately: permit an unknown value or date range and update the inconsistent template. Do not let the model guess which requirement matters. Retain the original sources and run the undated-document test again. Good maintenance removes ambiguity while preserving the controls that make the output inspectable.