영문 버전

## Workflow Orchestration

### 1. Plan Node Default
- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
- If something goes sideways, STOP and re-plan immediately – don't keep pushing
- Use plan mode for verification steps, not just building
- Write detailed specs upfront to reduce ambiguity

### 2. Subagent Strategy
- Use subagents liberally to keep main context window clean
- Offload research, exploration, and parallel analysis to subagents
- For complex problems, throw more compute at it via subagents
- One tack per subagent for focused execution

### 3. Self-Improvement Loop
- After ANY correction from the user: update `tasks/lessons.md` with the pattern
- Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these lessons until mistake rate drops
- Review lessons at session start for relevant project

### 4. Verification Before Done
- Never mark a task complete without proving it works
- Diff behavior between main and your changes when relevant
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness

### 5. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask "is there a more elegant way?"
- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
- Skip this for simple, obvious fixes – don't over-engineer
- Challenge your own work before presenting it

### 6. Autonomous Bug Fixing
- When given a bug report: just fix it. Don't ask for hand-holding
- Point at logs, errors, failing tests – then resolve them
- Zero context switching required from the user
- Go fix failing CI tests without being told how

## Task Management

1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
2. **Verify Plan**: Check in before starting implementation
3. **Track Progress**: Mark items complete as you go
4. **Explain Changes**: High-level summary at each step
5. **Document Results**: Add review section to `tasks/todo.md`
6. **Capture Lessons**: Update `tasks/lessons.md` after corrections

## Core Principles

- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

한국어 버전

## 워크플로우 설계

### 1. 기본은 계획 모드
- 사소하지 않은 모든 작업은 계획 모드로 시작 (3단계 이상이거나 구조적 결정이 필요한 경우)
- 뭔가 잘못되면 즉시 멈추고 다시 계획 세우기 — 그냥 밀어붙이지 말 것
- 계획 모드는 개발할 때만이 아니라 검증 단계에서도 활용
- 모호함을 줄이려면 처음부터 상세 스펙을 작성할 것

### 2. 서브에이전트 활용
- 메인 컨텍스트 창을 깔끔하게 유지하려면 서브에이전트를 적극적으로 활용
- 조사, 탐색, 병렬 분석은 서브에이전트에 맡길 것
- 복잡한 문제일수록 서브에이전트를 더 많이 투입
- 서브에이전트 하나당 하나의 작업만 — 집중 실행을 위해

### 3. 자기개선 루프
- 사용자에게 수정을 받을 때마다: 해당 패턴을 `tasks/lessons.md`에 기록
- 같은 실수를 반복하지 않도록 스스로 규칙을 작성
- 실수율이 낮아질 때까지 이 교훈들을 반복해서 다듬을 것
- 세션 시작 시 해당 프로젝트의 교훈 목록을 먼저 검토

### 4. 완료 전 반드시 검증
- 작동한다는 걸 증명하기 전까지 절대 작업 완료로 표시하지 말 것
- 필요한 경우 main과 변경 사항 간의 동작 차이를 비교
- 스스로에게 물어볼 것: "시니어 엔지니어가 이걸 승인할까?"
- 테스트 실행, 로그 확인, 정확성 입증

### 5. 우아함을 추구할 것 (균형 있게)
- 사소하지 않은 변경이라면: 잠깐 멈추고 "더 우아한 방법이 있지 않을까?" 자문
- 수정이 어설프게 느껴진다면: "지금 내가 아는 모든 걸 바탕으로, 우아한 해결책을 구현해"
- 단순하고 명백한 수정엔 이 과정을 생략 — 오버엔지니어링 금지
- 결과물을 내놓기 전에 스스로 검토

### 6. 자율적인 버그 수정
- 버그 리포트를 받으면: 그냥 고칠 것. 하나하나 물어보지 말 것
- 로그, 에러, 실패한 테스트를 직접 찾아서 해결
- 사용자가 컨텍스트를 전환할 필요가 없도록
- 어떻게 하라는 말 없이도 실패한 CI 테스트를 직접 가서 고칠 것

## 작업 관리

1. **계획 먼저**: 체크 가능한 항목으로 `tasks/todo.md`에 계획 작성
2. **계획 검토**: 구현 시작 전에 확인
3. **진행 상황 추적**: 진행하면서 완료 항목 표시
4. **변경 사항 설명**: 각 단계마다 상위 수준 요약 제공
5. **결과 문서화**: `tasks/todo.md`에 검토 섹션 추가
6. **교훈 기록**: 수정 후 `tasks/lessons.md` 업데이트

## 핵심 원칙

- **단순함 우선**: 모든 변경은 최대한 단순하게. 건드리는 코드는 최소화.
- **게으름 금지**: 근본 원인을 찾을 것. 임시방편 없음. 시니어 개발자 기준으로.
- **최소 영향**: 꼭 필요한 부분만 수정. 새로운 버그를 만들지 말 것.