---
description: 정련된 FRD.md를 받아 실행 가능한 PLAN.md(작업 분해)로 만든다. 요구사항을 단일·검증가능·증분 Task로 쪼개고, TASK-ID·`[P]` 병렬 마커·`size` 크기 마커(실행 라우팅 신호)·`test` 테스트 필요 여부 마커·`file:`·`traces:`를 부여하며, PR 단위로 그룹핑하고 의존성 그래프와 Definition of Done을 작성한다. 모든 REQ/AC/CTR/EDGE가 traces로 커버되는지(누락 0) 검증한다. "FRD를 작업으로 분해해줘", "PLAN 짜줘", "태스크/PR 나눠줘", "스펙→태스크 분해", "작업 계획 세워줘" 같은 요청에서 사용한다. 분해 후 실행은 devoks-sdlc:feature-plan-executor, 전체 흐름은 devoks-sdlc:feature-workflow-runner.
metadata:
  author: ridsync
  version: 1.3.0
---

# plan-author — PLAN 작성 (Phase 2)

FRD를 추적 가능하고 PR 단위로 분리된 작업 분해로 변환한다. `devoks-sdlc:feature-workflow-runner` 의 **Phase 2만** 단독 실행한다.
공유 자산/레퍼런스는 통합 스킬 디렉터리를 참조한다(SSOT).

## 호출 방법

```
/devoks-sdlc:feature-plan-author [frd=<FRD.md 경로>] [out=<산출물 디렉터리>]
```

- `out` 기본값 = FRD.md가 있는 워크스페이스(`.claude/workspace/{feature-name}-{date}/`). 산출물 = `<out>/PLAN.md`. → `../feature-workflow-runner/references/output-location.md`
- PLAN은 워크스페이스에 저장하되, 각 Task의 `file:`은 항상 **프로젝트 본래 코드 위치**를 가리킨다(워크스페이스 아님).

## 절차

0. **FRD 승인 처리** — `FRD.md` 로드 시 frontmatter `status`가 `review`이면 `approved`로 갱신(FRD 최종 상태). → `../feature-workflow-runner/references/progress-tracking.md`
1. **골격 로드** — `../feature-workflow-runner/assets/PLAN.template.md` 형식을 따른다.
2. **Approach·Resource** — §1 구현 방식·PR 분리 방침, §2 Resource Check(FRD §6에서 가져옴).
3. **Task 분해** — 단일·검증가능·증분. 각 Task에 `TASK-ID`, (가능하면)`[P]`, `size`(S/M/L — 실행 라우팅 신호, 애매하면 M), `test`(required/skip — 테스트 필요 여부, 애매하면 required), `file:`, `traces:` 부여. `L`은 분해 재검토 신호 — 원칙적으로 더 쪼개고, 못 쪼개면 §1에 사유 1줄을 **스펙 닫힘 축/판단 축 중 어느 것인지 밝혀** 남긴다(실행 라우팅이 이 기록을 읽는다). `test`는 `code-implementer`가 실행 중 스스로 재판단하지 않고 그대로 따르는 값이므로 이 단계에서 확정한다. → `../feature-workflow-runner/references/task-pr-splitting.md`
4. **PR 그룹핑** — 기본값 PR 1개. FRD의 메모는 참고일 뿐, `task-pr-splitting.md` 기준으로 이 단계에서 직접 재판단한다(애매하면 AskUserQuestion). 분리 시 §1에 근거 1줄. → `../feature-workflow-runner/references/task-pr-splitting.md`
5. **그래프·DoD** — §4 mermaid 의존성 그래프(사이클 금지), §5 Definition of Done.
6. **커버리지 검증(누락 0)** — FRD의 모든 `AC/CTR/EDGE`가 어떤 Task `traces`에 등장하는지 점검. → `../feature-workflow-runner/references/traceability.md` 의 comm 스크립트.
7. **작성** — 누락이 없을 때만 `<out>/PLAN.md` 작성. 있으면 담당 Task 추가 후 재검증.

## 완료 기준

- 모든 Task가 `size:`·`test:`·`file:`·`traces:`를 가짐, ID 규칙(`TASK-\d+`) 준수.
- `[P]` 가 의존성 그래프와 모순 없음(병렬 Task는 서로를 가리키지 않음).
- `size: L` Task가 남아 있으면 §1에 분해 불가 사유 명시 — **스펙 닫힘 축인지 판단 축(설계 변경·인터페이스 파급)인지 밝혔는지** 확인(실행 라우팅의 위임/직접 판정 근거).
- `size` 분포 자기점검 — 양방향으로 확인한다. ⑴ `S`가 부여 기준의 **`S` 열거를 벗어나지 않았고** `test: required` Task에 `S`가 붙지 않았는지(**`required` ⇒ 최소 `M`**), ⑵ 그 열거에 해당하는 후보가 있는데도 전부 `M`으로만 부여되지 않았는지 — 열거 원문은 `../feature-workflow-runner/references/task-pr-splitting.md`(부여 기준 SSOT)에서 확인하고 여기에 복제하지 않는다.
- `test` 분포 자기점검 — `skip`을 부여한 Task에 실제로 로직(비즈니스 로직·상태 전이·데이터 흐름·계약 검증·조건부 분기)이 없는지 재확인. 애매해서 `skip`으로 몰아넣지 않았는지 확인 — 부여 기준: `../feature-workflow-runner/references/task-pr-splitting.md`.
- 1개 이상 PR 생성(기본 1개). 2개 이상이면 §1에 분리 근거(기능/위험/리뷰 부담 중 하나) 명시 + PR 간 의존 단방향 준수.
- 커버리지 점검 출력 공백(누락 0), DoD 섹션 존재.
- `PLAN.md` 작성 완료 시 frontmatter `status: draft → approved`. → `../feature-workflow-runner/references/progress-tracking.md`

> 형식이 헷갈리면 `../feature-workflow-runner/references/example-walkthrough.md` 참고.