Menü
feature 산출물을 CPO·CDO·CTO·QA Lead 4명의 전문가 에이전트가 병렬 검수. 피드백 수렴 후 문서 수정 제안.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
코드베이스 전체를 컨벤션·패턴 기준으로 감사. 리포트 전용 — fix·빌드·커밋 안 함.
pnpm build 실행 후 결과 요약
변경된 코드를 시급도별로 보고. 리포트 전용 — fix·빌드·커밋 안 함.
웹스토어 배포 (main 가드 → tag push → 스토어 빌드 → zip → GitHub Release draft → 심사 요청 안내)
저장소 문서(Codex/DIRECTORY/ARCHITECTURE/DESIGN/README/PERMISSION/privacy/AUTHORING)를 문서별 전담 에이전트가 병렬로 코드베이스와 양방향 대조(사실오류 + 누락 커버리지)해 stale 탐지 → 통합 리포트 → 항목별 확인 → 수정. guide/ko·en 본문은 제외(/guide 전담). 빌드 안 함.
e2e 전체 스위트 실행 + 리포트 전용. fix·spec 수정 금지. green & 클린 트리면 e2e/.last-green에 커밋 해시 기록.
| name | source-command-feature-review |
| description | feature 산출물을 CPO·CDO·CTO·QA Lead 4명의 전문가 에이전트가 병렬 검수. 피드백 수렴 후 문서 수정 제안. |
Use this skill when the user asks to run the migrated source command feature-review.
/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 | 검증 항목 충분성, 엣지 케이스 누락, 태스크 의존 관계, 회귀 리스크, 테스트 계획 실현 가능성 |
docs/features/<slug>/ 에서 prd.md, design.md, tasks.md 3개 파일을 읽는다./feature를 먼저 실행해주세요."AGENTS.md, docs/ARCHITECTURE.md도 함께 읽는다 (에이전트에게 전달).활성화된 전문가 에이전트를 동시에 실행한다 (subagent_type: general-purpose). 각 에이전트에게 다음을 전달:
메인 스레드
├── 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: 회귀 리스크 대상 기존 기능
각 전문가 에이전트는:
subagent_type: Explore)하위 Explore 에이전트는 코드베이스를 읽어 문서의 주장을 검증한다 (예: "이 파일이 실제로 존재하는가", "이 패턴이 실제로 쓰이고 있는가", "이 인터페이스가 정확한가").
| 하위 에이전트 | 검증 목적 | 탐색 대상 |
|---|---|---|
| feature-precedent | 기존 유사 기능과 스코프 비교, 스코프 크리프 위험 | docs/features/*/prd.md, 기존 기능 구현체 |
| scenario-feasibility | 사용자 시나리오가 현재 UX 흐름에서 실현 가능한지 | src/sidepanel/**/* 사용자 진입점, 상태 전환 경로 |
| 하위 에이전트 | 검증 목적 | 탐색 대상 |
|---|---|---|
| ui-pattern | 기존 동일 역할 UI와 패턴 일치 여부 | 문서에서 언급된 컴포넌트의 기존 구현체, src/sidepanel/components/ |
| ux-flow | 기존 상태 전환·다이얼로그·폼 패턴과 일관성 | 기존 UX 흐름 (connect, issue submit, editor 등) |
| layout-constraint | ~400px 사이드패널에서 제안된 레이아웃 실현 가능성 | src/sidepanel/ 기존 레이아웃 구조, Tailwind 클래스 패턴 |
| 하위 에이전트 | 검증 목적 | 탐색 대상 |
|---|---|---|
| arch-pattern | 기존 아키텍처 패턴 (store, message, adapter) 준수 여부 | src/store/*, src/background/messages.ts, 기존 어댑터 |
| code-claim | 문서가 참조하는 파일·함수·인터페이스의 실제 존재·정확성 | 문서에서 언급된 모든 소스 경로 |
| risk-assessment | 성능·보안·MV3 제약 관련 위험 식별 | 관련 background/content 코드, manifest 설정 |
| 하위 에이전트 | 검증 목적 | 탐색 대상 |
|---|---|---|
| test-coverage | 기존 테스트 커버리지 패턴, 새 테스트 계획 실현 가능성 | **/__tests__/*, 기존 테스트 구조 |
| dependency-chain | 태스크 의존 대상의 실제 상태 + 인터페이스 안정성 | 태스크에서 참조하는 소스 파일, store 의존 체인 |
| regression-target | 회귀 리스크 대상 기존 기능 식별 | 변경 영향을 받을 기존 기능 코드 |
각 전문가 에이전트는 아래 형식으로 구조화된 피드백을 반환:
## [역할] 검수 결과
### 질문 (답변 필요)
번호를 매겨 질문. 사용자에게 확인이 필요한 사항.
### 이슈 (수정 권장)
번호를 매겨 문제점과 수정 방향 제시. 각 항목에 심각도 표시:
- 🔴 심각: 기능이 잘못 정의됐거나 구현 불가능
- 🟡 권장: 개선하면 좋은 사항
- ⚪ 사소: 문서 품질/표현 수준
### 긍정 (잘된 점)
특별히 잘 설계된 부분 간단히 언급 (1-2개).
두 단계로 진행한다:
3-1. 전체 피드백 목록 제시: 활성 에이전트 결과를 역할별로 정리해 사용자에게 한 번에 보여준다 (질문/이슈/긍정 전체 목록). 사용자가 전체 그림을 파악할 수 있게 한다.
3-2. 하나씩 질문 라운드: 전체 목록 제시 후, 심각도 순(🔴 → 🟡 → ⚪)으로 각 이슈/질문을 AskUserQuestion으로 하나씩 던진다. 각 항목에 적절한 선택지(2-4개)를 제시하고, 사용자 응답을 받아 수정 사항에 포함/제외를 결정한다. 중복 지적(여러 에이전트가 같은 문제를 지적)은 하나로 합쳐서 질문한다. 문서 정확성 오류(라인 번호, 검증 누락 등) 같은 명백한 수정 건은 묶어서 일괄 수정 허락을 구한다.
사용자와 합의된 수정 사항을 문서에 반영한다.
수정된 문서를 커밋한다. 메시지: docs(feature): <slug> apply review feedback.
수정 요약을 보고하고 끝. 후속 액션 제안 금지.
data-testid)가 실재하거나 부착 계획이 있는가)src/, manifest, package.json 등 프로덕션 코드 변경하지 않는다.