Write a CLAUDE.md That Describes Your Actual Project

CLAUDE.md supplies authored project context. Claude Code discovers instructions from relevant ancestor and nested locations; inspect what is loaded with the current memory/context controls. Do not assume that Codex’s AGENTS.md precedence rules apply to it.

Read the repository’s existing instructions before adding another file. Identify the real source directories and documented commands. If a command has not been verified, label it unknown rather than presenting it as a reliable check.

The project has static HTML and CSS, with no message-sending backend in the exercise. A useful root instruction file describes this architecture and preserves the boundary; it does not contain the entire contact-form brief.

• Purpose: an informational site for a fictional studio.
• Source map: contact.html contains the form; styles/forms.css styles form controls. These are illustrative paths—replace them after inspection.
• Rules: keep visible labels; preserve keyboard access; do not add dependencies without asking.
• Boundary: no production credentials, endpoint changes, or deployment in local exercises.
• Verification: record the actual documented commands and browser checks; never invent a package script.

1. Use the Agent Instructions Builder to draft CLAUDE.md from facts you have checked, or write the file manually.
2. Remove transient status such as “the current task is almost done.” Keep that in a handoff instead.
3. Review inherited and nested instructions for contradictions. Prefer one clear rule over several subtly different versions.
4. Start a fresh session or use the current client inspection controls and ask which relevant rules were loaded. Verify a harmless read-only request against them.

The file should be short enough to audit and specific enough to change behavior: an agent can find sources, avoid prohibited areas, and identify real checks. It remains guidance, not an access-control mechanism.

Pause if an existing instruction conflicts with your draft, if a command would modify a live system, or if the model treats the file as permission to bypass a tool approval. Resolve the conflict with the project owner.

• Are paths and commands real for this checkout?
• Is task status kept outside durable rules?
• Did you inspect loaded instructions rather than assume the filename alone guarantees use?