엔지니어
발견 작업을 두 가지 지속 가능한 산출물로 종합합니다: /implement가 실행할 수 있는 명세서와, 기억할 가치가 있는 결정에 대한 ADR.
입력: $ARGUMENTS.
침묵하는 가정은 없습니다. 모든 설계 결정은 사용자가 직접 내리거나 가정으로 나열됩니다. 여기에는 너무 사소해서 물어보기 어렵다고 느껴지는 선택(라이브러리, 오류 형식, 네이밍, 기본값, 제한), 코드베이스에서 추론한 내용, 그리고 여러분의 권장 사항이 모두 포함됩니다. 전체 과정 동안 가정 원장(✅ 사용자 확인 · ❓ 미확인 · ❌ 거부됨)을 유지하며, 확인되지 않은 선택을 결정 사항으로 명세나 ADR에 절대 기록하지 마세요.
프로세스
- 정제. 이 세션에 정제된 브리프가 아직 없다면 먼저
/refine프로세스를 실행하세요(질문 → 승인 기준). 설계를 막는 미해결 질문이 있는 상태로 진행하지 마세요. 브리프가 이미 있다면 그 안의 ❓ 가정들을 원장으로 가져오고, 해당 가정에 의존하는 모든 설계를 시작하기 전에 해결하세요. - 모델링. 새로운 개념이나 변경된 개념이 있으면
/domain-modelling프로세스를 실행하고 도메인 문서를 업데이트하세요. 명세서는 반드시 정식 용어를 사용해야 합니다. - 코드베이스 탐색. 변경 사항이 영향을 미치는 모듈, 인터페이스, 데이터 저장소, 테스트를 식별하세요. 따라야 할 기존 패턴을 기록하세요. 실제 경로를 참조하세요. 오늘날 코드가 하는 일은 증거이지 의도가 아닙니다: "
src/x.ts의 기존 패턴을 따르세요"는 그 자체로 사용자와 확인해야 할 선택이며, 출처와 함께 기록되어야 합니다. - 설계. 각 중요한 결정에 대해 장단점과 권장 사항이 포함된 2~3개의 옵션을 제시하고, 사용자가 결정하며, 사용자가 명시적으로 선택해야만 권장 사항으로 간주됩니다. 더 작은 선택의 경우 스스로 결정하지 말고 하나의 확인 목록으로 모아서 제시하세요. 데이터 모델 및 마이그레이션, API/계약 변경, 오류 처리, 보안, 성능, 관찰 가능성, 롤아웃 및 롤백, 이전 버전과의 호환성을 고려하세요.
- ADR 기록. 결정이 되돌리기 어렵거나, 여러 모듈에 영향을 주거나, 미래의 엔지니어가 "왜 이렇게 했을까?"라고 궁금해할 만한 경우 ADR을 작성해야 합니다. 각 ADR은
docs/adr/NNNN-케밥-제목.md(다음 사용 가능한 번호, 4자리)에 adr-template.md를 사용하여 작성하세요. ADR이 다른 ADR을 대체하는 경우 기존 ADR의 상태를 업데이트하세요. 사용자가 결정을 확인한 경우에만 ADR을승인됨으로 표시하고, 그렇지 않으면제안됨으로 유지하세요. - 명세서 작성.
docs/specs/<케밥-제목>.md에 spec-template.md를 사용하여 명세서를 작성하세요. 작업을 작고, 순서가 정해져 있으며, 독립적으로 테스트 가능한 작업으로 나누세요 — 각 작업에는 이를 증명할 테스트가 포함되어야 합니다. 명세서의 가정 섹션을 원장에서 채우세요. 모든 설계 문장은 사용자 결정으로 추적되거나 ❓로 그곳에 나타나야 합니다. - 사용자와 검토. 명세서와 ADR을 요약하고, 열려 있는 ❓ 항목을 보여주고, 서명을 요청하고, 조정하세요. ❓가 작업, 승인 기준 또는 ADR에 영향을 미치는 동안에는 명세서를
승인됨으로 설정하지 마세요.
규칙
- 프로젝트에 이미 명세서나 ADR 폴더/템플릿이 있는 경우 기존 규칙을 존중하고 그것들을 대신 사용하세요.
- 명세서는 무엇을 할 것인지와 어떻게 검증할 것인지를 설명하며, 모호함을 제거할 수 있는 충분한 방법을 포함해야 합니다 — 줄 단위 구현이 아닙니다.
- 모든 승인 기준은 적어도 하나의 작업과 테스트에 매핑되어야 합니다.
- 변경 사항이 허용하는 한 최대한 간결하게 유지하세요.
다음 단계
/handoff (새 세션에서 구현을 시작하려면) 또는 /implement docs/specs/<파일>.md를 직접 실행할 것을 권장합니다.