Claude Code CLAUDE.md Permission Recipe: Reduce Repeated Context and Risky Access

Many Claude Code failures are not caused by a weak model. They happen because the project rules change from session to session. A clear CLAUDE.md plus a permission recipe reduces repeated context, risky edits, and missing verification.

This article shows the first recipe a beginner should create. The goal is not to freeze the agent. The goal is to separate read-only context, ask-before areas, never-touch areas, and proof commands.

Related reading: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

Why this pattern works

CLAUDE.md is not memory. It is a work contract. When it names proof commands, protected directories, and revenue paths such as PDF, Gumroad, and consultation links, it helps both development and publishing.

A permission recipe turns that contract into behavior. Separating read-only, ask-before, never-touch, and auto proof commands lowers the chance that Claude Code runs ahead of the user.

The practical workflow

1. Write the goal, quality bar, proof commands, and revenue paths in CLAUDE.md
2. Split file areas into read-only, ask-before, and never-touch
3. Name the proof commands Claude Code may run without extra approval
4. Keep deploy, deletion, and irreversible actions behind explicit human confirmation
5. After publishing, screenshot h1, opening body, CTA, and Gumroad links

Situation	Safe move	Proof
Solo site	Allow article body edits; keep forms and APIs ask-before	build and public URL
Team PR	Allow review of diffs; stop before push or deploy until requested	PR diff
Revenue page	Protect product links, prices, and inquiry forms	click check

Copy-paste prompt and code

Create a CLAUDE.md permission recipe for this project. Include read-only, ask-before, never-touch, auto proof commands, public URL checks, and protection rules for the free PDF, Gumroad products, and consultation path.

const permissionRecipe = {
  readOnly: ["README.md", "package.json", "src/routes/"],
  askBefore: ["site/src/layouts/", "scripts/", "wrangler.toml"],
  neverTouch: [".env", "billing/", "customer-data/"],
  proofCommands: ["npm.cmd run build", "git diff --stat"]
};

function canRunWithoutAsking(command) {
  return permissionRecipe.proofCommands.includes(command);
}

console.log(canRunWithoutAsking("npm.cmd run build"));
console.log(canRunWithoutAsking("wrangler pages deploy"));

The example is not a real config file. It is a compact way to model the decision. Adapt it to your team’s permissions, CI, and deploy flow.

Three real examples

First setup

Let Claude Code read README and package.json, then create CLAUDE.md before the first edit. Limit the first edit to one file so success and failure are visible.

Multilingual article

Do not trust only slug and frontmatter. Add a rule that opening body and CTA must be in the target locale, with screenshot proof.

Before consultation

Bring the permission table, blocked areas, and proof commands to a consultation. The call becomes an implementation session instead of vague AI advice.

Failure cases to avoid

• Writing only values and principles in CLAUDE.md without concrete blocked areas.
• Allowing deploy or deletion because it feels convenient.
• Treating product links and inquiry forms like ordinary content files.

Rules that are too long are ignored. Start short and add one rule after each real failure.

How to route readers to PDF, Gumroad, and consultation

If the basics still feel shaky, keep the free cheatsheet nearby. For CLAUDE.md, permissions, hooks, MCP, and CI, the Setup Guide is the fastest paid path.

Use 50 Prompt Templates when you need standardized review and debugging requests. Use consultation when team rules or revenue paths need design. Compare resources at products.

What to verify before and after publishing

Before publishing, check that the article and any new CLAUDE.md rule do not contradict the permission recipe. After publishing, inspect h1, opening body, CTA, and product links at mobile width for each locale.

Metrics to watch next

Watch Setup Guide clicks, PDF starts, consultation visits, and clicks to related permission articles. If consultation rises from this slug, readers need operating design more than another template.

A 30-minute operations review

When you put the CLAUDE.md permission recipe into real work, the most useful review happens the next day. Read the run log and write down the allowed scope, the files that changed, the proof commands, and the public pages that were inspected. Avoid vague notes such as “checked the page.” Write the exact receipt: mobile h1, opening paragraph, CTA area, Gumroad link, and consultation path.

Then separate worker confidence from reader behavior. Worker confidence means blocked areas were not touched, build proof exists, the public URL is the same slug, and translated pages are not silently using English body text. Reader behavior means the article gives a clear next step after the point of need: free PDF for command fluency, Gumroad when the reader has a repeatable bottleneck, and consultation when the issue is workflow design.

Finally, turn the review into one future rule. Do not add ten rules after every problem. Add one rule that would have prevented the mistake: ask before editing a layout, click every Gumroad URL on production, or screenshot the opening body for each locale. Small rules that survive daily use are stronger than a long policy nobody reads.