Claude Code CLAUDE.md Permission Recipe : réduire le contexte répété et les accès risqués

Beaucoup d’échecs Claude Code ne viennent pas d’un modèle faible. Ils viennent de règles projet qui changent à chaque session. Un CLAUDE.md clair et une recette de permissions réduisent le contexte répété, les éditions risquées et les preuves manquantes.

Cet article montre la première recette à créer. Le but n’est pas de bloquer l’agent, mais de séparer lecture seule, demander avant, ne jamais toucher et commandes de preuve.

À lire aussi: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

Pourquoi ce modèle fonctionne

CLAUDE.md n’est pas une mémoire, c’est un contrat de travail. Quand il nomme commandes de preuve, dossiers protégés et chemins PDF, Gumroad, consultation, il sert au développement et à la publication.

La recette de permissions transforme le contrat en comportement. Séparer read-only, ask-before, never-touch et auto proof commands réduit les dépassements.

Flux de travail pratique

1. Écrire objectif, barre qualité, commandes de preuve et chemins revenus dans CLAUDE.md
2. Diviser les fichiers en read-only, ask-before et never-touch
3. Nommer les commandes de preuve exécutables sans nouvelle approbation
4. Garder déploiement, suppression et actions irréversibles sous confirmation humaine
5. Après publication, capturer h1, début, CTA et liens Gumroad

Situation	Action sûre	Preuve
Site solo	Autoriser le corps des articles; formulaires et API demandent avant	build et URL publique
PR équipe	Autoriser revue de diff; bloquer push et déploiement jusqu’à demande	diff PR
Page revenus	Protéger liens produits, prix et formulaires	clics vérifiés

Prompt et code à copier

Crée une CLAUDE.md permission recipe pour ce projet. Inclure read-only, ask-before, never-touch, auto proof commands, contrôles URL publique et règles pour protéger PDF gratuit, Gumroad et consultation.

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"));

L’exemple n’est pas une vraie configuration. C’est une façon compacte de modéliser la décision. Adapter aux permissions, CI et déploiement.

Trois exemples réels

Premier setup

Laisser lire README et package.json, puis créer CLAUDE.md avant la première édition. Limiter cette édition à un fichier.

Article multilingue

Ne pas croire seulement slug et frontmatter. Ajouter une règle: début du corps et CTA dans la bonne langue, avec capture.

Avant consultation

Apporter table de permissions, zones interdites et commandes de preuve. La session devient concrète.

Échecs à éviter

• Écrire seulement des principes dans CLAUDE.md sans zones concrètes.
• Autoriser déploiement ou suppression par confort.
• Traiter liens produit et formulaire comme contenu ordinaire.

Les règles trop longues sont ignorées. Commencer court et ajouter une règle après chaque vrai échec.

Relier PDF gratuit, Gumroad et consultation

Si les bases restent fragiles, garder le cheatsheet gratuit. Pour CLAUDE.md, permissions, hooks, MCP et CI, la Setup Guide est le chemin payant le plus direct.

Utiliser 50 Prompt Templates pour standardiser revue et debug. Utiliser la consultation pour règles d’équipe ou revenus. Comparer sur products.

À vérifier avant et après publication

Avant publication, vérifier que l’article et toute règle CLAUDE.md ne contredisent pas la recette. Après publication, inspecter h1, début, CTA et produits en mobile pour chaque langue.

Chiffres à suivre ensuite

Suivre clics Setup Guide, démarrages PDF, visites consultation et circulation vers articles permissions. Si la consultation monte, le besoin est opérationnel.

Revue opérationnelle de 30 minutes

Quand le recette de permissions CLAUDE.md passe en travail réel, la revue la plus utile arrive le lendemain. Lire le journal et noter portée autorisée, fichiers changés, commandes de preuve et pages publiques vues. Ne pas écrire seulement “vérifié”. Garder le reçu exact : h1 mobile, début du texte, zone CTA, lien Gumroad et chemin consultation.

Séparer confiance de l’opérateur et comportement lecteur. Côté opérateur, vérifier zones interdites, build, même slug public et absence de corps anglais dans les pages traduites. Côté lecteur, vérifier l’étape naturelle : PDF gratuit pour les commandes, Gumroad pour un blocage répété, consultation pour la conception du workflow.

Transformer la revue en une règle future. Ne pas ajouter dix règles après chaque souci. Ajouter une règle qui aurait évité l’erreur : demander avant un layout, cliquer chaque URL Gumroad en production, ou capturer le début du texte pour chaque langue. Une petite règle exécutée chaque jour vaut mieux qu’une longue politique.