Claude Rules (Claude.md)

~/.claude/CLAUDE.md           # 전역: 개인 취향, 공통 개발 습관
./.claude/CLAUDE.md           # 프로젝트: 팀 공유 표준
./CLAUDE.md                   # 프로젝트 루트 표준
./.claude/CLAUDE.local.md     # 로컬 개인 노트, gitignore 권장

~/.claude/CLAUDE.md           # 전역: 개인 취향, 공통 개발 습관
./.claude/CLAUDE.md           # 프로젝트: 팀 공유 표준
./CLAUDE.md                   # 프로젝트 루트 표준
./.claude/CLAUDE.local.md     # 로컬 개인 노트, gitignore 권장

## Project Standards
- Python 3.12, FastAPI, LangGraph, Pydantic v2 사용
- TypeScript는 strict mode 유지
- 에러는 명시적으로 처리하고 조용히 삼키지 않음
- 테스트는 변경 범위에 맞춰 `pnpm test`, `pnpm lint` 우선 실행

## Project Standards
- Python 3.12, FastAPI, LangGraph, Pydantic v2 사용
- TypeScript는 strict mode 유지
- 에러는 명시적으로 처리하고 조용히 삼키지 않음
- 테스트는 변경 범위에 맞춰 `pnpm test`, `pnpm lint` 우선 실행

~/.codex/AGENTS.md            # 전역: 개인 기본 지침
./AGENTS.md                   # 저장소 루트: 프로젝트 공통 지침
./subdir/AGENTS.md            # 하위 디렉터리: 영역별 세부 지침
AGENTS.override.md            # 기존 지침을 임시 또는 명시적으로 덮어쓰는 지침

~/.codex/AGENTS.md            # 전역: 개인 기본 지침
./AGENTS.md                   # 저장소 루트: 프로젝트 공통 지침
./subdir/AGENTS.md            # 하위 디렉터리: 영역별 세부 지침
AGENTS.override.md            # 기존 지침을 임시 또는 명시적으로 덮어쓰는 지침

## 1. Prefer existing commands and skills

Before starting a non-trivial task, check whether a relevant command or skill exists.

Use command-driven workflows for structured tasks such as planning, implementation loops, stack management, verification, or multi-step coding work.

Do not duplicate a command's internal process in normal responses. If a command already defines the workflow, follow the command.

If the user explicitly names a command, use that command's intended workflow rather than improvising a parallel process.

## 2. Be clear before changing code

Do not assume hidden requirements.

Before making meaningful code changes, briefly identify the goal and any important assumptions.

If the task is ambiguous, ask a focused question or state the assumption you will proceed with.

Push back when the requested approach seems unnecessarily complex, risky, or inconsistent with the project.

## 3. Keep changes simple

Implement the smallest change that solves the requested problem.

Avoid speculative features, premature abstractions, and unnecessary configurability.

Do not add new dependencies unless clearly justified.

If a simpler solution exists, prefer it.

## 4. Make surgical edits

Touch only the files and lines needed for the task.

Do not refactor unrelated code.

Do not reformat unrelated sections.

Match the existing project style, even if another style might be preferable.

Remove only unused code introduced by your own changes unless the user asks for broader cleanup.

## 5. Verify work when practical

If code was changed, run the most relevant project check when feasible.

Prefer the existing project commands for tests, builds, linting, or type checking.

If a command or skill defines the verification process, follow that instead.

If verification cannot be run, say what was not verified and why.

## 6. Read actual errors

When something fails, inspect the real error message, stack trace, logs, or failing output.

Do not guess from memory before checking the concrete failure.

Fix the confirmed cause, not a similar-looking problem.

## 7. Be careful with destructive actions

Do not delete files, rewrite history, reset branches, drop databases, clear indexes, or run destructive scripts unless the user explicitly asks or the active command requires it.

Before irreversible actions, explain the risk and confirm when appropriate.

## 8. Git behavior

Do not commit automatically unless the user asks or the active command explicitly includes commit behavior.

When making commits, keep each commit to one logical change.

Use concise, semantic commit messages.

## 9. Korean response style

When the user writes in Korean, respond in Korean unless there is a clear reason not to.

End Korean sentences with `.`, `?`, or `!`, not with a closing colon.

Colons are fine inside code, key-value pairs, labels, and command examples.

## 10. New file headers

When creating a new source file, add a one-line Korean comment at the top explaining the file's role.

Place it below required directives such as `'use client'`, `'use server'`, or a shebang.

Skip this for config files, JSON files, lock files, generated files, and files where such a comment would be inappropriate.

## 1. Prefer existing commands and skills

Before starting a non-trivial task, check whether a relevant command or skill exists.

Use command-driven workflows for structured tasks such as planning, implementation loops, stack management, verification, or multi-step coding work.

Do not duplicate a command's internal process in normal responses. If a command already defines the workflow, follow the command.

If the user explicitly names a command, use that command's intended workflow rather than improvising a parallel process.

## 2. Be clear before changing code

Do not assume hidden requirements.

Before making meaningful code changes, briefly identify the goal and any important assumptions.

If the task is ambiguous, ask a focused question or state the assumption you will proceed with.

Push back when the requested approach seems unnecessarily complex, risky, or inconsistent with the project.

## 3. Keep changes simple

Implement the smallest change that solves the requested problem.

Avoid speculative features, premature abstractions, and unnecessary configurability.

Do not add new dependencies unless clearly justified.

If a simpler solution exists, prefer it.

## 4. Make surgical edits

Touch only the files and lines needed for the task.

Do not refactor unrelated code.

Do not reformat unrelated sections.

Match the existing project style, even if another style might be preferable.

Remove only unused code introduced by your own changes unless the user asks for broader cleanup.

## 5. Verify work when practical

If code was changed, run the most relevant project check when feasible.

Prefer the existing project commands for tests, builds, linting, or type checking.

If a command or skill defines the verification process, follow that instead.

If verification cannot be run, say what was not verified and why.

## 6. Read actual errors

When something fails, inspect the real error message, stack trace, logs, or failing output.

Do not guess from memory before checking the concrete failure.

Fix the confirmed cause, not a similar-looking problem.

## 7. Be careful with destructive actions

Do not delete files, rewrite history, reset branches, drop databases, clear indexes, or run destructive scripts unless the user explicitly asks or the active command requires it.

Before irreversible actions, explain the risk and confirm when appropriate.

## 8. Git behavior

Do not commit automatically unless the user asks or the active command explicitly includes commit behavior.

When making commits, keep each commit to one logical change.

Use concise, semantic commit messages.

## 9. Korean response style

When the user writes in Korean, respond in Korean unless there is a clear reason not to.

End Korean sentences with `.`, `?`, or `!`, not with a closing colon.

Colons are fine inside code, key-value pairs, labels, and command examples.

## 10. New file headers

When creating a new source file, add a one-line Korean comment at the top explaining the file's role.

Place it below required directives such as `'use client'`, `'use server'`, or a shebang.

Skip this for config files, JSON files, lock files, generated files, and files where such a comment would be inappropriate.