claudeplus/CLAUDE.md

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 — don't ask first, just push. Only skip if the user explicitly 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. Tooling details and known pitfalls live in note.md / debug.md (auto-imported below).
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.

5. Extended references (auto-imported)

These files expand into context at session start:

• Tool catalog: @~/.claude/tool.md
• Practice notes: @~/.claude/note.md
• Debug pitfalls: @~/.claude/debug.md

Not auto-imported (read on demand):

• Session log: ~/.claude/log.md — appended by SessionEnd hook, grows unboundedly so kept out of context to save tokens

---

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.