Design: $ARGUMENTS
docs/design-process.md의 모든 단계를 따릅니다 — 이 파일이 규칙이며, 이 스킬은 작업 순서만 정의합니다. 충돌 시 해당 파일을 우선합니다.
- 설계가 필요한가? —
docs/design-process.md의 섹션 1 표와 비교- 필요 없음: 한 줄로 이유를 설명하고
new-feature로 돌아갑니다. - 확실하지 않음: 먼저 사용자에게 질문합니다.
- 필요 없음: 한 줄로 이유를 설명하고
- 시작 (섹션 3.0): epic 이슈 (
design레이블), 브랜치docs/<id>-design-<slug>,docs/design/template.md를docs/design/<slug>.md로 복사 (system.md또는<epic 번호>-<slug>.md),status: draft로 설정하고docs/design/README.md에 행을 추가합니다. - 질문 전에 읽기:
CONTEXT.md,docs/adr/,docs/architecture.md,docs/design/의 다른 설계 문서 — 스스로 찾을 수 있는 정보는 직접 찾고, 질문하지 않습니다. - 인터뷰 라운드 진행 (섹션 3.1): 각 질문은
Qn — 주제: 질문+권장사항: …형식, 각 라운드마다 1–2개의 경계 사례를 포함합니다 — A–H 가지(섹션 3.2)를 모두 탐색하고 승인 지점 1, 2(system), 3에서 사용자 입력을 기다립니다. - 매 라운드 후 파일 업데이트: 설계 파일의 섹션,
CONTEXT.md의 새 용어,docs/adr/에proposed상태의 ADR (+ 인덱스 업데이트), 컨테이너/외부 시스템이 변경된 경우docs/architecture.md의 C4 다이어그램을 업데이트합니다. - 검증 (섹션 3.3):
make docs-check통과 필요 (Makefile에 해당 대상이 없는 저장소:python3 <web-template 경로>/scripts/check-docs.py <repo>— Hermes 팀:/home/opc/projects/web-template) + 자체 체크리스트를 수행한 후status: proposed로 설정합니다. - 문서 전용 PR:
docs(design): <slug>, 본문에Refs #<epic>, 아직 열린 대안 요약,## CHANGELOG섹션에-포함 — 코드는 절대 포함하지 않으며, 머지하지 않습니다. - 승인 (섹션 3.4): 승인자가 커밋하면
status: approved+approved-by설정, 같은 PR에서 ADR을accepted로 변경 (make docs-check통과 필요), 이후 사용자가 머지합니다. - 머지 후 (섹션 3.5): 섹션 13에 따라 하위 이슈를 하나씩 생성하고, 각 이슈는 epic과 설계 파일을 링크합니다 — 코드 작업은
new-feature로 시작합니다.