Global Claude Code CLAUDE.md conventions

Communication Style

Answer exactly what was asked; do not volunteer Slack drafts, extra summaries, or commentary unless requested.
Show the actual changed lines — a diff or the code with file:line references — rather than only describing the change, so I can validate it without opening the file.
When making performance or comparison claims, always show the raw numbers and the arithmetic — never round to marketing-style figures like '200-300x faster'.
Never assume a person's pronouns; use their name or 'they' unless I have told you otherwise.

NEVER base branches or PRs off main. Always branch from and target develop unless I explicitly say otherwise.
Exception: the design system repo and infrastructure repos use main as their base branch — branch from and target main there. If unsure which convention a repo uses, check its default branch and recent merge history before branching.
After changing an implementation mid-PR, always update the PR description and title to match the final approach before asking for review.
Before opening a PR, run typecheck, lint, and the test suite locally and report the results in the PR body. Re-run before merging, and watch for test regressions you introduced yourself.

Change only the files needed for the stated task. If a fix appears to require touching infra, nginx, prod config, or unrelated apps, STOP and ask before editing.
Prefer the narrowest possible diff; split unrelated changes into separate PRs rather than bundling them.
Clean up only your own mess: remove imports/variables/functions that YOUR changes made unused, but leave pre-existing dead code alone — mention it instead of deleting it.
Match existing style, even if you'd do it differently. Don't "improve" adjacent code, comments, or formatting.

Search for an existing implementation before writing your own — grep the codebase for the helper, component, hook, or util, and check shared/design-system packages. Prefer reusing or extending what's there over hand-rolling a duplicate; if you do write new code, say what you looked for and why it didn't fit.
Minimum code that solves the problem. No speculative features, no abstractions for single-use code, no unrequested configurability, no error handling for impossible scenarios.
If you write 200 lines and it could be 50, rewrite it.

Turn tasks into verifiable goals: "fix the bug" → "write a test that reproduces it, then make it pass"; "refactor X" → "tests pass before and after".
For multi-step work, state a brief plan as step → verify: check before starting, then loop until each check passes.

State the root cause and the evidence for it — failing job/file/line, a minimal repro, expected vs observed — before writing any fix.
If you can't reproduce it, say so and give your top two hypotheses with the test that would distinguish them.

Jira comments/descriptions must use proper ADF/markup — never emit literal h2. wiki markup or literal \n escape sequences; verify the formatting renders.
Ticket descriptions lead with an Acceptance Criteria section written as clear bullet points, followed by a Dev Notes section for engineering-focused detail (implementation approach, affected files/services, gotchas).
Keep updates concise and do only what was asked unless extra output is requested.
When closing work: link the PR in the ticket, then transition the ticket in one step without asking for extra confirmation.