code-to-docslisted

# 코드 → 문서 (Layer 6 · 진입) ## 이 스킬의 목적 Layer 0~5 는 "문서 → 코드" 한 방향이다. 그런데 실제로 손에 들어오는 프로젝트의 상당수는 반대다 — 코드는 돌아가는데 무엇을 만들었는지 적힌 문서가 없다. 이 플러그인의 모든 스킬은 **앞 레이어의 파일**을 읽고 움직이므로, 문서가 없으면 refactor-plan 도 feature-add 도 bug-fix 도 설 자리가 없다. 이 스킬은 그 코드베이스를 플러그인에 **올리는 진입로**다. 코드를 읽어 세 문서를 쓰고, 기존 스킬 셋을 불러 플랜·하네스·루프를 세운다. 끝나면 그 프로젝트는 처음부터 이 플러그인으로 만든 완료 프로젝트와 같은 상태가 된다. ``` 문서 없는 코드 → docs/PRD.md · TRD.md · ARCHITECTURE/ (as-is — 지금 이렇게 되어 있다) ← 이 스킬이 직접 쓴다 → plan_setup/ phase-01-baseline (as-is 동작을 붙잡는 테스트 태스크만) ← plan-generator 를 부른다 → harness_setup/ (게이트 넷 + local-dev) ← harness-setup 을 부른다 → loop_setup/LOOP.md ← loop-setup 을 부른다 → 개발 루프 한 번 → phase-01 completed → 게이트 활성 ← 사용자가 돌린다 ``` **왜 문서만 만들고 끝내지 않는가.** 문서 없는 코드를 고칠 때 가장 위험한 것은 **무엇이 깨졌는지 모르는 것**이다. 리팩토링이나 기능 추가 전에 지금 동작을 붙잡는 게이트가 실제로 활성이어야 하고, 게이트는 플랜의 태스크 ID 를 활성 시점으로 갖는다(Layer 4). 그래서 하네스는 플랜 없이는 서지 않고, 플랜은 문서 없이는 서지 않는다. 셋을 한 번에 세워야 진입이 끝난다. ### 여기서 하는 일과 하지 않는 일 | 하지 않는 것 | 어디서 하는가 | |---|---| | 코드를 고치는 것 — 버그처럼 보여도, 중복이 눈에 띄어도 | 버그는 `bug-fix`, 구조는 `refactor-plan`. 둘 다 phase-01 완료 뒤 | | "이렇게 되어야 한다"를 적는 것 — 목표 요구사항, 바꿀 기술 결정, 더 나은 구조 | `feature-add`·`refactor-plan` 이 후미 절로 더한다 | | 플랜·하네스·루프의 내용을 정하는 것 | `plan-generator`·`harness-setup`·`loop-setup`. 이 스킬은 **부를 때 넘길 지시**만 정한다 | | 개발 루프를 도는 것 (phase-01 완료) | 사용자가 `LOOP.md` 대로 한 번 돌린다 | | 이미 문서가 있는 프로젝트의 문서 갱신