Lead Plan (Distribute Pattern)

Overview

승인된 Tech Spec을 분석하여 Epic → Story 구조를 생성하고, 각 Story에 난이도(S/M/L/XL)를 태깅한다. Story 문서가 5개 이상이면 Creator 에이전트를 병렬로 스폰하여 문서를 작성한다.

When to Use

```
bf-lead-orchestrate
```
가 스폰
직접 호출하지 않는다.

Prerequisites

승인된 Tech Spec:
```
docs/tech-specs/{TICKET}-tech-spec.md
```
Tech Spec 리뷰 통과 (사람 개입 ① 완료)

Error Handling

Tech Spec 파일 미존재:
```
"error: tech-spec not found at {경로}"
```
신호를 orchestrate에 전달 후 종료
Story Creator 스폰 실패: Lead가 직접 Story 문서를 작성 (4개 이하일 때와 동일하게 순차 처리)
conventions.md 미존재: 경고만 표시하고 난이도 태깅은 기본 기준으로 진행 (컨벤션 영향도 반영 불가)

Instructions

1. 초기 로딩

```
docs/tech-specs/{TICKET}-tech-spec.md
```
읽기
```
docs/conventions.md
```
읽기 (있으면) — 기존 도메인/아키텍처 규칙을 난이도 판정과 Story 분리 기준에 반영

2. Epic 도출

기능 단위 또는 도메인 단위로 에픽을 분리한다.
에픽 간 의존성을 명시한다.
에픽은 순차적으로 실행됨을 기준으로 순서를 결정한다.
Epic 최소 규모: Epic당 Story 3개 이상을 권장한다. Story 2개 이하인 Epic이 나오면 인접 Epic과 병합을 검토한다. 단, 도메인 경계가 명확하여 병합이 부자연스러운 경우(예: 인증 vs 결제)는 2개도 허용한다. Epic마다 E2E 검증·통합 리뷰·사람 확인 등 고정 오버헤드가 발생하므로, 불필요하게 작은 Epic은 피한다.
Story 0개 에픽 처리: 인프라 준비, 설정 변경 등 Story로 분해할 수 없는 에픽은 sprint-status.yaml에 Story 없이 에픽만 등록하고,
```
e2e: passed
```
로 초기화한다 (기본 템플릿의
```
pending
```
이 아닌
```
passed
```
로 직접 설정).

3. Story 구조 결정

각 Epic 내 Story를 결정한다:

Story는 병렬 실행 가능한 단위로 분리한다.
각 Story에 명확한 AC를 포함한다.
Story 간 의존성이 있으면 Dependencies 섹션에 명시한다.

4. 난이도 태깅

<HARD-GATE> 모든 Story에 반드시 난이도(S/M/L/XL)를 태깅해야 한다. 난이도 태그 없이 Story 문서를 완성하지 않는다. 난이도는 agent 구성(모델 선택, 팀 규모)을 결정하는 핵심 입력이다. </HARD-GATE>

각 Story에 난이도를 태깅한다:

난이도	기준
S (Simple)	단일 파일, 명확한 AC, 의존성 없음
M (Medium)	2~3 파일, 모듈 간 연결 있음
L (Large)	다수 파일, 아키텍처 영향 큼
XL (Complex)	크로스 레이어, 보안/성능 고려, 설계 판단 포함

```
docs/conventions.md
```
에 아키텍처 규칙이 정의되어 있으면, 해당 규칙의 영향을 받는 Story의 난이도를 상향 조정한다 (예: 컨벤션에 엄격한 보안 규칙이 있으면 관련 Story를 M→L로).

5. Story 문서 작성 (Distribute Pattern)

Story 5개 이상:

Creator 에이전트를 스폰한다 (
```
model: sonnet
```
).
각 Creator에게 전달:
- Story AC, Epic 컨텍스트, Story 문서 템플릿 (아래 Output Format 참조)
Lead가 모든 Creator의
```
"done"
```
+ story 파일을 수집한다.

Story 4개 이하:

Lead가 직접 순차적으로 Story 문서를 작성한다.

6. Sprint 식별자 결정

Sprint 식별자는 Jira 티켓 번호를 그대로 사용한다 (예:

HACKLE-13554

스폰 시 전달받은
```
{TICKET}
```
번호를 sprint-status.yaml의 최상위 키로 사용
```
docs/archive/
```
디렉토리에 이미 같은 티켓의 아카이브가 있으면 에러 보고

7. sprint-status.yaml 생성

<HARD-GATE> sprint-status.yaml의 모든 메트릭 필드(model_used, ralph_retries, ralph_approaches, review_blockers, review_recommended, failure_tag, is_regression, parent_story, ralph_stuck)를 기본값(0/null/false)으로 초기화해야 한다. 필드 누락은 이후 bf-metrics 분석을 오염시킨다. </HARD-GATE>

yaml

{TICKET}:
  epic-1:
    story-1:
      status: todo
      difficulty: S
      tdd: pending
      review: pending
      model_used: null
      ralph_retries: 0
      ralph_approaches: 0
      review_blockers: 0
      review_recommended: 0
      failure_tag: null
      is_regression: false
      parent_story: null
      ralph_stuck: false
    story-2:
      status: todo
      difficulty: M
      tdd: pending
      review: pending
      model_used: null
      ralph_retries: 0
      ralph_approaches: 0
      review_blockers: 0
      review_recommended: 0
      failure_tag: null
      is_regression: false
      parent_story: null
      ralph_stuck: false
    e2e: pending

메트릭 필드 기본값: 모든 필드는 0/null/false로 초기화. 각 필드는 이후 Lead 스킬들이 기록한다:
model_used
,
ralph_retries
,
ralph_approaches
,
ralph_stuck
: bf-lead-implement
review_blockers
,
review_recommended
: bf-lead-review
failure_tag
,
is_regression
,
parent_story
: E2E agent

8. 파일 저장 및 커밋

Story 파일:
```
docs/stories/{TICKET}-story-{N}.md
```
sprint-status.yaml:
```
docs/sprint-status.yaml
```
git commit하지 않는다 — docs/ 산출물은 Phase 4 Archive에서 일괄 커밋한다.

9. Done 신호

스폰한 상위 에이전트에 전달:
```
"done"
```
+ stories/ 경로 + sprint-status.yaml 경로
종료 (컨텍스트 소멸).

Output Format

Story 문서 템플릿

markdown

# {TICKET}-story-{N}: {Story 제목}

## 에픽
{소속 에픽 ID 및 이름}

## 난이도
{S | M | L | XL} — {난이도 판정 근거}

## 인수 조건
- [ ] AC 1: {구체적이고 테스트 가능한 기준}
- [ ] AC 2: ...

## 기술 노트
- 변경 대상 파일/모듈
- 주요 라이브러리 (구현에 핵심적인 외부 라이브러리 — 예: zod, react-hook-form, @tanstack/react-query)
- 의존성 (다른 Story와의 관계)
- 주의사항

## 의존성
- {의존하는 Story ID} (있는 경우)

bf-lead-plan

NPX Install

Tags

SKILL.md Content