writing-planslisted

# writing-plans 승인된 스펙을 구현자가 그대로 실행할 수 있는 플랜으로 바꾼다. 플랜 승인이 마지막 사용자 게이트다. 여기를 지나면 구현·검증은 자율이다. 산출물은 `docs/plans/PLAN-NNNN-<topic>.md`다. 경로·명명·번호 규약 정본은 `groundwork:finding-unknowns`의 「산출물 규약」 절이다. ## 입력 승인된 스펙 파일의 경로를 호출자에게 받는다. `groundwork:finding-unknowns`가 스펙 승인 직후 이 스킬로 넘기면서 그 경로를 준다. 사용자가 직접 불러 경로가 없으면 어느 스펙의 플랜을 쓸지 묻는다. 스펙 없이 플랜을 시작하지 않는다. 번호 재사용과 `spec-alignment` 리뷰가 둘 다 스펙 경로에 의존한다. ## 독자 가정 **REQUIRED SUB-SKILL**: 플랜 본문을 쓰기 전에 `groundwork:writing-for-junior`(맥락 없는 주니어 독자 기준의 작성 규범과 판정 렌즈)를 로드한다. 독자 정의와 작성 처방의 정본이 거기 있고, 리뷰의 `junior-read` 렌즈가 같은 기준으로 판정한다. 플랜의 독자에게는 그 정의에 더 붙는 것이 있다. - **좋은 테스트 설계에 밝지 않다.** 무엇을 어떻게 검증할지를 구현자 판단에 맡기지 않고 플랜이 정한다. - **한 태스크만 본다.** 태스크마다 fresh 구현자가 붙고 세션 히스토리를 상속받지 않는다. 플랜에 없는 것은 그에게 도달하지 않고, 이웃 태스크에만 적힌 것도 도달하지 않는다. 그래서 어느 파일을 건드리는지, 무엇을 쓰는지, 어떻게 검증하는지를 태스크마다 그 안에 적는다. ## 번호 재사용 플랜 파일의 4자리 번호와 `<topic>`은 대응 스펙 파일명에 이미 박힌 값을 그대로 복사한다. `<topic>`은 파일명 슬러그이고, 문서 h1의 `<제목>`은 사람이 읽는 명사구라 둘은 같은 값이 아니다. topic 문자열로 매칭하지 않고, 새 번호를 발급하지도 않는다. 스펙 `docs/specs/SPEC-0042-foo.md`의 플랜은 `docs/plans/PLAN-0042-foo.md`다. ## 범위 점검 스펙이 독립 서브시스템 여럿을 덮으면 스펙 단계에서 갈렸어야 한다. 갈리지 않은 채 넘어왔으면 서브시스템마다 별도 스펙·플랜으로 쪼갤 것을 제안한다. 플랜 하나는 그 자체로 동작하고 테스트되는 소프트웨어를 낳아야 한다. 대형 작업의 단계는 플랜 문서 내부의 단계로 표현한다. 플랜 파일을 쪼개지 않는다. ## 파일 구조 태스크를 정의하기 전에 어느 파일이 생기고 바뀌는지, 각 파일이 무엇을 책임지는지 먼저 그린다. 분해 결정이 여기서 확정된다. - 경계가 뚜렷하고 인터페이스가 명확한 단위로 설계한다. 파일 하나가 책임 하나를 진다. - 한 컨텍스트에 담기는 코드일수록 판단이 정확하고 편집이 안정된다. 너무 많은 일을 하는 큰 파일보다 초점이 좁은 작은 파일을 택한다. - 함께 바뀌는 파일은 함께 둔다. 기술 계층이 아니라 책임으로 가른다. -