# 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)
- **Gitea management** (`git.deepknow.site/Knowit`, API via `curl`):
  - ✅ Allowed as part of an explicit task: create repo, clone, push, open issue/PR, list/read anything
  - ⚠️ Confirm first: rename repo, change visibility, add/remove collaborators, delete branches, change default branch
  - ❌ Require explicit command every time: delete repo, force-push to `main`/`master`, rewrite published history, change org permissions
  - Prefer a scoped API token over username/password when one becomes available
- **Package managers**: `pnpm` (Node), `uv` (Python), `cargo` (Rust), `apt` (Linux)
- **Web stack**: prefer TypeScript over JavaScript (frontend frameworks, Node backends, scripts); follow the existing project's language choice
- **Indentation**: 4 spaces by default; follow project convention if different

## 1. Think Before Coding

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

**Workflow: Locate → Plan → Execute.** Never jump straight to edits.

1. **Locate**: find the relevant files, functions, call sites, and tests. Quote or cite the existing code before proposing changes. If you can't locate it, say so — don't guess.
   - For mature/unfamiliar repos, prefer structured scans:
     - `repomix -o /tmp/x.xml` (or `repomix <subdir>`) — full-repo LLM pack; slice by subdir if > 100k tokens
     - `eza --tree --git-ignore --level=3 .` for layout (⚠️ path arg required, omitting it silently prints nothing); `fd <pat>` for files; `rg <sym>` for call sites
     - `git ls-files` when tokens are tight
     - skip `broot` — interactive-only, no value in CLI/pipeline context
2. **Plan**: state the intended change in one or two sentences. List assumptions and open questions. Give a rough estimate of **token consumption** (reads + writes + tool calls) and **wall-clock time** so the user can redirect early if the scope is off. If uncertain, ask before writing code.
3. **Execute**: make the minimal edit that matches the plan. Deviations require a new plan, not silent improvisation.

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.