Harness
The complete guide — all six sections.
Setup
Environment, logging, and session management essentials
- 1
병렬로 App이 뜰 수 있게 만든다.
- 병렬 실행시 재시작되거나 Kill 하거나 다른 App에서 테스트하는 경우를 방지한다.
- 포트 충돌 방지할 수 있게 만든다.
- 2
log를 파일로 남긴다. backend error를 복붙하는거 병목이다.
- timestamp와 로그가 발생한 파일도 작성해둔다.
- 1줄로 남긴다. grep으로 한 방에 찾을 수 있게.
- 3
CLAUDE.md (AGENTS.MD) 는 목차(Table of Contents)로만 쓴다.
- docs/ 에 architecture, schema 등 몰아 넣는다.
- 4
세션 관리
- 한 화면에 2개 이상 세션은 안둔다. 인지력 부하가 온다
- 탭으로 나눈다
- 탭에 이름을 넣고 필요할 때만 나중에 이어서 작업할 때만 세션에 이름을 부여한다.
- 5
Plugin을 쓰되 SKILL.md 를 공부하고 사용한다. + 자신의 입맛에 수정해서 쓴다.
Spec
Requirements clarity before writing any code
- 1
스펙 문서는 읽는다.
- 급하거나 피곤하면 안 읽는다. 하지만 결국 읽는게 빠르다.
- 2
UI Component가 추가되는 Spec은 Terminal 내에서라도 Mock UI를 그려달라고 한다.
- UX Designer & Product Owner 두 관점을 (병렬로) 고려해서 스펙을 작성해달라고 한다.
- 3
Vague, Unknown 을 최대한 없앤다.
Plan
Structured implementation strategy with DAG ordering
- 1
구현 순서를 DAG로 나타내라고 한다. (이 정도 하면 알아서 병렬 실행해준다)
- 2
Plan이 Spec과 일치하는지 검토한다. 달라지는 경우가 있음.
- 3
architecture, framework 결정, schema 설계 수준의 high level 기술적 결정은 "읽고 이해한다"
- 4
Verification Plan도 같이 세우라고한다.
- 백엔드만 테스트하면 되는지 프론트엔드, E2E도 필요한지
- 성공 조건을 읽는다.
Execution
Model selection, continuous work, and quality hooks
- 1
frontier model이 아니어도 되는 작업이면 모델 바꿔서 실행한다. plan에 opus를 쓰고 execution은 sonnet 쓰는것도 방법.
- 2
verification이 완료될때까지 계속 작업하라고 시키기
- 3
작업 종료 알림 받기
- 4
worktree를 알아서 생성해서 작업하게 한다
- 5
syntax error를 잡는 hook은 꼭 걸어둔다
- line 수, style formatter 같은 인간을 위한 건 필요없다
Verification & Review
Systematic checking and continuous improvement loops
- 1
Verification 도구를 인지하고 개선해나간다.
- 2
Spec/ Plan 에 있는 내용 구현되었는지 검토하라고 시킨다.
- 3
선입력 시킨다. (자동화?)
- 4
review agent를 만든다.
- 5
버그는 test coverage로 남기고 compound한다.
Compound
Turn every session into lasting organizational knowledge
- 1
버그 수정이 아닌 기능 추가 Spec 문서는 docs/ 또는 requirements/ 에 저장한다.
- 2
"이번에 에이전트가 멍청하게 행동한 부분이 어디인가?" → 오답 노트 추가
- 3
"내가 말해주지 않았으면 에이전트가 몰랐을 내 취향은 무엇인가?" → 취향(Taste) 문서화
- 4
"이 문제는 나중에도 또 발생할 것 같은가?" → 해결책(Solution) 저장 또는 린터 추가
References
Articles and talks that shaped this workflow.