CLAUDE.md — operating rules for this repo

These rules govern how Claude (or any AI agent) works in this repository. They are loaded at the start of every session and override defaults.

The repo is a GEO audit toolkit, audit-only, no sales/CRM (see docs/LLM_RETRIEVAL_ARCHITECTURE.md for methodology). The rules below come from Anthropic's internal dev practices — adopt them strictly.

Working Rules

1. Plan Mode Default

• Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions).
• If something goes sideways, STOP and re-plan immediately — don't keep pushing.
• Use plan mode for verification steps, not just building.
• Write detailed specs upfront to reduce ambiguity.

2. Subagent Strategy

• Use subagents liberally to keep the main context window clean.
• Offload research, exploration, and parallel analysis to subagents.
• For complex problems, throw more compute at it via subagents.
• One task per subagent for focused execution.

3. Self-Improvement Loop

• After ANY correction from the user: update tasks/lessons.md with the pattern.
• Write rules for yourself that prevent the same mistake.
• Ruthlessly iterate on these lessons until mistake rate drops.
• Review lessons at session start when relevant to the current task.

4. Verification Before Done

• Never mark a task complete without proving it works.
• Diff behaviour between main and your changes when relevant.
• Ask yourself: "Would a staff engineer approve this?"
• Run tests, check logs, demonstrate correctness.

5. Demand Elegance (Balanced)

• For non-trivial changes: pause and ask "is there a more elegant way?"
• If a fix feels hacky: "Knowing everything I know now, implement the elegant solution."
• Skip this for simple, obvious fixes — don't over-engineer.
• Challenge your own work before presenting it.

6. Autonomous Bug Fixing

• When given a bug report: just fix it. Don't ask for hand-holding.
• Point at logs, errors, failing tests — then resolve them.
• Zero context switching required from the user.
• Go fix failing CI tests without being told how.

Task Management

1. Plan First — Write the plan to tasks/todo.md with checkable items.
2. Verify Plan — Check in with the user before starting implementation on non-trivial work.
3. Track Progress — Mark items complete as you go.
4. Explain Changes — High-level summary at each step.
5. Document Results — Add a review section to tasks/todo.md.
6. Capture Lessons — Update tasks/lessons.md after corrections.

The TodoWrite tool stays the in-session runtime tracker. tasks/todo.md is the durable, repo-visible plan that survives sessions and is part of the project's collaboration contract.

Core Principles

• Simplicity First — Make every change as simple as possible. Impact minimal code.
• No Laziness — Find root causes. No temporary fixes. Senior developer standards.

Project-Specific Reminders

• Audit-only philosophy: never recommend pricing tiers, MRR projections, traffic uplift estimates, or "client-ready" sales framing. Findings are framed in effort × score-gain × confidence. See feedback_audit_only in user memory.
• Per-LLM analysis: report citation likelihood per LLM (ChatGPT/Google, Gemini/Google, Perplexity/multi, Claude/Brave, Le Chat/Brave). No single composite "AI readiness" score — see docs/LLM_RETRIEVAL_ARCHITECTURE.md.
• Evidence over claim: distinguish proven signals (Schema validity, crawler access, Wikipedia/Wikidata presence, SERP rank) from emerging / weakly-evidenced ones (llms.txt, citability passage scoring). Tag confidence on every finding.
• No paid APIs: the toolkit must run without paid LLM/search APIs. Free public APIs (MediaWiki, Wikidata SPARQL, Brave Search free tier, Wayback) and respectful scraping only.
• site-client/ is gitignored: never commit audit artefacts. Local-only by design.
• Branch hygiene: single branch main. No upstream remote is configured. Don't reintroduce one — the repo's history is intentionally self-contained.
• Output language: audit reports default to the audited site's language (detected via scripts/site_locale.py — HTML lang → Content-Language → TLD → fallback en). The user can override with --output-lang <iso2>. Fallback: English. This applies to all skills and scripts that produce user-facing Markdown / prose. See tasks/lessons.md 2026-04-25 entry for rationale.