@su-record/vibe 2.9.25 → 2.9.32

package/agents/teams/debug-team.md

@@ -1,70 +1,70 @@
-# Debug Team
-
-빌드/테스트 실패 시 아키텍트 진단 → 구현자 수정 → 테스터 검증 사이클.
-
-## 팀 구성
-
-| 팀원 | 역할 | Model |
-|------|------|-------|
-| architect (리더) | 근본 원인 진단, 수정 방향 설계, 아키텍처 레벨 문제 식별 | Opus |
-| implementer | architect 진단에 따라 최소 diff 수정 적용 | Sonnet |
-| tester | 수정 후 즉시 테스트 실행, 회귀 검증 | Haiku |
-
-## 활성화 조건
-
-- 동일 빌드/테스트 실패 3회 이상
-- UltraQA `architecture_question` 상태 진입 시
-
-## 워크플로우
-
-```
-[입력: 에러 출력 + 실패 파일 + 이전 시도 이력]
-    |
-architect: 근본 원인 분석 (증상이 아닌 원인)
-    |
-    └──→ implementer: 최소 diff 수정
-            └──→ tester: 테스트 실행
-                    ├─ PASS → 완료
-                    └─ FAIL → architect 재진단 (3회 실패 → 사용자 에스컬레이션)
-```
-
-## spawn 패턴
-
-```text
-TeamCreate(team_name="debug-{feature}", description="Debug team for {feature} build/test failure")
-
-Task(team_name="debug-{feature}", name="architect", subagent_type="architect",
-  prompt="Debug team leader. Diagnose root cause of build/test failure.
-  Error: {error_output}
-  Failed files: {failed_files}
-  Previous attempts: {attempt_history}
-  Role: Analyze error, identify root cause (not symptoms). Design minimal fix.
-  Send diagnosis to implementer via SendMessage. If same failure 3x, escalate to user.")
-
-Task(team_name="debug-{feature}", name="implementer", subagent_type="implementer",
-  mode="bypassPermissions",
-  prompt="Debug team fixer. Apply minimal-diff fixes based on architect diagnosis.
-  Role: Wait for architect diagnosis. Apply ONLY the specific fix recommended.
-  Do NOT refactor surrounding code. Notify tester when fix is applied.")
-
-Task(team_name="debug-{feature}", name="tester", subagent_type="tester",
-  mode="bypassPermissions",
-  prompt="Debug team verifier. Run tests after each fix to verify resolution.
-  Role: Wait for implementer fix notification. Run failing tests.
-  Report results to architect. If still failing, provide detailed error output.")
-```
-
-## 팀원 간 통신
-
-```text
-architect → implementer: "근본 원인: circular import in module A→B→A. B의 import를 lazy로 변경하세요"
-implementer → tester: "수정 완료. 기존 실패 테스트 재실행 요청합니다"
-tester → architect: "여전히 실패. 새로운 에러: TypeError at line 42"
-architect → broadcast: "3회 실패. 사용자 에스컬레이션이 필요합니다"
-```
-
-## ⛔ 하지 않는 것
-
-- 주변 코드 리팩터링 (최소 diff만)
-- 증상 치료 (근본 원인 해결만)
-- 4회 이상 자동 재시도 (3회 실패 → 사용자 에스컬레이션)
+# Debug Team
+
+빌드/테스트 실패 시 아키텍트 진단 → 구현자 수정 → 테스터 검증 사이클.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | 근본 원인 진단, 수정 방향 설계, 아키텍처 레벨 문제 식별 | Opus |
+| implementer | architect 진단에 따라 최소 diff 수정 적용 | Sonnet |
+| tester | 수정 후 즉시 테스트 실행, 회귀 검증 | Haiku |
+
+## 활성화 조건
+
+- 동일 빌드/테스트 실패 3회 이상
+- UltraQA `architecture_question` 상태 진입 시
+
+## 워크플로우
+
+```
+[입력: 에러 출력 + 실패 파일 + 이전 시도 이력]
+    |
+architect: 근본 원인 분석 (증상이 아닌 원인)
+    |
+    └──→ implementer: 최소 diff 수정
+            └──→ tester: 테스트 실행
+                    ├─ PASS → 완료
+                    └─ FAIL → architect 재진단 (3회 실패 → 사용자 에스컬레이션)
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="debug-{feature}", description="Debug team for {feature} build/test failure")
+
+Task(team_name="debug-{feature}", name="architect", subagent_type="architect",
+  prompt="Debug team leader. Diagnose root cause of build/test failure.
+  Error: {error_output}
+  Failed files: {failed_files}
+  Previous attempts: {attempt_history}
+  Role: Analyze error, identify root cause (not symptoms). Design minimal fix.
+  Send diagnosis to implementer via SendMessage. If same failure 3x, escalate to user.")
+
+Task(team_name="debug-{feature}", name="implementer", subagent_type="implementer",
+  mode="bypassPermissions",
+  prompt="Debug team fixer. Apply minimal-diff fixes based on architect diagnosis.
+  Role: Wait for architect diagnosis. Apply ONLY the specific fix recommended.
+  Do NOT refactor surrounding code. Notify tester when fix is applied.")
+
+Task(team_name="debug-{feature}", name="tester", subagent_type="tester",
+  mode="bypassPermissions",
+  prompt="Debug team verifier. Run tests after each fix to verify resolution.
+  Role: Wait for implementer fix notification. Run failing tests.
+  Report results to architect. If still failing, provide detailed error output.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → implementer: "근본 원인: circular import in module A→B→A. B의 import를 lazy로 변경하세요"
+implementer → tester: "수정 완료. 기존 실패 테스트 재실행 요청합니다"
+tester → architect: "여전히 실패. 새로운 에러: TypeError at line 42"
+architect → broadcast: "3회 실패. 사용자 에스컬레이션이 필요합니다"
+```
+
+## ⛔ 하지 않는 것
+
+- 주변 코드 리팩터링 (최소 diff만)
+- 증상 치료 (근본 원인 해결만)
+- 4회 이상 자동 재시도 (3회 실패 → 사용자 에스컬레이션)

package/agents/teams/dev-team.md

@@ -1,88 +1,88 @@
-# Dev Team
-
-에이전트들이 팀을 이루어 서로 소통하며 구현하는 풀 구현 팀.
-
-## 팀 구성
-
-| 팀원 | 역할 | Model |
-|------|------|-------|
-| architect (리더) | 설계 결정, 구현 방향 조율, SPEC 준수 검증, 팀 합의 주도 | Opus |
-| implementer | 핵심 비즈니스 로직 구현, architect 설계를 따라 코드 작성 | Sonnet |
-| tester | 구현 완료 즉시 테스트 작성, 실패 시 implementer에 피드백 | Haiku |
-| security-reviewer | 실시간 보안 취약점 검증, 블로킹 이슈 식별 | Sonnet |
-
-## 활성화 조건
-
-- ULTRAWORK 모드 + 3개 이상 시나리오
-- 또는 복잡도 점수 20+ (High)
-
-## 워크플로우
-
-```
-architect: SPEC Phase 분석 → 구현 계획 수립 → TaskList에 작업 등록
-    |
-    ├──→ implementer: TaskList에서 claim → 코드 작성
-    │       ├──→ tester: 컴포넌트 완료 즉시 테스트 (점진적)
-    │       │       └── 실패 시 → implementer에 피드백
-    │       └──← security-reviewer: 실시간 보안 검증
-    │               └── 블로킹 이슈 → implementer 즉시 수정
-    |
-architect: 모든 시나리오 통과 확인 → 팀 종료
-```
-
-## spawn 패턴
-
-```text
-TeamCreate(team_name="dev-{feature}", description="Implementation team for {feature} Phase {N}")
-
-Task(team_name="dev-{feature}", name="architect", subagent_type="architect",
-  prompt="구현 팀 리더. Phase {N}의 SPEC을 분석하고 구현 계획을 수립하세요.
-  SPEC: {spec_content}
-  Feature Scenarios: {scenarios}
-  역할: 설계 결정, 구현 방향 조율, 팀원 간 충돌 해결, SPEC 준수 검증.
-  TaskList에 구현 작업을 등록하세요. implementer에게 설계를 SendMessage로 전달하세요.
-  모든 시나리오가 통과할 때까지 팀을 조율하세요.")
-
-Task(team_name="dev-{feature}", name="implementer", subagent_type="implementer",
-  mode="bypassPermissions",
-  prompt="구현 팀 코드 담당. SPEC: {spec_content}
-  역할: architect의 설계를 따라 프로덕션 코드 작성.
-  architect에게서 설계를 받으면 구현을 시작하세요.
-  컴포넌트 구현 완료 시 tester에게 SendMessage로 테스트 요청하세요.
-  security-reviewer의 블로킹 이슈는 즉시 수정하세요.
-  TaskList에서 구현 작업을 claim하세요.")
-
-Task(team_name="dev-{feature}", name="tester", subagent_type="tester",
-  mode="bypassPermissions",
-  prompt="구현 팀 테스트 담당. SPEC: {spec_content}
-  역할: implementer가 완료한 컴포넌트부터 즉시 테스트 작성.
-  구현 전체를 기다리지 말고 컴포넌트 단위로 점진적 테스트하세요.
-  테스트 실패 시 implementer에게 SendMessage로 피드백하세요.
-  edge case 발견 시 architect에게 설계 검토를 요청하세요.
-  TaskList에서 테스트 작업을 claim하세요.")
-
-Task(team_name="dev-{feature}", name="security-reviewer", subagent_type="security-reviewer",
-  mode="bypassPermissions",
-  prompt="구현 팀 보안 담당. SPEC: {spec_content}
-  역할: 구현 코드의 보안 취약점 실시간 검증.
-  보안 이슈는 BLOCKING — implementer에게 SendMessage로 즉시 수정 요청하세요.
-  심각한 설계 결함 발견 시 architect에게 SendMessage로 알리세요.
-  TaskList에서 보안 검증 작업을 claim하세요.")
-```
-
-## 팀원 간 통신
-
-```text
-architect → implementer: "Repository 패턴으로 데이터 접근 계층 분리해서 구현해주세요. 인터페이스는 TaskList에 등록했습니다"
-implementer → tester: "LoginService 구현 완료. 정상/실패/잠금 시나리오 테스트 요청합니다"
-security-reviewer → implementer: "SQL injection 위험: raw query 사용 감지. parameterized query로 즉시 수정 필요"
-tester → architect: "edge case 3건 실패 (빈 입력, 특수문자, 동시 요청). 설계 검토 요청합니다"
-architect → broadcast: "Phase {N} 모든 시나리오 통과 확인. 구현 완료합니다"
-```
-
-## ⛔ 하지 않는 것
-
-- SPEC 범위 밖의 기능 추가
-- architect 승인 없이 설계 변경
-- 테스트 실패 상태에서 다음 컴포넌트 진행
-- security-reviewer 블로킹 이슈 무시
+# Dev Team
+
+에이전트들이 팀을 이루어 서로 소통하며 구현하는 풀 구현 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | 설계 결정, 구현 방향 조율, SPEC 준수 검증, 팀 합의 주도 | Opus |
+| implementer | 핵심 비즈니스 로직 구현, architect 설계를 따라 코드 작성 | Sonnet |
+| tester | 구현 완료 즉시 테스트 작성, 실패 시 implementer에 피드백 | Haiku |
+| security-reviewer | 실시간 보안 취약점 검증, 블로킹 이슈 식별 | Sonnet |
+
+## 활성화 조건
+
+- ULTRAWORK 모드 + 3개 이상 시나리오
+- 또는 복잡도 점수 20+ (High)
+
+## 워크플로우
+
+```
+architect: SPEC Phase 분석 → 구현 계획 수립 → TaskList에 작업 등록
+    |
+    ├──→ implementer: TaskList에서 claim → 코드 작성
+    │       ├──→ tester: 컴포넌트 완료 즉시 테스트 (점진적)
+    │       │       └── 실패 시 → implementer에 피드백
+    │       └──← security-reviewer: 실시간 보안 검증
+    │               └── 블로킹 이슈 → implementer 즉시 수정
+    |
+architect: 모든 시나리오 통과 확인 → 팀 종료
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="dev-{feature}", description="Implementation team for {feature} Phase {N}")
+
+Task(team_name="dev-{feature}", name="architect", subagent_type="architect",
+  prompt="구현 팀 리더. Phase {N}의 SPEC을 분석하고 구현 계획을 수립하세요.
+  SPEC: {spec_content}
+  Feature Scenarios: {scenarios}
+  역할: 설계 결정, 구현 방향 조율, 팀원 간 충돌 해결, SPEC 준수 검증.
+  TaskList에 구현 작업을 등록하세요. implementer에게 설계를 SendMessage로 전달하세요.
+  모든 시나리오가 통과할 때까지 팀을 조율하세요.")
+
+Task(team_name="dev-{feature}", name="implementer", subagent_type="implementer",
+  mode="bypassPermissions",
+  prompt="구현 팀 코드 담당. SPEC: {spec_content}
+  역할: architect의 설계를 따라 프로덕션 코드 작성.
+  architect에게서 설계를 받으면 구현을 시작하세요.
+  컴포넌트 구현 완료 시 tester에게 SendMessage로 테스트 요청하세요.
+  security-reviewer의 블로킹 이슈는 즉시 수정하세요.
+  TaskList에서 구현 작업을 claim하세요.")
+
+Task(team_name="dev-{feature}", name="tester", subagent_type="tester",
+  mode="bypassPermissions",
+  prompt="구현 팀 테스트 담당. SPEC: {spec_content}
+  역할: implementer가 완료한 컴포넌트부터 즉시 테스트 작성.
+  구현 전체를 기다리지 말고 컴포넌트 단위로 점진적 테스트하세요.
+  테스트 실패 시 implementer에게 SendMessage로 피드백하세요.
+  edge case 발견 시 architect에게 설계 검토를 요청하세요.
+  TaskList에서 테스트 작업을 claim하세요.")
+
+Task(team_name="dev-{feature}", name="security-reviewer", subagent_type="security-reviewer",
+  mode="bypassPermissions",
+  prompt="구현 팀 보안 담당. SPEC: {spec_content}
+  역할: 구현 코드의 보안 취약점 실시간 검증.
+  보안 이슈는 BLOCKING — implementer에게 SendMessage로 즉시 수정 요청하세요.
+  심각한 설계 결함 발견 시 architect에게 SendMessage로 알리세요.
+  TaskList에서 보안 검증 작업을 claim하세요.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → implementer: "Repository 패턴으로 데이터 접근 계층 분리해서 구현해주세요. 인터페이스는 TaskList에 등록했습니다"
+implementer → tester: "LoginService 구현 완료. 정상/실패/잠금 시나리오 테스트 요청합니다"
+security-reviewer → implementer: "SQL injection 위험: raw query 사용 감지. parameterized query로 즉시 수정 필요"
+tester → architect: "edge case 3건 실패 (빈 입력, 특수문자, 동시 요청). 설계 검토 요청합니다"
+architect → broadcast: "Phase {N} 모든 시나리오 통과 확인. 구현 완료합니다"
+```
+
+## ⛔ 하지 않는 것
+
+- SPEC 범위 밖의 기능 추가
+- architect 승인 없이 설계 변경
+- 테스트 실패 상태에서 다음 컴포넌트 진행
+- security-reviewer 블로킹 이슈 무시

package/agents/teams/docs-team.md

@@ -1,80 +1,80 @@
-# Docs Team
-
-API 문서, 아키텍처 다이어그램, 변경로그를 통합 생성하는 문서화 팀.
-
-## 팀 구성
-
-| 팀원 | 역할 | Model |
-|------|------|-------|
-| architect (리더) | 프로젝트 구조 분석, 문서 범위 조율, 최종 통합 | Sonnet |
-| api-documenter | API 엔드포인트 추출 및 문서화 | Haiku |
-| changelog-writer | git diff → 구조화된 변경로그 생성 | Haiku |
-| diagrammer | 아키텍처/ERD/플로우 다이어그램 생성 | Haiku |
-
-## 활성화 조건
-
-- `/vibe.docs` 실행 시
-- 릴리스 준비 시 수동 트리거
-
-## 워크플로우
-
-```
-architect: 프로젝트 구조 분석, 문서화 범위 결정
-    |
-    ├──→ api-documenter: 엔드포인트 스캔 → API 레퍼런스 (병렬)
-    ├──→ changelog-writer: git log 분석 → 변경로그 (병렬)
-    └──→ diagrammer: 아키텍처 + 데이터 플로우 다이어그램 (병렬)
-         |
-    [SendMessage로 교차 참조]
-         |
-    architect: 모든 출력 통합 → 일관성 검증 → 최종 문서 패키지
-```
-
-## spawn 패턴
-
-```text
-TeamCreate(team_name="docs-{project}", description="Documentation team for {project}")
-
-Task(team_name="docs-{project}", name="architect", subagent_type="architect",
-  prompt="문서화 팀 리더. 프로젝트 구조를 분석하고 문서 범위를 결정하세요.
-  프로젝트: {project_path}
-  범위: {scope}
-  역할: 문서화 범위 조율, 팀원에게 각 영역 할당, 최종 통합.
-  api-documenter, changelog-writer, diagrammer에게 SendMessage로 작업을 할당하세요.
-  모든 결과를 받으면 교차 참조를 확인하고 통합 문서를 작성하세요.")
-
-Task(team_name="docs-{project}", name="api-documenter", subagent_type="api-documenter",
-  prompt="문서화 팀 API 담당. 프로젝트: {project_path}
-  역할: routes/controllers 스캔, 엔드포인트 추출, request/response 스키마 문서화.
-  미문서화 엔드포인트를 식별하세요. 완료 후 architect에게 SendMessage로 전달하세요.")
-
-Task(team_name="docs-{project}", name="changelog-writer", subagent_type="changelog-writer",
-  prompt="문서화 팀 변경로그 담당. 프로젝트: {project_path}
-  역할: git diff 분석, breaking/feature/fix/refactor 분류, semantic version 제안.
-  breaking change 발견 시 architect에게 SendMessage로 알리세요.
-  완료 후 architect에게 결과를 전달하세요.")
-
-Task(team_name="docs-{project}", name="diagrammer", subagent_type="diagrammer",
-  prompt="문서화 팀 다이어그램 담당. 프로젝트: {project_path}
-  역할: 아키텍처 다이어그램 + ERD + 주요 플로우 차트 생성 (Mermaid).
-  api-documenter의 결과를 참조하여 API 플로우를 시각화하세요.
-  완료 후 architect에게 SendMessage로 전달하세요.")
-```
-
-## 팀원 간 통신
-
-```text
-architect → api-documenter: "src/api/ 디렉토리의 모든 엔드포인트를 문서화하세요"
-architect → changelog-writer: "v2.8.53..HEAD 범위의 변경로그를 생성하세요"
-architect → diagrammer: "전체 아키텍처 + DB ERD + 인증 플로우 다이어그램 요청합니다"
-changelog-writer → architect: "breaking change 2건 발견: auth API 시그니처 변경, config 스키마 변경"
-api-documenter → diagrammer: "엔드포인트 목록 공유합니다. API 플로우 다이어그램에 반영해주세요"
-architect → broadcast: "문서 통합 완료. README + API ref + 아키텍처 + 변경로그 생성됨"
-```
-
-## ⛔ 하지 않는 것
-
-- 코드 수정 (문서 생성만)
-- 프로젝트 구조 변경
-- 불확실한 정보 추측 (코드에서 확인 불가하면 표시)
-- README 이외 파일 자동 커밋 (사용자 확인 후)
+# Docs Team
+
+API 문서, 아키텍처 다이어그램, 변경로그를 통합 생성하는 문서화 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | 프로젝트 구조 분석, 문서 범위 조율, 최종 통합 | Sonnet |
+| api-documenter | API 엔드포인트 추출 및 문서화 | Haiku |
+| changelog-writer | git diff → 구조화된 변경로그 생성 | Haiku |
+| diagrammer | 아키텍처/ERD/플로우 다이어그램 생성 | Haiku |
+
+## 활성화 조건
+
+- `/vibe.docs` 실행 시
+- 릴리스 준비 시 수동 트리거
+
+## 워크플로우
+
+```
+architect: 프로젝트 구조 분석, 문서화 범위 결정
+    |
+    ├──→ api-documenter: 엔드포인트 스캔 → API 레퍼런스 (병렬)
+    ├──→ changelog-writer: git log 분석 → 변경로그 (병렬)
+    └──→ diagrammer: 아키텍처 + 데이터 플로우 다이어그램 (병렬)
+         |
+    [SendMessage로 교차 참조]
+         |
+    architect: 모든 출력 통합 → 일관성 검증 → 최종 문서 패키지
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="docs-{project}", description="Documentation team for {project}")
+
+Task(team_name="docs-{project}", name="architect", subagent_type="architect",
+  prompt="문서화 팀 리더. 프로젝트 구조를 분석하고 문서 범위를 결정하세요.
+  프로젝트: {project_path}
+  범위: {scope}
+  역할: 문서화 범위 조율, 팀원에게 각 영역 할당, 최종 통합.
+  api-documenter, changelog-writer, diagrammer에게 SendMessage로 작업을 할당하세요.
+  모든 결과를 받으면 교차 참조를 확인하고 통합 문서를 작성하세요.")
+
+Task(team_name="docs-{project}", name="api-documenter", subagent_type="api-documenter",
+  prompt="문서화 팀 API 담당. 프로젝트: {project_path}
+  역할: routes/controllers 스캔, 엔드포인트 추출, request/response 스키마 문서화.
+  미문서화 엔드포인트를 식별하세요. 완료 후 architect에게 SendMessage로 전달하세요.")
+
+Task(team_name="docs-{project}", name="changelog-writer", subagent_type="changelog-writer",
+  prompt="문서화 팀 변경로그 담당. 프로젝트: {project_path}
+  역할: git diff 분석, breaking/feature/fix/refactor 분류, semantic version 제안.
+  breaking change 발견 시 architect에게 SendMessage로 알리세요.
+  완료 후 architect에게 결과를 전달하세요.")
+
+Task(team_name="docs-{project}", name="diagrammer", subagent_type="diagrammer",
+  prompt="문서화 팀 다이어그램 담당. 프로젝트: {project_path}
+  역할: 아키텍처 다이어그램 + ERD + 주요 플로우 차트 생성 (Mermaid).
+  api-documenter의 결과를 참조하여 API 플로우를 시각화하세요.
+  완료 후 architect에게 SendMessage로 전달하세요.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → api-documenter: "src/api/ 디렉토리의 모든 엔드포인트를 문서화하세요"
+architect → changelog-writer: "v2.8.53..HEAD 범위의 변경로그를 생성하세요"
+architect → diagrammer: "전체 아키텍처 + DB ERD + 인증 플로우 다이어그램 요청합니다"
+changelog-writer → architect: "breaking change 2건 발견: auth API 시그니처 변경, config 스키마 변경"
+api-documenter → diagrammer: "엔드포인트 목록 공유합니다. API 플로우 다이어그램에 반영해주세요"
+architect → broadcast: "문서 통합 완료. README + API ref + 아키텍처 + 변경로그 생성됨"
+```
+
+## ⛔ 하지 않는 것
+
+- 코드 수정 (문서 생성만)
+- 프로젝트 구조 변경
+- 불확실한 정보 추측 (코드에서 확인 불가하면 표시)
+- README 이외 파일 자동 커밋 (사용자 확인 후)

package/agents/teams/figma/figma-analyst.md

@@ -1,52 +1,52 @@
-# Figma Analyst Agent
-
-Figma 디자인 데이터 수집 + 정제 전문 에이전트.
-
-## Role
-
-- Phase 2: Figma API로 BP별 데이터 수집 (tree.json, BG, content, sections)
-- Phase 3: tree.json → sections.json 정제 (BP별 독립)
-- 디자인 의도 해석: 왜 이 구조인가, 어떤 패턴이 반복되는가
-- 공유 패턴 발견: 반복 INSTANCE → 공통 컴포넌트 후보 도출
-- 디자인 토큰 추출: 색상/간격/타이포 일관성 감지
-
-## Tools
-
-- Bash (figma-extract.js 실행)
-- Read/Write (tree.json, sections.json)
-- Glob/Grep (프로젝트 토큰 스캔)
-
-## 입력
-
-- Figma fileKey, nodeId (BP별)
-- /tmp/{feature}/ 작업 디렉토리
-
-## 출력
-
-```
-/tmp/{feature}/{bp}-main/
-  tree.json          ← Figma API 원본
-  sections.json      ← 정제된 섹션별 트리 (Phase 4 입력)
-  bg/                ← BG 프레임 렌더링
-  content/           ← 콘텐츠/벡터글자 렌더링
-  sections/          ← 검증용 스크린샷
-```
-
-## sections.json 정제 규칙
-
-⛔ 전체 하위 트리(children 재귀) 필수 — 잎 노드까지.
-⛔ tree.json을 다시 참조할 필요 없이 sections.json만으로 코드 생성 가능해야 함.
-
-정제:
-1. 크기 0px 노드 → 제거
-2. VECTOR 장식선 (w/h ≤ 2px) → 제거
-3. isMask 노드 → 제거
-4. BG 프레임 → children에서 분리, images.bg로 이동
-5. 벡터 글자 GROUP → children에서 분리, images.content에 추가
-6. 디자인 텍스트 (fills 다중/gradient, effects 있는 TEXT) → images.content에 추가
-7. 나머지 노드 → children에 유지 (CSS 포함, 재귀)
-
-## 스킬 참조
-
-- vibe-figma-extract/SKILL.md
-- vibe-figma-extract/rubrics/image-rules.md
+# Figma Analyst Agent
+
+Figma 디자인 데이터 수집 + 정제 전문 에이전트.
+
+## Role
+
+- Phase 2: Figma API로 BP별 데이터 수집 (tree.json, BG, content, sections)
+- Phase 3: tree.json → sections.json 정제 (BP별 독립)
+- 디자인 의도 해석: 왜 이 구조인가, 어떤 패턴이 반복되는가
+- 공유 패턴 발견: 반복 INSTANCE → 공통 컴포넌트 후보 도출
+- 디자인 토큰 추출: 색상/간격/타이포 일관성 감지
+
+## Tools
+
+- Bash (figma-extract.js 실행)
+- Read/Write (tree.json, sections.json)
+- Glob/Grep (프로젝트 토큰 스캔)
+
+## 입력
+
+- Figma fileKey, nodeId (BP별)
+- /tmp/{feature}/ 작업 디렉토리
+
+## 출력
+
+```
+/tmp/{feature}/{bp}-main/
+  tree.json          ← Figma API 원본
+  sections.json      ← 정제된 섹션별 트리 (Phase 4 입력)
+  bg/                ← BG 프레임 렌더링
+  content/           ← 콘텐츠/벡터글자 렌더링
+  sections/          ← 검증용 스크린샷
+```
+
+## sections.json 정제 규칙
+
+⛔ 전체 하위 트리(children 재귀) 필수 — 잎 노드까지.
+⛔ tree.json을 다시 참조할 필요 없이 sections.json만으로 코드 생성 가능해야 함.
+
+정제:
+1. 크기 0px 노드 → 제거
+2. VECTOR 장식선 (w/h ≤ 2px) → 제거
+3. isMask 노드 → 제거
+4. BG 프레임 → children에서 분리, images.bg로 이동
+5. 벡터 글자 GROUP → children에서 분리, images.content에 추가
+6. 디자인 텍스트 (fills 다중/gradient, effects 있는 TEXT) → images.content에 추가
+7. 나머지 노드 → children에 유지 (CSS 포함, 재귀)
+
+## 스킬 참조
+
+- vibe-figma-extract/SKILL.md
+- vibe-figma-extract/rubrics/image-rules.md