저에게 시간적 손실을 가장 크게 안겨주는 Claude Code의 실패 모드는 나쁜 코드가 아닙니다. 제가 이미 결정했던 내용들을 세션이 다시 열어버리는 것입니다. 한 세션은 '확장성(scalability)'을 위해 데이터베이스를 교체하고, 또 다른 세션은 제가 의도적으로 평문으로 유지했던 문구를 재작성합니다. 모든 확정된 질문들이 마치 여전히 열려 있는 것처럼 영원히 남아있습니다. 그래서 저는 charter라는 도구를 만들었습니다. 이 도구는 작업 흐름(workstream)별로 마크다운 파일 하나를 작성하며, 엄격한 프론트매터 스키마를 사용합니다. 이 스키마에는 해당 문서가 소유하는 것, 고정된 제약 조건은 무엇인지, 그리고 진정으로 열려 있는 질문이 무엇인지를 명시합니다. 그런 다음 charter sync는 이 내용을 관리 마커(managed markers) 사이에 삽입하여 CLAUDE.md에 주입하고, 이는 에이전트가 다시 열어서는 안 되는 확정된 결정 사항으로 간주됩니다 (그리고 우회하는 대신 충돌을 표면화하도록 지시합니다). 이 저장소는 스스로에게 charter를 실행합니다. 즉, 자신의 범위 결정 사항들은 charters/ 디렉토리에 있으며, 여기에는 제가 출시 주간에 깨뜨리고 싶었던 내용들까지 포함되어 있습니다. 가장 유용한 부분은 의사결정 로그(decision log)입니다. charter log

이것은 의도적으로 지루한 기술입니다: 종속성 제로(zero-dependency) Node 스크립트 하나, 마크다운 입력(markdown in), 마크다운 출력(markdown out), 그리고 작은 e2e 테스트 스위트만 포함되어 있습니다. 어려운 부분은 코드가 아니라 무엇을 제외할지 결정하는 것이었습니다 (설정 시스템 없음, 통합 기능 없음, 호스팅되는 것 없음). 작업 가능한 환경으로 클론하는 데 10분이 넘지 않아야 합니다 — 만약 그렇지 않다면 그것은 버그이며 이에 대해 듣고 싶습니다. 다른 분들은 이것을 다르게 처리하시는지 궁금합니다 (직접 구현한 CLAUDE.md 규칙? 메모리 도구?). /u/alexjray가 제출했습니다 [링크] [댓글]