211c0f05d8
原条目 "push by default" 留了模糊空间, 实测我仍然会在 commit 后反复确认 "要不要 push", 用户明确要求消除这种冗余询问; 加 "don't ask first, just push" 固化下来, 只在用户显式拒绝或仓库没 remote 时才跳过。
89 lines
4.6 KiB
Markdown
89 lines
4.6 KiB
Markdown
# 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:
|
|
|
|
- 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.
|