source-command-feature-review

name	source-command-feature-review
description	feature 산출물을 CPO·CDO·CTO·QA Lead 4명의 전문가 에이전트가 병렬 검수. 피드백 수렴 후 문서 수정 제안.

source-command-feature-review

Use this skill when the user asks to run the migrated source command feature-review.

Command Template

/feature로 산출한 설계 문서(prd.md, design.md, tasks.md)를 4명의 C-Level / Lead 전문가 에이전트가 각자 관점에서 크로스체크한다. 피드백을 사용자에게 전달하고, 답변을 반영해 문서 수정 제안을 적용한다.

사용

• /feature-review <slug> — 4명 전문가 전부 병렬 검수.
• /feature-review <slug> <role> [role...] — 지정 전문가만 실행.
• /feature-review — slug 자동 선택 (최근 수정), 4명 전부.

역할 키워드가 아닌 인자는 slug로 취급. 키워드: cpo, cdo, cto, qa.

예시:

/feature-review                     → slug 자동, 4명 전부
/feature-review auth-flow           → slug=auth-flow, 4명 전부
/feature-review cto qa              → slug 자동, CTO + QA만
/feature-review auth-flow cto qa    → slug=auth-flow, CTO + QA만

검수 역할

키워드	역할	검수 대상	관점
cpo	CPO (Chief Product Officer)	prd.md	스코프 적절성, 시나리오 완전성, 비목표 명확성, 성공 기준 측정 가능성, 사용자 가치
cdo	CDO (Chief Design Officer)	prd.md + design.md	UX 플로우, 사용성 허들, UI 패턴 일관성(기존 codebase 기준), 접근성, 인터랙션 엣지 케이스
cto	CTO (Chief Technology Officer)	design.md	아키텍처 정합성, 기존 패턴/컨벤션 준수(AGENTS.md 기준), 오버엔지니어링, 기술 위험, 성능/보안
qa	QA Lead	tasks.md	검증 항목 충분성, 엣지 케이스 누락, 태스크 의존 관계, 회귀 리스크, 테스트 계획 실현 가능성

절차

1. 문서 로드

• docs/features/<slug>/ 에서 prd.md, design.md, tasks.md 3개 파일을 읽는다.
• 하나라도 없으면 즉시 종료: "문서가 불완전합니다. /feature를 먼저 실행해주세요."
• 컨텍스트용으로 AGENTS.md, docs/ARCHITECTURE.md도 함께 읽는다 (에이전트에게 전달).

2. 병렬 검수

활성화된 전문가 에이전트를 동시에 실행한다 (subagent_type: general-purpose). 각 에이전트에게 다음을 전달:

• 담당 문서 전문 + 다른 문서 참고용
• AGENTS.md + docs/ARCHITECTURE.md (코드베이스 컨텍스트)
• 역할별 검수 관점 (아래 프롬프트 가이드)
• 하위 검증 에이전트 분배 지침

2단계 구조

메인 스레드
├── CPO (general-purpose)
│   ├── Explore: 기존 유사 feature 문서 비교
│   └── Explore: sidepanel 사용자 흐름 실현 가능성
├── CDO (general-purpose)
│   ├── Explore: 기존 동일 역할 UI 컴포넌트 패턴
│   ├── Explore: 기존 UX 흐름 (상태 전환, 다이얼로그, 폼)
│   └── Explore: 사이드패널 레이아웃 구조 (400px 제약)
├── CTO (general-purpose)
│   ├── Explore: 아키텍처 패턴 (store, message, adapter)
│   ├── Explore: 관련 소스 코드 (문서 주장 검증)
│   └── Explore: 성능/보안 연관 파일
└── QA Lead (general-purpose)
    ├── Explore: 기존 테스트 파일 + 커버리지 패턴
    ├── Explore: 의존성 체인 + 상태 관리 경로
    └── Explore: 회귀 리스크 대상 기존 기능

각 전문가 에이전트는:

1. 담당 문서를 분석하고 코드베이스에서 검증해야 할 항목 식별
2. 검증 항목별로 Explore 하위 에이전트를 병렬 생성 (subagent_type: Explore)
3. 각 하위 에이전트에게 검증 목적 + 탐색할 파일 경로/패턴 전달
4. 하위 에이전트의 검증 결과를 수집
5. 문서 분석 + 코드 검증 결과를 종합하여 피드백 생성

하위 Explore 에이전트는 코드베이스를 읽어 문서의 주장을 검증한다 (예: "이 파일이 실제로 존재하는가", "이 패턴이 실제로 쓰이고 있는가", "이 인터페이스가 정확한가").

---

CPO 하위 에이전트

하위 에이전트	검증 목적	탐색 대상
feature-precedent	기존 유사 기능과 스코프 비교, 스코프 크리프 위험	docs/features/*/prd.md, 기존 기능 구현체
scenario-feasibility	사용자 시나리오가 현재 UX 흐름에서 실현 가능한지	src/sidepanel/**/* 사용자 진입점, 상태 전환 경로

---

CDO 하위 에이전트

하위 에이전트	검증 목적	탐색 대상
ui-pattern	기존 동일 역할 UI와 패턴 일치 여부	문서에서 언급된 컴포넌트의 기존 구현체, src/sidepanel/components/
ux-flow	기존 상태 전환·다이얼로그·폼 패턴과 일관성	기존 UX 흐름 (connect, issue submit, editor 등)
layout-constraint	~400px 사이드패널에서 제안된 레이아웃 실현 가능성	src/sidepanel/ 기존 레이아웃 구조, Tailwind 클래스 패턴

---

CTO 하위 에이전트

하위 에이전트	검증 목적	탐색 대상
arch-pattern	기존 아키텍처 패턴 (store, message, adapter) 준수 여부	src/store/*, src/background/messages.ts, 기존 어댑터
code-claim	문서가 참조하는 파일·함수·인터페이스의 실제 존재·정확성	문서에서 언급된 모든 소스 경로
risk-assessment	성능·보안·MV3 제약 관련 위험 식별	관련 background/content 코드, manifest 설정

---

QA Lead 하위 에이전트

하위 에이전트	검증 목적	탐색 대상
test-coverage	기존 테스트 커버리지 패턴, 새 테스트 계획 실현 가능성	**/__tests__/*, 기존 테스트 구조
dependency-chain	태스크 의존 대상의 실제 상태 + 인터페이스 안정성	태스크에서 참조하는 소스 파일, store 의존 체인
regression-target	회귀 리스크 대상 기존 기능 식별	변경 영향을 받을 기존 기능 코드

---

에이전트 출력 형식

각 전문가 에이전트는 아래 형식으로 구조화된 피드백을 반환:

## [역할] 검수 결과

### 질문 (답변 필요)
번호를 매겨 질문. 사용자에게 확인이 필요한 사항.

### 이슈 (수정 권장)
번호를 매겨 문제점과 수정 방향 제시. 각 항목에 심각도 표시:
- 🔴 심각: 기능이 잘못 정의됐거나 구현 불가능
- 🟡 권장: 개선하면 좋은 사항
- ⚪ 사소: 문서 품질/표현 수준

### 긍정 (잘된 점)
특별히 잘 설계된 부분 간단히 언급 (1-2개).

3. 피드백 통합 + 사용자 대화

두 단계로 진행한다:

3-1. 전체 피드백 목록 제시: 활성 에이전트 결과를 역할별로 정리해 사용자에게 한 번에 보여준다 (질문/이슈/긍정 전체 목록). 사용자가 전체 그림을 파악할 수 있게 한다.

3-2. 하나씩 질문 라운드: 전체 목록 제시 후, 심각도 순(🔴 → 🟡 → ⚪)으로 각 이슈/질문을 AskUserQuestion으로 하나씩 던진다. 각 항목에 적절한 선택지(2-4개)를 제시하고, 사용자 응답을 받아 수정 사항에 포함/제외를 결정한다. 중복 지적(여러 에이전트가 같은 문제를 지적)은 하나로 합쳐서 질문한다. 문서 정확성 오류(라인 번호, 검증 누락 등) 같은 명백한 수정 건은 묶어서 일괄 수정 허락을 구한다.

4. 문서 수정 적용

사용자와 합의된 수정 사항을 문서에 반영한다.

• 각 파일에 대해 변경 내역을 명시하고 수정
• 수정 전/후를 간결하게 요약

5. 커밋

수정된 문서를 커밋한다. 메시지: docs(feature): <slug> apply review feedback.

6. 종료

수정 요약을 보고하고 끝. 후속 액션 제안 금지.

에이전트 프롬프트 가이드

CPO 프롬프트 핵심

• 배경이 문제를 명확히 설명하는가? 왜 지금 이 기능이 필요한가?
• 목표가 검증 가능한 문장인가? 모호한 표현("적절히", "더 나은") 없는가?
• 비목표가 충분한가? 스코프 크리프 위험이 있는 항목이 빠져 있진 않은가?
• 사용자 시나리오가 실제 사용 패턴을 반영하는가? 주요 엣지 케이스가 누락됐는가?
• 성공 기준이 기능 완성을 판별하기에 충분한가?

CDO 프롬프트 핵심

• 사용자 시나리오의 UX 플로우가 자연스러운가? 불필요한 클릭/전환이 있는가?
• 기존 UI 패턴(탭 구조, 컴포넌트 사이즈, 인터랙션 방식)과 일관성이 있는가?
• 좁은 사이드 패널(~400px)에서 레이아웃이 실현 가능한가?
• 빈 상태(empty state), 로딩 상태, 에러 상태가 고려됐는가?
• 접근성(키보드 내비게이션, 스크린 리더)에 문제가 없는가?
• 기존 codebase의 동일 레이어 UI를 직접 읽어 패턴 일치 여부를 검증할 것.

CTO 프롬프트 핵심

• AGENTS.md의 아키텍처 원칙·코드 컨벤션과 충돌하지 않는가?
• 기존 패턴(서브탭 구조, 스토어 접근, 메시지 패턴)을 정확히 따르는가?
• 오버엔지니어링이 없는가? 더 단순한 접근이 가능한가?
• 데이터 흐름이 기존 파이프라인과 정합하는가?
• 성능·메모리·보안 위험이 있는가?
• 대안 검토가 타당한가? 기각 사유가 합리적인가?
• 위험 요소가 충분히 식별됐는가?

QA Lead 프롬프트 핵심

• 각 태스크의 검증 항목이 실제로 검증 가능한가?
• 엣지 케이스가 누락됐는가? (빈 데이터, 대량 데이터, 동시성, 상태 전환 경계)
• 태스크 간 의존 관계가 정확한가? 순서가 합리적인가?
• 회귀 리스크가 충분히 식별됐는가? 기존 기능에 미치는 영향은?
• 테스트 계획이 실현 가능한가? 자동 테스트와 수동 테스트 구분이 적절한가?
• e2e 시나리오가 스크립트로 판정 가능한 문장인가? (자동화 가능성 — "~하면 ~가 된다" 형식, 셀렉터(data-testid)가 실재하거나 부착 계획이 있는가)
• 검증 누락 시나리오: 상태 보존 검증, i18n 양방향 검증, 다이얼로그 기존 동작 유지 검증 등.

금지 사항

• 코드 수정 금지 — src/, manifest, package.json 등 프로덕션 코드 변경하지 않는다.
• 빌드/테스트 실행 금지 — 읽기 전용.
• 에이전트가 직접 문서 수정 금지 — 에이전트는 피드백만 반환. 수정은 사용자 합의 후에만.
• 후속 액션 자동 실행 금지 — 문서 수정 후 종료.