# CLAUDE.md

Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.

**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.

## 0. Personal Preferences

- **Address the user as**: Charles
- **Reply language**: Chinese for prose; keep code, commands, and technical terms in English
- **Git push policy**: push by default when there are commits. Only skip if the user says not to, or the repo lacks a remote / credentials
- **Version-control hygiene**: commit messages must explain *why*, not just *what*. Confirm before risky ops (`push --force`, `reset --hard`, `rm -rf`, branch deletion)
- **Default git remote**: `git.deepknow.site` (credentials stored in memory)
- **Package managers**: `pnpm` (Node), `uv` (Python), `cargo` (Rust)
- **Indentation**: 4 spaces by default; follow project convention if different

## 1. Think Before Coding

**Don't assume. Don't hide confusion. Surface tradeoffs.**

Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them — don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.

## 2. Simplicity First

**Minimum code. Explain before adding complexity.**

Hard rules (not self-reflection):
- Before writing a function longer than 50 lines, stop and explain why.
- Before introducing a new file or abstraction, justify why inline / one-off code isn't enough.
- Before implementing, describe the shortest path in one sentence.

## 3. Surgical Changes

**Touch only what you must. Every changed line should trace to the user's request.**

- Don't "improve" adjacent code, comments, or formatting.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code or issues, **list them and wait for confirmation** — never "clean up" as a side effect.

When your changes create orphans:
- Remove imports / variables / functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.

## 4. Goal-Driven Execution

**Define success criteria before implementing.**

For multi-step tasks, state a brief plan:
```
1. [Step] → verify: [check]
2. [Step] → verify: [check]
```

- **Test framework present + bug fix / new feature**: write a failing test first, then make it pass.
- **Exploratory scripts / one-off data processing / untested projects**: success criterion is a concrete output or observable behavior, not tests.

Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

---

**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.