/implement

description: |
  Implement features based on PRD specifications.

  Trigger keywords:
  - Commands: "/implement", "구현해줘", "만들어줘", "바로 구현"

  - Natural language (바이브 코더 친화):
    - "코드 작성해줘", "개발해줘", "빌드해줘"
    - "이제 만들어", "시작해줘", "진행해줘"
    - "코딩해줘", "개발 시작", "구현 시작"
    - "바로 만들어줘", "빨리 만들어줘"
    - "작업해줘", "개발 진행해줘"

  Best used AFTER /prd and prd-reviewer.

Implement

PRD에 정의된 기능을 구현한다.

파이프라인: `/prd` → `prd-reviewer` → (FE 있으면 `/screen-spec`) → **`/implement`** → `/auto-commit`

**핵심 원칙 — 설계-구현 분리**: DESIGN → **사용자 확인(Y/n)** → BUILD. 확인 없이 구현을 시작하지 않는다. 이것은 오버헤드가 아니라 안전장치다.

진행 원장 (ledger)

`docs/todo_plan/PLAN_{feature}.md`의 `- [ ]` 체크박스가 진행 상태의 **정본**이다. task 완료마다 `[ ]` → `[x]`로 갱신하고, Phase 완료 시 Progress 표와 Execution Log(시각은 `YYYY-MM-DD HH:MM`)를 기록한다.

> 서브에이전트에는 작업 추적 도구가 **없다** (호출 시 `not enabled in this context`). 진행 추적은 반드시 파일 원장으로 한다 — `.github/probes/HARNESS_FACTS.md` P-1.

PLAN 파일이 없으면 PRD 기반으로 계획을 세우고, 구현 완료 후 PLAN 생성을 제안한다.

작업 규모 triage — 진입 시 최초 1회

작은 수정에 그린필드용 오케스트레이션(디깅·팀빌드·별도 verifier)을 태워 느려지고 비싸지는 것을 막는다.

| 분류 | 정의 | 신호 | |------|------|------| | **quick-fix** | 버그픽스·소규모 수정·문구/설정 변경. 단일 관심사, 새 아키텍처 결정 불요. | "버그", "고쳐", "오타", "~만 바꿔", "롤백"; 예상 변경 ≤2 파일; 기존 코드 국소 수정 | | **feature** | 기존 코드베이스에 기능 추가. 기존 스택/패턴 위에서 구현. | 단일~소수 팀; 새 모듈 소수; 기존 아키텍처 재사용 | | **greenfield** | 새 프로젝트 또는 대형 기능. 아키텍처를 새로 정해야 함. | 새 레포/앱; 다수 팀·도메인; 아키텍처 미정; PRD 필수 |

요청 문구 + PRD 존재 여부 + 예상 변경 범위 + 새 아키텍처 필요 여부를 함께 본다. 애매하면 **한 단계 무겁게** 잡는다. 판정은 한 줄로 알린다(예: `triage: quick-fix — 단일 파일 버그픽스로 판단, 경량 경로 진행`).

| 단계 | quick-fix | feature | greenfield | |------|-----------|---------|-----------| | PRD 품질 게이트 (Step 0) | PRD 있을 때만 | 예 | 예 | | 아키텍처 결정 (Step 2) | 스킵 | 조건부(기존 스택 있으면 스킵) | 항상 | | DESIGN Step 3~5 | 인라인 경량(영향 파일만) | 예 | 예 | | 디깅 상세검토 (`prd-reviewer`) | 스킵 | 사용자 선택 시만 | 사용자 선택 시만 | | 사용자 확인 (Step 6) | 예(요약 1줄 + Y/n) | 예 | 예 | | BUILD | 단일 에이전트 인라인 | 단일~소수 팀 | team-build 병렬 | | Fresh-context verifier (Step 4.5) | 인라인 self-check | 예 | 예 |

quick-fix가 스킵하는 것은 **오케스트레이션 오버헤드지 안전장치가 아니다** — Step 6 확인과 커밋 전 확인은 그대로 유지한다.

**수동 오버라이드**: `--full`(풀 파이프라인 강제) · `--quick`(경량 경로 강제, greenfield에 쓰면 경고 후 진행). `--parallel`/`--sequential`은 feature/greenfield의 BUILD 모드에만 적용된다.

병렬 모드

• **전제**: `feature`/`greenfield`만. `quick-fix`는 항상 단일 에이전트.
• **기본값**: sequential.
• **자동 활성화**: 활성 팀 2개 이상 **또는** BUILD Phase 2개 이상 (Step 5.5 결과). **파일 개수 단독으로는 켜지 않는다** — 병렬 이득은 파일 수가 아니라 독립 팀·Phase 수에서 나온다.
• **병렬 DESIGN**: `Step 0+0.5+1`(읽기 전용) / `Step 2` / `Step 3+4` 를 3개 레인으로 나눠 실행하고 Step 5에서 병합한다. 첫 레인이 **Quality Gate BLOCKED**를 내면 나머지 레인을 즉시 중단한다.
• 활성화 시 현재 모드와 활성 에이전트 수를 한 줄로 표시하고 `--sequential`로 끌 수 있음을 안내한다.

Usage

/implement 사용자 인증
/implement FR-006              # PRD 기능 ID로 직접 지정
/implement --parallel 사용자 인증
/implement --quick 오타 수정
/implement --full 로그인 버그
/implement --no-tracker 사용자 인증

Parameters

• `feature-name or FR-ID`: 기능명 또는 기능 ID (required)
• `--quick`: triage를 무시하고 경량 경로(quick-fix) 강제
• `--full`: triage를 무시하고 풀 파이프라인 강제
• `--parallel`: 병렬 모드 강제 활성화 (feature/greenfield BUILD)
• `--sequential`: 순차 모드 강제
• `--full-stack`: (deprecated) 모든 팀 강제 활성화로 매핑
• `--no-tracker`: 이슈 트래커(Linear) 연동을 무시하고 원큐 플로우로 진행
• `--resume`: 저장된 진행 상태에서 마지막 실패 지점부터 재개 (인자 없이 `/implement {feature}` 와 동일)
• `--restart`: 저장된 진행 상태를 버리고 처음부터 다시 실행

---

DESIGN Phase

> `quick-fix`는 이 Phase를 **인라인 최소 수행**한다 — 영향 파일 Read → 계획 1~3줄 → Step 6 확인. Step 2·디깅·병렬 DESIGN은 건너뛴다.

Step 0: PRD 품질 검증 (Quality Gate)

`/prd` 실행 시 저장된 prd-reviewer 결과 또는 PRD 메타데이터에서 검증 상태를 읽는다.

| Critical 이슈 | 상태 | 액션 | |--------------|------|------| | **0개** | PASS | Step 1로 진행 | | **1개 이상** | BLOCKED | 구현 중단 |

BLOCKED이면 Critical 이슈(번호·위치·영향)를 나열하고 ① PRD 수정 후 재실행 ② 강제 진행("Critical 무시하고 진행" 입력, 보안 취약점·구현 실패 위험 경고) 중 선택하게 한다.

Step 0.5: 이슈 트래커 감지 (읽기 전용)

`mcp__linear__*` 도구가 있으면 `issue_tracker = linear`, 없거나 `--no-tracker`면 `none`(원큐 플로우).

연동 감지 시 읽기 전용으로 수집한다:

• `mcp__linear__list_teams` → 팀 1개면 자동 선택, 여러 개면 Step 6에서 선택 요청.
• `mcp__linear__list_projects` → Epic을 어디에 둘지 판단 (Step 7에서 사용).
• `mcp__linear__list_issue_statuses` → **상태 이름은 팀마다 다르므로 글자가 아닌 `type`으로 매칭한다**:
• `started_state` = `type: "started"` (예: "In Progress", "In Dev")
• `done_state` = `type: "completed"` (예: "Done", "Shipped")
• 같은 type이 여러 개면 워크플로우 순서상 첫 번째. 없으면 가장 가까운 상태로 폴백하고 경고.
• BUILD의 상태 전환은 이 두 변수만 쓴다 — 이름을 하드코딩하지 않는다.

> **쓰기 금지**: 실제 에픽/이슈 생성은 Step 6 승인 이후(Step 7)에만 한다. 이 단계는 읽기 전용이라 병렬 DESIGN의 첫 레인에 포함한다.

결과는 한 줄 요약(예: `Linear 연결됨 · 팀: Engineering`). 미연동이면 "이슈 트래커 미연동 → 원큐 플로우로 진행".

Step 1: PRD 검색

기능명 또는 `FR-XXX`로 `prd/`, `docs/prd/`, `requirements/`, `specs/` 등에서 PRD를 찾는다. 못 찾으면 ① `/prd [기능명]` 먼저 작성 ② 경로 직접 지정 ③ PRD 없이 진행(권장하지 않음) 중 선택하게 한다.

Step 2: 아키텍처 결정

> `greenfield`만 항상 수행. `feature`는 기존 스택/아키텍처가 감지되면 그것을 존속하고 스킵. `quick-fix`는 스킵.

`architecture-decision` 에이전트를 호출한다. 입력은 PRD 경로·프로젝트 경로·감지된 기존 스택, 출력은 아키텍처 유형 + 근거 + 추천 스택/패턴 + 주의사항이다. 결과를 요약해 표시한다.

Step 3~4: 프로젝트 상태 분석

기존 구현 여부, 관련 파일 위치, 사용 중인 패턴·컨벤션을 파악해 **이미 된 부분은 다시 만들지 않는다**. 새 코드는 발견한 컨벤션을 따른다.

**화면정의서가 있으면 읽는다.** `docs/prd/screens/{feature}/` 가 존재하면 `03-SCREEN-SPEC.md`(화면별 상태·컴포넌트)와 `05-DEV-HANDOFF.md`(FR ↔ 화면 ↔ 컴포넌트 매핑)를 Read해 Step 5 계획의 입력으로 쓴다. 없으면 PRD만으로 진행한다. `/screen-spec` 이 산출물을 내놓아도 여기서 읽지 않으면 그 단계는 값을 하지 못한다.

Step 5: 구현 계획 수립

생성/수정할 파일을 표로 정리하고 **각 파일에 담당 `FR`을 매핑한다**. 이 매핑이 Step 5.7 이슈 본문의 "구현 범위(파일)"과 BUILD 루프의 작업 범위를 결정하므로, 이슈 트래커 연동 시에는 필수다. 여러 FR이 한 파일을 건드리면 의존성 순서상 **나중 FR 이슈**가 그 파일을 마지막에 커밋한다(앞 FR은 자기 범위만 부분 작성).

Step 5.5: 팀 할당

| 팀 | 활성화 조건 | Agent | |-----|-----------|-------| | Backend | api/, services/, models/, prisma/ 파일 존재 | `backend-architect` | | Frontend | components/, pages/, app/, styles/ 파일 존재 | `frontend-developer` | | AI Server | ai/, llm/, stt/, ml/ 파일 또는 PRD에 AI 키워드 | `ai-agent` | | Ops | Dockerfile, .github/, k8s/ 파일 존재 | (전용 에이전트 없음) |

팀별 활성 여부·task 수·담당 에이전트를 Step 6 확인에 포함한다.

Step 5.6: 디자인 결정 (Frontend 팀 활성 시)

위에서부터 평가해 해당하면 그 자리에서 결정하고 나머지는 스킵한다.

| 조건 | 액션 | |------|------| | PRD에 스타일 명시 (`"스타일: Gl