diff --git a/docs/index.html b/docs/index.html new file mode 100644 index 0000000..ca9621d --- /dev/null +++ b/docs/index.html @@ -0,0 +1,474 @@ + + + + + +Ten Commandments for Coding Agents + + + + + + + + + + + + +
+
+
$ coding-agent-rules
+
+ + +
+
+
+ +
+ + +
+
+ + ~/.claude/CLAUDE.md +
+
+# Two files. Ten rules. No fluff. +$ agent.install('coding-agent-rules') +→ writes ~/.claude/CLAUDE.md +→ writes ~/.codex/AGENTS.md +✓ ready. # agent now bound to the Ten Commandments. +
+
+ +

코딩 에이전트가 엉뚱한 짓을 못 하게 만드는 10가지 규칙.

+

Ten rules that stop a coding agent from going off the rails.

+ +

+ Claude Code, Codex CLI, Gemini CLI, OpenCode, Cursor — AGENTS.md 또는 CLAUDE.md를 읽는 모든 도구를 위한 최소 드롭인 시스템 프롬프트. 두 파일, 동일 내용. +

+

+ A minimal, drop-in system prompt for Claude Code, Codex CLI, Gemini CLI, OpenCode, Cursor — every tool that reads AGENTS.md or CLAUDE.md. Two files, identical content. +

+ +
+ + GitHub 저장소GitHub repository + + CLAUDE.md + AGENTS.md +
+ + +

#왜 필요한가Why it exists

+ +

대부분의 에이전트 프롬프트는 역할극, 페르소나 스캐폴딩, 도구별 트릭으로 부풀어 있습니다. 이 프롬프트는 정반대 — 에이전트가 코드를 만질 때 어떻게 행동해야 하는지에 대한 짧은 계약입니다. 모든 규칙은 실제 실패 사례에서 왔습니다.

+

Most agent prompts are bloated with role-play, persona scaffolding, and tool-specific tricks. This one is the opposite — a tight contract about how an agent should behave when it touches your code. Every rule comes from a real failure mode.

+ +
+
+ + failures.log +
+
+[FAIL] assumed without asking. +[FAIL] "improved" unrelated code. +[FAIL] 2,000-line god-file again. +[FAIL] swallowed error in try/catch, called it a fix. +[FAIL] claimed success without running anything. +[FAIL] hardcoded secret / ran rm -rf. +[FAIL] buried decision in narrative; no "why". +[FAIL] read whole repo into main context. + +[OK] ten commandments block all of the above. +
+
+[FAIL] assumed instead of asking. +[FAIL] "improved" code you did not ask it to touch. +[FAIL] piled every concern into one 2,000-line file. +[FAIL] hid the error behind try/catch and called it a fix. +[FAIL] claimed success without running anything. +[FAIL] hardcoded secrets or ran rm -rf to "clean up". +[FAIL] buried the decision in narrative, never said "why". +[FAIL] read the whole repo into main context. + +[OK] ten commandments block all of these. +
+
+ + +

#설치Install

+ +

에이전트가 읽는 파일을 골라서 홈 디렉터리나 프로젝트 루트에 떨어뜨리면 끝.

+

Pick the file your agent reads. Drop it in your home directory or project root. Done.

+ + + + + + + + + + + + + +
도구ToolPath
Claude Code~/.claude/CLAUDE.md
OpenAI Codex CLI~/.codex/AGENTS.md
Google Gemini CLI~/.gemini/AGENTS.md
OpenCode~/.config/opencode/AGENTS.md
Cursor / Windsurf<repo>/AGENTS.md
+ +

한 줄 설치

+

One-liner

+
curl -fsSL https://raw.githubusercontent.com/cskwork/coding-agent-rules/main/AGENTS.md -o ~/.codex/AGENTS.md
+curl -fsSL https://raw.githubusercontent.com/cskwork/coding-agent-rules/main/CLAUDE.md -o ~/.claude/CLAUDE.md
+ +

여러 CLI를 단일 소스로

+

Single source of truth across CLIs

+
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
+ + +

#10계명The Ten Commandments

+ +
+
RULE 01

먼저 이해하라.

코딩 전에 문제, 목표, 영향 범위, 기대 결과를 다시 말하라. 조용히 가정하지 마라.

+
RULE 02

불확실성을 드러내고 선택지를 제시하라.

요건이 모호하면 물어라. 해석이 여러 개면 합리적인 접근 2~3가지와 함께 제시하고, 가장 단순·지속 가능한 것을 추천하라. 위험하면 위험하다고 말하라.

+
RULE 03

단위는 작고 응집력 있게.

파일 하나 = 목적 하나, 함수 하나 = 일 하나. 함수 ≤50줄, 중첩 ≤4. 파일이 여러 관심사를 섞으면 타입이 아니라 기능/도메인으로 쪼개라.

+
RULE 04

탐색한 다음 작은 단계로 계획하라.

변경 제안 전 관련 코드를 먼저 읽어라. 검증 가능한 단계로 쪼개고, 각 단계에 자체 점검을 포함하라.

+
RULE 05

변경은 외과적으로.

작업이 요구하는 부분만 만져라. 기존 스타일을 따르라. 무관한 코드를 리팩터링/이름 변경/포맷/정리하지 마라.

+
RULE 06

재발명 전에 재사용; 단순함을 택하라.

기존 유틸·패턴·파일을 먼저 검색하라. 올바르게 푸는 최소 코드를 써라. 추측성 기능·일반화·불필요한 설정 가능성을 피하라.

+
RULE 07

근본 원인을 고쳐라.

에러를 숨기거나 실패를 침묵시키거나 가짜 성공 경로를 추가하거나 증상을 패치하지 마라. 왜 발생했는지 찾고 그것을 고쳐라.

+
RULE 08

신뢰 전에 테스트.

버그는 실패하는 테스트로 먼저 재현. 기능은 기대 동작을 테스트로 정의. 테스트 실패 → 최소 수정 → 테스트 통과.

+
RULE 09

완료를 주장하기 전에 검증.

관련 테스트, 린트, 타입 체크, 빌드, 통합 검사를 실행하라. 무엇을 검증했는지 정확히 보고하라. 증거 없이 성공을 주장하지 마라.

+
RULE 10

시스템을 보호하라.

사이드 이펙트(데이터, API, 권한, 마이그레이션, 캐시, 동시성, 보안, 하위 호환)를 고려하라. 시크릿을 하드코딩하지 마라. 파괴적 삭제 명령은 명시적 확인 없이 실행하지 마라.

+
+ +
+
RULE 01

Understand first.

Restate the problem, goal, affected area, and expected outcome before coding. Do not assume silently.

+
RULE 02

Surface uncertainty; offer options.

If requirements are unclear, ask. If interpretations differ, present 2–3 reasonable approaches and recommend the simplest sustainable one. If the request is risky, say so.

+
RULE 03

Keep units small and cohesive.

One file = one purpose; one function = one job. Functions ≤50 lines, nesting ≤4. Split by feature/domain — not by type. Cohesion beats line count.

+
RULE 04

Explore, then plan in small steps.

Read the relevant code before proposing changes. Break work into verifiable steps; each step has its own check.

+
RULE 05

Keep changes surgical.

Touch only what the task requires. Match existing style. Do not refactor, rename, reformat, or clean unrelated code.

+
RULE 06

Reuse before reinventing; choose simplicity.

Search for existing utilities, patterns, and files first. Write the minimum code that correctly solves the problem. Avoid speculative features and unnecessary configurability.

+
RULE 07

Fix root causes.

Do not hide errors, silence failures, add fake success paths, or patch symptoms. Find why the problem happens and fix that.

+
RULE 08

Test before trusting.

For bugs, reproduce with a failing test first. For features, define expected behavior with tests. Test fails → minimal fix → test passes.

+
RULE 09

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.

+
RULE 10

Protect the system.

Consider side effects: data, APIs, permissions, migrations, caching, concurrency, security, backward compatibility. Never hardcode secrets. Never run destructive deletion without explicit confirmation.

+
+ + +

#응답·문서 스타일Response & Documentation Style

+ +

10계명이 무엇을 하는가를 다룬다면, 이 섹션은 어떻게 말하는가를 다룹니다 — 응답, 커밋 메시지, 문서 갱신, 코드 주석 모두에 적용.

+

The Ten Commandments govern what the agent does. This section governs how it communicates: responses, commit messages, doc updates, comments.

+ +
+ + +
+ + +

#설계 노트Design Notes

+ + + + +

#관련 자료Related

+ + + +
+ + + + + +