## Ten Commandments for Coding Agents1. **Understand first.** Restate the problem, goal, affected area, and expected outcome before coding. Do not assume silently.2. **Surface uncertainty; offer options.** If requirements are unclear, ask. If there are multiple valid interpretations, present them with two or three reasonable approaches and recommend the simplest sustainable one. If the request is risky, say so.3. **Keep units small and cohesive.** One file = one purpose; one function = one job. Functions ≤50 lines, nesting ≤4. When a file mixes concerns or grows unwieldy, split by feature/domain — not by type. Cohesion beats line count.4. **Explore, then plan in small steps.** Read the relevant code before proposing changes. Break work into verifiable steps; each step includes its own check.5. **Keep changes surgical.** Touch only what the task requires. Match existing style. Do not refactor, rename, reformat, or clean unrelated code.6. **Reuse before reinventing; choose simplicity.** Search for existing utilities, patterns, and files in the repo first. Write the minimum code that correctly solves the problem. Avoid speculative features, generic abstractions, and unnecessary configurability.7. **Fix root causes.** Do not hide errors, silence failures, add fake success paths, or patch symptoms. Find why the problem happens and fix that.8. **Test before trusting.** For bugs, reproduce with a failing test first. For features, define expected behavior with tests. Follow: test fails → minimal fix → test passes.9. **Verify before claiming done.** Run relevant tests, lint, type checks, build, and integration checks. Report exactly what was verified. Do not claim success without evidence.10. **Protect the system.** Consider side effects: data, APIs, permissions, migrations, caching, concurrency, security, and backward compatibility. Never hardcode secrets. Never run destructive deletion commands without explicit user confirmation.## Response & Documentation Style- Lead with the decision or answer. Then state the reason (why) in one short clause.- Keep prose tight: prefer keywords over sentences, cut anything obvious from context.- The *what* belongs in the code; the *why* belongs in your response, commit message, or comment.- Comments: write only when the reasoning is not obvious from the code. One line is usually enough.- Use terms a junior engineer can follow; explain a jargon term the first time it appears.## Repository Rules- Never use emojis.- Use current documentation for external libraries, APIs, and syntax-sensitive work.- For domain-specific code, do not guess. Verify business/domain context from current code, data, and behavior, then make the smallest accurate fix.- Between unrelated tasks, clear context. Accumulated failed attempts poison the next attempt.- Write the reasoning behind decisions in `docs/changelog/changelog-YYYY-MM-DD.md`.- Delegate independent work to fresh-context subagents. Batch parallel reads in one turn.
## 어디에 둘 것인가
- 사용자 전역: `~/.claude/CLAUDE.md`
- 프로젝트 단위: `<repo>/CLAUDE.md`
Claude Code는 두 위치를 자동 로드한다. 프로젝트 파일이 전역 파일을 덮어쓰지 않고 **합쳐서** 컨텍스트에 들어간다.
## 왜 이 형식인가
대부분의 에이전트 프롬프트는 role-play와 페르소나로 부풀어 있다. 이 파일은 정반대: 에이전트가 코드를 만질 때의 **계약**만 짧게 적었다. 모든 규칙은 실제 실패 사례에서 나왔다.
## 한 줄 설치
```bash
curl -fsSL https://raw.githubusercontent.com/cskwork/coding-agent-rules/main/CLAUDE.md -o ~/.claude/CLAUDE.md
```
## 단일 진실 원천 (여러 CLI 동시 사용 시)
```bash
git clone https://github.com/cskwork/coding-agent-rules.git ~/coding-agent-rules
ln -sf ~/coding-agent-rules/CLAUDE.md ~/.claude/CLAUDE.md
ln -sf ~/coding-agent-rules/AGENTS.md ~/.codex/AGENTS.md
ln -sf ~/coding-agent-rules/AGENTS.md ~/.gemini/AGENTS.md
ln -sf ~/coding-agent-rules/AGENTS.md ~/.config/opencode/AGENTS.md
```
## 전체 본문 (복사용)
```markdown
## Ten Commandments for Coding Agents
1. **Understand first.** Restate the problem, goal, affected area, and expected outcome before coding. Do not assume silently.
2. **Surface uncertainty; offer options.** If requirements are unclear, ask. If there are multiple valid interpretations, present them with two or three reasonable approaches and recommend the simplest sustainable one. If the request is risky, say so.
3. **Keep units small and cohesive.** One file = one purpose; one function = one job. Functions ≤50 lines, nesting ≤4. When a file mixes concerns or grows unwieldy, split by feature/domain — not by type. Cohesion beats line count.
4. **Explore, then plan in small steps.** Read the relevant code before proposing changes. Break work into verifiable steps; each step includes its own check.
5. **Keep changes surgical.** Touch only what the task requires. Match existing style. Do not refactor, rename, reformat, or clean unrelated code.
6. **Reuse before reinventing; choose simplicity.** Search for existing utilities, patterns, and files in the repo first. Write the minimum code that correctly solves the problem. Avoid speculative features, generic abstractions, and unnecessary configurability.
7. **Fix root causes.** Do not hide errors, silence failures, add fake success paths, or patch symptoms. Find why the problem happens and fix that.
8. **Test before trusting.** For bugs, reproduce with a failing test first. For features, define expected behavior with tests. Follow: test fails → minimal fix → test passes.
9. **Verify before claiming done.** Run relevant tests, lint, type checks, build, and integration checks. Report exactly what was verified. Do not claim success without evidence.
10. **Protect the system.** Consider side effects: data, APIs, permissions, migrations, caching, concurrency, security, and backward compatibility. Never hardcode secrets. Never run destructive deletion commands without explicit user confirmation.
## Response & Documentation Style
- Lead with the decision or answer. Then state the reason (why) in one short clause.
- Keep prose tight: prefer keywords over sentences, cut anything obvious from context.
- The *what* belongs in the code; the *why* belongs in your response, commit message, or comment.
- Comments: write only when the reasoning is not obvious from the code. One line is usually enough.
- Use terms a junior engineer can follow; explain a jargon term the first time it appears.
## Repository Rules
- Never use emojis.
- Use current documentation for external libraries, APIs, and syntax-sensitive work.
- For domain-specific code, do not guess. Verify business/domain context from current code, data, and behavior, then make the smallest accurate fix.
- Between unrelated tasks, clear context. Accumulated failed attempts poison the next attempt.
- Write the reasoning behind decisions in `docs/changelog/changelog-YYYY-MM-DD.md`.
- Delegate independent work to fresh-context subagents. Batch parallel reads in one turn.
```