@su-record/vibe 2.9.1 → 2.9.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,83 @@
1
+ # Fullstack Team
2
+
3
+ Frontend + Backend 동시 변경이 필요한 풀스택 기능 구현 팀.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | architect (리더) | API 인터페이스 설계, frontend/backend 분업 조율 | Opus |
10
+ | implementer-backend | Backend API, 데이터베이스, 서비스 로직 구현 | Sonnet |
11
+ | implementer-frontend | Frontend UI, 상태 관리, API 연동 구현 | Sonnet |
12
+ | tester | E2E 테스트, API 테스트, 통합 테스트 | Haiku |
13
+
14
+ ## 활성화 조건
15
+
16
+ - SPEC에 frontend + backend 파일이 모두 포함된 경우
17
+ - 또는 수동으로 `fullstack` 키워드 지정 시
18
+
19
+ ## 워크플로우
20
+
21
+ ```
22
+ architect: API 계약 설계 (request/response 스키마, 데이터 모델)
23
+ |
24
+ ├──→ implementer-backend: API 엔드포인트 구현 (병렬)
25
+ │ └── 완료 시 → implementer-frontend에 통보
26
+ ├──→ implementer-frontend: UI 구현 (mock 데이터 → 실 API 전환) (병렬)
27
+ │ └── 통합 완료 시 → tester에 통보
28
+ └──→ tester: API 테스트 (backend 후) → E2E 테스트 (frontend 후)
29
+ |
30
+ architect: 통합 검증 → 완료
31
+ ```
32
+
33
+ ## spawn 패턴
34
+
35
+ ```text
36
+ TeamCreate(team_name="fullstack-{feature}", description="Fullstack team for {feature}")
37
+
38
+ Task(team_name="fullstack-{feature}", name="architect", subagent_type="architect",
39
+ prompt="Fullstack team leader. Design API contract for {feature}.
40
+ SPEC: {spec_content}
41
+ Role: Define API endpoints (request/response schemas). Design data models.
42
+ Share API contract with both implementers. Coordinate integration timing.")
43
+
44
+ Task(team_name="fullstack-{feature}", name="implementer-backend", subagent_type="implementer",
45
+ mode="bypassPermissions",
46
+ prompt="Fullstack team backend developer. Implement API for {feature}.
47
+ SPEC: {spec_content}
48
+ Role: Implement API endpoints per architect's contract. Create data models and services.
49
+ Notify implementer-frontend when endpoints are ready for integration.
50
+ Share API response samples with tester.")
51
+
52
+ Task(team_name="fullstack-{feature}", name="implementer-frontend", subagent_type="implementer",
53
+ mode="bypassPermissions",
54
+ prompt="Fullstack team frontend developer. Implement UI for {feature}.
55
+ SPEC: {spec_content}
56
+ Role: Build UI components and pages per SPEC. Use architect's API contract for types.
57
+ Start with mock data, switch to real API when backend notifies readiness.
58
+ Notify tester when UI is ready for E2E testing.")
59
+
60
+ Task(team_name="fullstack-{feature}", name="tester", subagent_type="tester",
61
+ mode="bypassPermissions",
62
+ prompt="Fullstack team tester. Write comprehensive tests for {feature}.
63
+ SPEC: {spec_content}
64
+ Role: Write API tests (after backend ready). Write E2E tests (after frontend ready).
65
+ Test API contract conformance. Report integration issues to architect.")
66
+ ```
67
+
68
+ ## 팀원 간 통신
69
+
70
+ ```text
71
+ architect → implementer-backend: "API 계약 확정: POST /api/orders (request: OrderCreateDto, response: OrderResponse)"
72
+ architect → implementer-frontend: "API 계약 공유. mock 데이터로 먼저 시작하세요"
73
+ implementer-backend → implementer-frontend: "POST /api/orders 구현 완료. 실 API로 전환 가능합니다"
74
+ implementer-frontend → tester: "주문 페이지 구현 + API 연동 완료. E2E 테스트 요청합니다"
75
+ tester → architect: "API 응답 스키마 불일치: createdAt 필드 누락. 계약과 다릅니다"
76
+ architect → broadcast: "풀스택 구현 완료. API 6개 + UI 4페이지 + E2E 12 시나리오 통과"
77
+ ```
78
+
79
+ ## ⛔ 하지 않는 것
80
+
81
+ - architect API 계약 없이 구현 시작
82
+ - frontend가 backend 완료 전에 실 API 연동 (mock 먼저)
83
+ - 테스트 없이 통합 완료 선언
@@ -0,0 +1,69 @@
1
+ # Lite Team
2
+
3
+ Dev Team의 축소 버전. 일반 모드에서도 팀 협업을 제공하는 3인 구현 팀.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | architect (리더) | 설계 결정, 시나리오 분석, 구현 방향 조율 | Sonnet |
10
+ | implementer | 핵심 비즈니스 로직 구현 | Sonnet |
11
+ | tester | 구현 완료 즉시 테스트 작성, 실패 시 피드백 | Haiku |
12
+
13
+ ## 활성화 조건
14
+
15
+ - 일반 모드 + 3개 이상 시나리오
16
+ - 복잡도 점수 8-19 (Medium)
17
+ - 단순 구현(1-2 파일, 시나리오 2개 이하)에서는 기존 병렬 모드 유지
18
+
19
+ ## 워크플로우
20
+
21
+ ```
22
+ architect: SPEC Phase 분석 → 구현 계획 → TaskList 등록
23
+ |
24
+ ├──→ implementer: claim → 코드 작성
25
+ │ └──→ tester: 완료 즉시 테스트
26
+ │ └── 실패 → implementer 피드백
27
+ |
28
+ architect: 시나리오 통과 확인 → 팀 종료
29
+ ```
30
+
31
+ ## spawn 패턴
32
+
33
+ ```text
34
+ TeamCreate(team_name="lite-{feature}", description="Lite implementation team for {feature} Phase {N}")
35
+
36
+ Task(team_name="lite-{feature}", name="architect", subagent_type="architect",
37
+ prompt="Lite 팀 리더. Phase {N}의 SPEC을 분석하고 구현 계획을 수립하세요.
38
+ SPEC: {spec_content}
39
+ Feature Scenarios: {scenarios}
40
+ 역할: 설계 결정, 구현 방향 조율. TaskList에 작업을 등록하세요.
41
+ implementer에게 설계를 SendMessage로 전달하세요.")
42
+
43
+ Task(team_name="lite-{feature}", name="implementer", subagent_type="implementer",
44
+ mode="bypassPermissions",
45
+ prompt="Lite 팀 코드 담당. SPEC: {spec_content}
46
+ 역할: architect의 설계를 따라 프로덕션 코드 작성.
47
+ 완료 시 tester에게 SendMessage로 테스트 요청하세요.")
48
+
49
+ Task(team_name="lite-{feature}", name="tester", subagent_type="tester",
50
+ mode="bypassPermissions",
51
+ prompt="Lite 팀 테스트 담당. SPEC: {spec_content}
52
+ 역할: implementer가 완료한 컴포넌트부터 즉시 테스트 작성.
53
+ 테스트 실패 시 implementer에게 SendMessage로 피드백하세요.")
54
+ ```
55
+
56
+ ## 팀원 간 통신
57
+
58
+ ```text
59
+ architect → implementer: "API 엔드포인트 3개를 이 순서로 구현해주세요. 설계는 TaskList에 등록했습니다"
60
+ implementer → tester: "UserController 구현 완료. CRUD 시나리오 테스트 요청합니다"
61
+ tester → implementer: "PUT /users/:id 에서 빈 body 시 500 에러. 입력 검증 추가 필요"
62
+ architect → broadcast: "모든 시나리오 통과. 팀 종료합니다"
63
+ ```
64
+
65
+ ## ⛔ 하지 않는 것
66
+
67
+ - 보안 심층 리뷰 (Dev Team Full 사용)
68
+ - architect 승인 없이 설계 변경
69
+ - 테스트 실패 상태에서 다음 작업 진행
@@ -0,0 +1,78 @@
1
+ # Migration Team
2
+
3
+ 프레임워크/라이브러리 마이그레이션 전문 팀.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | architect (리더) | 마이그레이션 전략 설계, 호환성 분석, 단계별 계획 | Opus |
10
+ | implementer | 코드 변환 실행, API 변경 적용 | Sonnet |
11
+ | tester | 마이그레이션 후 회귀 테스트, 호환성 검증 | Haiku |
12
+ | build-error-resolver | 빌드 에러 즉시 해결, 타입 에러 수정 | Sonnet |
13
+
14
+ ## 활성화 조건
15
+
16
+ - package.json 주요 의존성 버전 변경 감지 시
17
+ - 또는 수동으로 `migration` 키워드 지정 시
18
+
19
+ ## 워크플로우
20
+
21
+ ```
22
+ architect: breaking changes 분석 → 단계별 마이그레이션 계획
23
+ |
24
+ ├──→ implementer: 파일 그룹 단위로 코드 변환
25
+ │ ├──→ build-error-resolver: 빌드 에러 즉시 수정
26
+ │ └──→ tester: 각 단계 후 회귀 테스트
27
+ │ ├─ PASS → 다음 파일 그룹
28
+ │ └─ FAIL → implementer에 피드백
29
+ |
30
+ architect: 전체 검증 → 마이그레이션 완료 보고
31
+ ```
32
+
33
+ ## spawn 패턴
34
+
35
+ ```text
36
+ TeamCreate(team_name="migration-{feature}", description="Migration team for {feature}")
37
+
38
+ Task(team_name="migration-{feature}", name="architect", subagent_type="architect",
39
+ prompt="Migration team leader. Plan migration strategy for {feature}.
40
+ From: {current_version}
41
+ To: {target_version}
42
+ Role: Analyze breaking changes. Create step-by-step migration plan.
43
+ Assign file groups to implementer. Monitor build-error-resolver for blockers.")
44
+
45
+ Task(team_name="migration-{feature}", name="implementer", subagent_type="implementer",
46
+ mode="bypassPermissions",
47
+ prompt="Migration team implementer. Execute code migration for {feature}.
48
+ Role: Apply migration changes per architect plan. Work file-by-file.
49
+ Notify tester after each file group. Report blockers to architect.")
50
+
51
+ Task(team_name="migration-{feature}", name="tester", subagent_type="tester",
52
+ mode="bypassPermissions",
53
+ prompt="Migration team tester. Verify migration correctness for {feature}.
54
+ Role: Run existing tests after each migration step. Add new tests for changed APIs.
55
+ Report regressions to implementer and architect.")
56
+
57
+ Task(team_name="migration-{feature}", name="build-error-resolver", subagent_type="build-error-resolver",
58
+ mode="bypassPermissions",
59
+ prompt="Migration team build fixer. Resolve build errors during {feature} migration.
60
+ Role: Monitor build output. Apply minimal-diff type fixes for migration errors.
61
+ Notify implementer of patterns requiring broader changes.")
62
+ ```
63
+
64
+ ## 팀원 간 통신
65
+
66
+ ```text
67
+ architect → implementer: "Step 1: React 18→19 — useEffect cleanup 패턴 변경. src/hooks/ 먼저 처리하세요"
68
+ implementer → tester: "src/hooks/ 마이그레이션 완료. 회귀 테스트 요청합니다"
69
+ build-error-resolver → implementer: "Type error pattern: React.FC deprecated. 12개 파일에서 동일 패턴"
70
+ tester → architect: "3건 실패: useLayoutEffect 경고. SSR 호환성 문제"
71
+ architect → broadcast: "마이그레이션 완료. 변경 파일 47개, 회귀 0건"
72
+ ```
73
+
74
+ ## ⛔ 하지 않는 것
75
+
76
+ - 마이그레이션과 무관한 리팩터링
77
+ - architect 계획 없이 임의 변경
78
+ - build-error-resolver가 5% 이상 파일 변경 (최소 diff만)
@@ -0,0 +1,94 @@
1
+ # Refactor Team
2
+
3
+ 안전한 멀티파일 리팩터링을 위한 팀. Characterization test로 현재 동작을 잠그고 변경 후 회귀를 검증한다.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | architect (리더) | 리팩터링 범위 설정, 단계별 계획, 리스크 평가 | Opus |
10
+ | refactor-cleaner | 데드코드 탐지, 미사용 export/파일/의존성 분석 | Sonnet |
11
+ | implementer | architect 계획에 따라 리팩터링 실행 (파일 단위) | Sonnet |
12
+ | tester | Characterization test 작성 + 회귀 테스트 실행 | Haiku |
13
+
14
+ ## 활성화 조건
15
+
16
+ - `/vibe.run refactor` 수동 트리거
17
+ - complexity-reviewer가 동일 모듈에서 P2 이슈 5개 이상 발견 시 제안
18
+
19
+ ## 워크플로우
20
+
21
+ ```
22
+ architect: 대상 모듈 분석, 리팩터링 범위 + 리스크 평가
23
+ |
24
+ refactor-cleaner: knip/depcheck/ts-prune → 데드코드 스캔 결과
25
+ |
26
+ tester: characterization test 작성 (현재 동작 잠금, 변경 전)
27
+ |
28
+ architect: 스캔 결과 + 테스트 커버리지 검토 → 단계별 리팩터링 계획
29
+ |
30
+ implementer: 파일 단위 리팩터링 실행
31
+ │ 각 파일마다:
32
+ │ ├──→ tester: characterization test 실행
33
+ │ │ ├─ PASS → 다음 파일
34
+ │ │ └─ FAIL → implementer 롤백 → architect 재계획
35
+ |
36
+ architect: 최종 검증, before/after 메트릭 비교, 요약 작성
37
+ ```
38
+
39
+ ## spawn 패턴
40
+
41
+ ```text
42
+ TeamCreate(team_name="refactor-{module}", description="Safe refactoring team for {module}")
43
+
44
+ Task(team_name="refactor-{module}", name="architect", subagent_type="architect",
45
+ prompt="리팩터링 팀 리더. 대상 모듈을 분석하고 안전한 리팩터링 계획을 수립하세요.
46
+ 대상: {target_path}
47
+ 목표: {refactor_goal}
48
+ 역할: 범위 설정, 리스크 평가, 단계별 계획. refactor-cleaner에게 스캔을 요청하세요.
49
+ tester가 characterization test를 작성할 때까지 구현을 시작하지 마세요.
50
+ 각 단계 후 tester 결과를 확인하고 다음 단계를 승인하세요.")
51
+
52
+ Task(team_name="refactor-{module}", name="refactor-cleaner", subagent_type="refactor-cleaner",
53
+ prompt="리팩터링 팀 분석 담당. 대상: {target_path}
54
+ 역할: knip/depcheck/ts-prune으로 데드코드, 미사용 export, 불필요 의존성 탐지.
55
+ 스캔 결과를 architect에게 SendMessage로 전달하세요.
56
+ DELETION_LOG.md에 삭제 대상을 기록하세요.")
57
+
58
+ Task(team_name="refactor-{module}", name="implementer", subagent_type="implementer",
59
+ mode="bypassPermissions",
60
+ prompt="리팩터링 팀 구현 담당. 대상: {target_path}
61
+ 역할: architect의 계획에 따라 파일 단위로 리팩터링 실행.
62
+ 각 파일 수정 후 tester에게 SendMessage로 테스트 요청하세요.
63
+ 테스트 실패 시 즉시 롤백하고 architect에게 알리세요.")
64
+
65
+ Task(team_name="refactor-{module}", name="tester", subagent_type="tester",
66
+ mode="bypassPermissions",
67
+ prompt="리팩터링 팀 테스트 담당. 대상: {target_path}
68
+ 역할: 1) 리팩터링 전 characterization test 작성 (현재 동작 잠금).
69
+ 2) 각 파일 수정 후 회귀 테스트 실행.
70
+ 실패 시 implementer에게 SendMessage로 즉시 알리세요.
71
+ architect에게 테스트 커버리지 현황을 보고하세요.")
72
+ ```
73
+
74
+ ## 팀원 간 통신
75
+
76
+ ```text
77
+ architect → refactor-cleaner: "src/services/ 모듈 스캔 요청. 미사용 export와 데드코드를 찾아주세요"
78
+ refactor-cleaner → architect: "미사용 export 12개, 데드파일 3개, 미사용 의존성 2개 발견"
79
+ architect → tester: "src/services/auth.ts의 현재 동작을 characterization test로 잠그세요"
80
+ tester → architect: "auth.ts 커버리지 94%. 리팩터링 진행 가능합니다"
81
+ architect → implementer: "Step 1: auth.ts에서 미사용 export 4개 제거. 계획 참조하세요"
82
+ implementer → tester: "auth.ts 수정 완료. 회귀 테스트 요청합니다"
83
+ tester → implementer: "1건 실패: validateToken() 시그니처 변경으로 호출부 깨짐"
84
+ implementer → architect: "호출부 수정 필요. 영향 범위: 3파일"
85
+ architect → broadcast: "리팩터링 완료. 복잡도 42→28, 데드코드 15개 제거, 테스트 전체 통과"
86
+ ```
87
+
88
+ ## ⛔ 하지 않는 것
89
+
90
+ - characterization test 없이 리팩터링 시작
91
+ - 테스트 실패 상태에서 다음 파일 진행
92
+ - architect 승인 없이 범위 확대
93
+ - 기능 추가/변경 (구조 개선만)
94
+ - refactor-cleaner가 코드 수정 (탐지/리포트만)
@@ -0,0 +1,86 @@
1
+ # Research Team
2
+
3
+ 리서치 결과를 팀으로 교차 검증하여 정확성과 호환성을 보장하는 리서치 협업 팀.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | best-practices (리더) | 패턴/안티패턴 종합, 팀원 간 충돌 해결, 최종 통합 요약 작성 | Haiku |
10
+ | security-advisory | 보안 관점에서 모든 권장사항 검증 | Haiku |
11
+ | codebase-patterns | 권장사항이 기존 코드 패턴과 호환되는지 검증 | Haiku |
12
+ | framework-docs | 최신 API/문서와 권장사항 대조 검증 | Haiku |
13
+
14
+ ## 활성화 조건
15
+
16
+ - `/vibe.spec` Step 3 리서치 단계에서 자동 활성화
17
+ - Agent Teams 환경변수 활성화 상태
18
+
19
+ ## 워크플로우
20
+
21
+ ```
22
+ [입력: 10개 병렬 리서치 결과]
23
+ |
24
+ ├──→ best-practices: 패턴 종합 + 합의 주도
25
+ ├──→ security-advisory: 보안 리스크 검증
26
+ ├──→ codebase-patterns: 기존 코드 호환성 검증
27
+ └──→ framework-docs: 최신 API 대조 검증
28
+ |
29
+ [SendMessage 교차 검증]
30
+ |
31
+ best-practices: 최종 통합 요약 → SPEC Context 반영
32
+ ```
33
+
34
+ ## spawn 패턴
35
+
36
+ ```text
37
+ TeamCreate(team_name="research-{feature}", description="Research collaboration for {feature}")
38
+
39
+ Task(team_name="research-{feature}", name="best-practices", subagent_type="best-practices-agent",
40
+ prompt="리서치 팀 리더. 10개 병렬 리서치 결과를 종합하세요.
41
+ 리서치 결과: {all_research_results}
42
+ 역할: 패턴/안티패턴 종합, 팀원 간 충돌 해결, 최종 통합 요약 작성.
43
+ TaskList를 확인하고 작업을 claim하세요. 팀원에게 SendMessage로 검증을 요청하세요.
44
+ 모든 작업 완료 후 최종 요약을 작성하세요.")
45
+
46
+ Task(team_name="research-{feature}", name="security-advisory", subagent_type="security-advisory-agent",
47
+ prompt="리서치 팀 보안 담당. 리서치 결과: {all_research_results}
48
+ 역할: 보안 관점에서 모든 권장사항 검증.
49
+ 보안 리스크 발견 시 best-practices에게 SendMessage로 알리세요.
50
+ TaskList에서 보안 관련 작업을 claim하세요.")
51
+
52
+ Task(team_name="research-{feature}", name="codebase-patterns", subagent_type="codebase-patterns-agent",
53
+ prompt="리서치 팀 코드베이스 담당. 리서치 결과: {all_research_results}
54
+ 역할: 권장사항이 기존 코드 패턴과 호환되는지 검증.
55
+ 비호환 발견 시 best-practices에게 SendMessage로 알리세요.
56
+ TaskList에서 호환성 관련 작업을 claim하세요.")
57
+
58
+ Task(team_name="research-{feature}", name="framework-docs", subagent_type="framework-docs-agent",
59
+ prompt="리서치 팀 문서 담당. 리서치 결과: {all_research_results}
60
+ 역할: 최신 API/문서와 권장사항 대조 검증.
61
+ 폐기/변경된 API 발견 시 best-practices에게 SendMessage로 알리세요.
62
+ TaskList에서 문서 검증 관련 작업을 claim하세요.")
63
+ ```
64
+
65
+ ## Result Merge Rules
66
+
67
+ | Area | Merge Strategy |
68
+ |------|----------------|
69
+ | Best Practices | Deduplicate, keep most detailed |
70
+ | Security | ALL included (no dedup for safety) |
71
+ | Libraries | Consensus recommendations |
72
+
73
+ ## 팀원 간 통신
74
+
75
+ ```text
76
+ security-advisory → best-practices: "JWT 라이브러리 권장사항에 CVE-2024-xxxx 취약점. 대안 필요"
77
+ codebase-patterns → best-practices: "기존 코드가 class 패턴인데 함수형 권장은 비호환. 점진적 마이그레이션 제안"
78
+ framework-docs → best-practices: "React 19에서 useEffect 패턴 변경됨. 리서치 결과의 패턴은 구버전"
79
+ best-practices → broadcast: "최종 합의: JWT는 jose 라이브러리로 교체, 함수형 전환은 신규 파일만 적용"
80
+ ```
81
+
82
+ ## ⛔ 하지 않는 것
83
+
84
+ - 코드 작성/수정 (리서치 결과만 텍스트로 반환)
85
+ - 파일 생성 (SPEC에 반영은 메인 에이전트가 담당)
86
+ - 보안 이슈 중복 제거 (안전을 위해 ALL 포함)
@@ -0,0 +1,125 @@
1
+ # Review Debate Team
2
+
3
+ 개별 리뷰어의 발견을 팀으로 토론하여 우선순위를 검증하고 오탐을 제거하는 교차 검증 팀.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | security-reviewer (리더) | P1/P2 이슈 종합, 보안 이슈 최종 판정, 합의 주도 | Sonnet |
10
+ | architecture-reviewer | 구조적 영향 평가, 숨겨진 결합도 식별 | Sonnet |
11
+ | performance-reviewer | 성능 영향 평가, 부하 시나리오 검증 | Sonnet |
12
+ | simplicity-reviewer | 과잉 설계 지적, 더 단순한 대안 제시, 오탐 식별 | Sonnet |
13
+
14
+ ## 활성화 조건
15
+
16
+ - P1 또는 P2 이슈 2개 이상 발견 시 자동 활성화
17
+ - Agent Teams 환경변수 활성화 상태
18
+ - P1/P2 이슈 1개 이하 → 스킵
19
+
20
+ ## 사용 스킬
21
+
22
+ - `/vibe.review` (Phase 4.5: Review Debate)
23
+ - `/vibe.spec.review` (Step 3.5: SPEC Debate)
24
+ - `/vibe.run` (Review Team: 구현 후 리뷰)
25
+
26
+ ## 워크플로우
27
+
28
+ ```
29
+ [입력: P1/P2 이슈 목록]
30
+ |
31
+ ├──→ security-reviewer: 보안 이슈 판정 + 합의 주도
32
+ ├──→ architecture-reviewer: 구조적 영향 평가
33
+ ├──→ performance-reviewer: 성능 영향 평가
34
+ └──→ simplicity-reviewer: 오탐 식별, 단순 대안 제시
35
+ |
36
+ [SendMessage 교차 검증]
37
+ |
38
+ security-reviewer: 팀 합의 종합 → 최종 P1/P2 목록
39
+ ```
40
+
41
+ ## spawn 패턴
42
+
43
+ ### Code Review 컨텍스트 (vibe.review, vibe.run)
44
+
45
+ ```text
46
+ TeamCreate(team_name="review-debate-{feature}", description="Review debate for {feature}")
47
+
48
+ Task(team_name="review-debate-{feature}", name="security-reviewer", subagent_type="security-reviewer",
49
+ mode="bypassPermissions",
50
+ prompt="리뷰 토론 팀 리더. Phase 2에서 발견된 P1/P2 이슈를 팀과 함께 검증하세요.
51
+ Phase 2 결과: {phase2_findings}
52
+ 역할: 보안 이슈 최종 판정, 팀원 간 우선순위 충돌 해결, 최종 합의 요약 작성.
53
+ TaskList를 확인하고 이슈를 claim하세요. 각 이슈에 대해 팀원에게 SendMessage로 검증을 요청하세요.
54
+ 모든 이슈 검증 완료 후 최종 합의 결과를 작성하세요.")
55
+
56
+ Task(team_name="review-debate-{feature}", name="architecture-reviewer", subagent_type="architecture-reviewer",
57
+ mode="bypassPermissions",
58
+ prompt="리뷰 토론 팀 아키텍처 담당. Phase 2 결과: {phase2_findings}
59
+ 역할: 각 이슈의 구조적 영향 평가, 숨겨진 결합도/의존성 식별.
60
+ 아키텍처 관점에서 우선순위 변경이 필요하면 security-reviewer에게 SendMessage로 알리세요.
61
+ TaskList에서 아키텍처 관련 이슈를 claim하세요.")
62
+
63
+ Task(team_name="review-debate-{feature}", name="performance-reviewer", subagent_type="performance-reviewer",
64
+ mode="bypassPermissions",
65
+ prompt="리뷰 토론 팀 성능 담당. Phase 2 결과: {phase2_findings}
66
+ 역할: 성능 영향 평가, 부하 시 cascading failure 가능성 검증.
67
+ 성능 관점에서 P2→P1 승격이 필요하면 security-reviewer에게 SendMessage로 알리세요.
68
+ TaskList에서 성능 관련 이슈를 claim하세요.")
69
+
70
+ Task(team_name="review-debate-{feature}", name="simplicity-reviewer", subagent_type="simplicity-reviewer",
71
+ mode="bypassPermissions",
72
+ prompt="리뷰 토론 팀 복잡도 담당. Phase 2 결과: {phase2_findings}
73
+ 역할: 과잉 진단(오탐) 식별, 더 단순한 수정 방안 제시.
74
+ 오탐이나 P1→P2 강등이 필요하면 security-reviewer에게 SendMessage로 알리세요.
75
+ TaskList에서 복잡도/단순화 관련 이슈를 claim하세요.")
76
+ ```
77
+
78
+ ### SPEC Review 컨텍스트 (vibe.spec.review)
79
+
80
+ spawn 패턴은 동일하되, prompt의 입력이 다름:
81
+
82
+ ```text
83
+ TeamCreate(team_name="spec-debate-{feature}", description="SPEC review debate for {feature}")
84
+
85
+ # prompt 차이점:
86
+ # - "Phase 2 결과: {phase2_findings}" 대신 "SPEC: {spec_content}, 발견된 이슈: {p1_p2_issues}"
87
+ # - 코드가 아닌 SPEC 문서를 대상으로 검증
88
+ # - 나머지 팀 구성/통신 패턴은 동일
89
+ ```
90
+
91
+ ## 팀원 간 통신
92
+
93
+ ```text
94
+ architecture-reviewer → security-reviewer: "Unbounded query는 부하 시 cascading failure 가능. P2→P1 승격 제안"
95
+ simplicity-reviewer → security-reviewer: "CSRF on read-only endpoint는 side effect 없음. P1→P2 강등 제안"
96
+ performance-reviewer → architecture-reviewer: "N+1 query가 현재 데이터 규모에서는 영향 없으나 확장 시 문제. 의견?"
97
+ security-reviewer → broadcast: "최종 합의: SQL Injection P1 유지, Unbounded query P1 승격, CSRF P2 강등, Circular dep 오탐 제거"
98
+ ```
99
+
100
+ ## 토론 결과 형식
101
+
102
+ ```
103
+ 🤝 REVIEW DEBATE RESULTS
104
+
105
+ Team Consensus (4 reviewers):
106
+
107
+ ✅ Validated P1 (unanimous):
108
+ 1. [SECURITY] SQL Injection — 4/4 agree critical
109
+
110
+ ⬆️ Upgraded P2→P1 (debate result):
111
+ 2. [PERF] Unbounded query — cascading failure risk under load
112
+
113
+ ⬇️ Downgraded P1→P2:
114
+ 3. [SECURITY] CSRF — read-only endpoint, no side effect
115
+
116
+ ❌ Removed (false positive):
117
+ 4. [ARCH] Circular dep — actually a valid cross-reference
118
+ ```
119
+
120
+ ## ⛔ 하지 않는 것
121
+
122
+ - 코드 직접 수정 (리포트만 작성)
123
+ - 이슈 수정 방법 구현
124
+ - P3 이슈 토론 (P1/P2만)
125
+ - 합의 없이 단독 판정
@@ -0,0 +1,81 @@
1
+ # Security Team
2
+
3
+ 보안 민감 코드 변경 시 전문 보안 검증 팀.
4
+
5
+ ## 팀 구성
6
+
7
+ | 팀원 | 역할 | Model |
8
+ |------|------|-------|
9
+ | security-reviewer (리더) | OWASP Top 10 검증, 보안 이슈 우선순위 결정 | Sonnet |
10
+ | data-integrity-reviewer | 데이터 무결성, 트랜잭션 관리, 입력 검증 | Sonnet |
11
+ | security-advisory-agent | 사용 라이브러리 CVE 확인, 보안 패치 확인 | Haiku |
12
+ | tester | 보안 테스트 케이스 작성, 침투 테스트 시나리오 검증 | Haiku |
13
+
14
+ ## 활성화 조건
15
+
16
+ - auth, payment, user-data, crypto 관련 파일 변경 감지 시
17
+ - 또는 수동으로 `security` 키워드 지정 시
18
+
19
+ ## 워크플로우
20
+
21
+ ```
22
+ [입력: 보안 민감 변경 파일 목록]
23
+ |
24
+ ├──→ security-reviewer: OWASP Top 10 검증 + 합의 주도
25
+ ├──→ data-integrity-reviewer: 데이터 흐름 + 입력 검증
26
+ ├──→ security-advisory-agent: CVE 스캔 + 의존성 검사
27
+ └──→ tester: 보안 테스트 케이스 작성
28
+ |
29
+ [SendMessage 교차 보고]
30
+ |
31
+ security-reviewer: P1 발견 → merge 차단
32
+ ```
33
+
34
+ ## spawn 패턴
35
+
36
+ ```text
37
+ TeamCreate(team_name="security-{feature}", description="Security audit team for {feature}")
38
+
39
+ Task(team_name="security-{feature}", name="security-reviewer", subagent_type="security-reviewer",
40
+ mode="bypassPermissions",
41
+ prompt="Security team leader. Comprehensive security audit for {feature}.
42
+ Files: {changed_files}
43
+ Role: OWASP Top 10 check. XSS, CSRF, SQL injection, auth bypass.
44
+ Coordinate with data-integrity-reviewer for data flow analysis.
45
+ Any P1 finding blocks merge — notify team immediately.")
46
+
47
+ Task(team_name="security-{feature}", name="data-integrity-reviewer", subagent_type="data-integrity-reviewer",
48
+ mode="bypassPermissions",
49
+ prompt="Security team data specialist. Verify data integrity for {feature}.
50
+ Files: {changed_files}
51
+ Role: Check transaction management, input validation, data sanitization.
52
+ Report findings to security-reviewer.")
53
+
54
+ Task(team_name="security-{feature}", name="security-advisory-agent", subagent_type="security-advisory-agent",
55
+ prompt="Security team advisory specialist. Check dependencies for {feature}.
56
+ Role: Scan for known CVEs in project dependencies. Check security advisories.
57
+ Report critical findings to security-reviewer.")
58
+
59
+ Task(team_name="security-{feature}", name="tester", subagent_type="tester",
60
+ mode="bypassPermissions",
61
+ prompt="Security team test specialist. Write security-focused tests for {feature}.
62
+ Files: {changed_files}
63
+ Role: Write tests for auth bypass, injection, permission escalation.
64
+ Report test results to security-reviewer.")
65
+ ```
66
+
67
+ ## 팀원 간 통신
68
+
69
+ ```text
70
+ security-reviewer → data-integrity-reviewer: "POST /users에서 입력 검증 확인 요청. SQL injection 가능성"
71
+ data-integrity-reviewer → security-reviewer: "입력 검증 없음 확인. parameterized query도 미사용. P1"
72
+ security-advisory-agent → security-reviewer: "jsonwebtoken@8.x에 CVE-2024-xxxxx. jose로 마이그레이션 필요"
73
+ tester → security-reviewer: "auth bypass 테스트: admin 엔드포인트에 일반 토큰으로 접근 성공. P1"
74
+ security-reviewer → broadcast: "P1 3건 발견. merge 차단. 수정 후 재검증 필요"
75
+ ```
76
+
77
+ ## ⛔ 하지 않는 것
78
+
79
+ - 코드 직접 수정 (보안 검증 + 리포트만)
80
+ - P3 이슈에 시간 소비 (P1/P2 집중)
81
+ - 합의 없이 merge 승인