CLAUDE.md lives in your project root. It's the single best protection against vibe-coding landmines — set it up before a single line of code is written.
These are suggestions — not everything will apply to every project. Pick what's relevant and adapt to your setup, team, and tech stack.
File access
→Scope restriction — only read and write files within a defined project folder. Never touch anything outside it.
→Ask before editing — show what you plan to change and wait for confirmation. No silent edits.
→No deleting files without asking — deletions are irreversible outside git.
Planning & transparency
→Explain before doing — for any non-trivial action, explain what you're about to do, why, and what the risks are.
→Ask, don't assume — ask clarifying questions rather than fill gaps with assumptions.
→Be explicit about uncertainty — distinguish between Verified, Assumed, and Estimated. Never present a guess as a fact.
→Don't claim something works unless it was tested — if it wasn't run, say so.
Change management
→One thing at a time — make one change, confirm it works, then move on.
→Prefer incremental, reversible changes — favour changes that can be undone over rewrites that can't.
→Ask before significant changes — confirm before modifying many files, refactoring, changing auth, modifying DB schema, or replacing working functionality.
→Prefer simple, maintainable solutions — avoid premature optimisation and unnecessary complexity.
Security
→No secrets in code — never hardcode API keys, tokens, or credentials. Always use environment variables.
→Warn before auth changes — flag any change to authentication, API keys, or tokens before touching them.
Dependencies
→No package installs without asking — confirm before adding any dependency. On a work machine this can trigger security alerts.
→Justify new dependencies — explain why it's needed, what alternatives were considered, and the tradeoffs. Keep the dependency set lean.
Git
→No git pushes without asking — never run git push automatically. Confirm before anything leaves the local machine.
→Use branches for significant work — descriptive names with fix/, feat/, or chore/ prefixes.
→Never merge to main without permission — always get explicit sign-off before merging.
Completion summary
→End every significant task with a summary — what changed and why, test results, known risks, what couldn't be verified, recommended next steps, and a confidence score (1–10).
"Help me create a CLAUDE.md file for my project. This file will set the ground rules for how you work in this codebase.
Ask me a few questions first so the rules fit my situation — for example: am I on a work laptop or personal machine? Is this project in a shared repo or local only? Do I have a preferred tech stack or is that TBD? Are there any tools, APIs, or services I know I'll be using?
Based on my answers, generate a CLAUDE.md covering the areas that are relevant: file access boundaries, how you should handle edits and confirmations, secrets and security rules, dependency management, git workflow, and how you should communicate uncertainty or summarise completed work.
Note which rules are project-specific and which are general best practice, so I can update them easily as the project evolves."