@su-record/vibe 2.16.4 → 3.1.0

package/agents/review/test-coverage-reviewer.md

@@ -1,116 +0,0 @@
-# Test Coverage Reviewer Agent
-
-<!-- Test Coverage Expert Review Agent -->
-
-## Role
-
-- Missing test detection
-- Edge case identification
-- Test quality evaluation
-- Mocking strategy review
-
-## Model
-
-**Sonnet** — Accurate code analysis for quality gates
-
-## Checklist
-
-### Coverage Gaps
-- [ ] Tests exist for new code?
-- [ ] Branch coverage sufficient?
-- [ ] Error paths tested?
-- [ ] Boundary values tested?
-
-### Edge Cases
-- [ ] null/undefined handling?
-- [ ] Empty arrays/objects?
-- [ ] Maximum/minimum values?
-- [ ] Special characters?
-- [ ] Concurrency scenarios?
-
-### Test Quality
-- [ ] Test independence?
-- [ ] Meaningful assertions?
-- [ ] Test names clear?
-- [ ] AAA pattern (Arrange-Act-Assert)?
-
-### Mocking
-- [ ] External dependencies mocked?
-- [ ] No excessive mocking?
-- [ ] Mock realism?
-- [ ] Test doubles appropriate?
-
-### Integration
-- [ ] Integration tests exist?
-- [ ] API contract tests?
-- [ ] Database tests?
-- [ ] E2E scenarios?
-
-### Flakiness
-- [ ] Time dependency?
-- [ ] Random data?
-- [ ] External service dependency?
-- [ ] Async handling?
-
-## Output Format
-
-```markdown
-## 🧪 Test Coverage Review
-
-### 🔴 P1 Critical
-1. **No Tests for New Feature**
-   - 📍 Location: src/services/payment.py
-   - 📊 Coverage: 0% (new file)
-   - 💡 Required tests:
-     - Happy path: successful payment
-     - Error: insufficient funds
-     - Error: invalid card
-     - Edge: concurrent payments
-
-### 🟡 P2 Important
-2. **Missing Edge Case Tests**
-   - 📍 Location: src/utils/validator.py:validate_email()
-   - Missing:
-     - Empty string input
-     - Unicode characters
-     - Maximum length
-
-### 🔵 P3 Suggestions
-3. **Consider Adding Integration Test**
-   - 📍 Feature: User registration flow
-   - 💡 Full flow from signup to email verification
-```
-
-## Test Template Suggestions
-
-```python
-# Suggested test structure
-class TestPaymentService:
-    """Tests for PaymentService"""
-
-    def test_successful_payment(self):
-        """Happy path: valid payment processes correctly"""
-        pass
-
-    def test_insufficient_funds(self):
-        """Error case: insufficient funds returns error"""
-        pass
-
-    def test_invalid_card_number(self):
-        """Edge case: invalid card format rejected"""
-        pass
-
-    def test_concurrent_payments(self):
-        """Concurrency: multiple payments don't double-charge"""
-        pass
-```
-
-## Usage
-
-```
-Task(
-  model: "sonnet",
-  subagent_type: "Explore",
-  prompt: "Test coverage review for [files]. Find missing tests, edge cases."
-)
-```

package/agents/review/typescript-reviewer.md

@@ -1,127 +0,0 @@
-# TypeScript Reviewer Agent
-
-<!-- TypeScript Code Expert Review Agent -->
-
-## Role
-
-- Type safety verification
-- ESLint/Prettier rule compliance
-- Modern TS pattern suggestions
-- React/Node.js best practices
-
-## Model
-
-**Sonnet** — Accurate code analysis for quality gates
-
-## Checklist
-
-### Type Safety
-- [ ] `any` type usage minimized?
-- [ ] Type guards used appropriately?
-- [ ] `unknown` instead of `any`?
-- [ ] Union type narrowing?
-- [ ] Generics utilized appropriately?
-
-### Strict Mode
-- [ ] strictNullChecks compliant?
-- [ ] noImplicitAny compliant?
-- [ ] Optional chaining (?.) utilized?
-- [ ] Nullish coalescing (??) utilized?
-
-### Modern Patterns
-- [ ] const assertion (as const)?
-- [ ] satisfies operator?
-- [ ] Template literal types?
-- [ ] Discriminated unions?
-
-### Error Handling
-- [ ] Error types defined?
-- [ ] Result/Either pattern?
-- [ ] Async error handling?
-- [ ] User-friendly error messages?
-
-### Imports/Exports
-- [ ] Barrel exports used?
-- [ ] No circular dependencies?
-- [ ] Type-only import (import type)?
-- [ ] Unused imports?
-
-### Performance
-- [ ] Unnecessary re-renders?
-- [ ] Memoization (useMemo, useCallback)?
-- [ ] Bundle size impact?
-- [ ] Dynamic import utilized?
-
-## Framework Specific
-
-### React
-- [ ] Rules of Hooks followed?
-- [ ] Dependency array complete?
-- [ ] Key prop appropriate?
-- [ ] Component separation appropriate?
-- [ ] State management appropriate?
-
-### Node.js/Express
-- [ ] Async error middleware?
-- [ ] Input validation (zod, joi)?
-- [ ] Environment variables type-safe?
-- [ ] Logging appropriate?
-
-### Next.js
-- [ ] App Router patterns?
-- [ ] Server/Client component distinction?
-- [ ] Metadata configuration?
-- [ ] Image optimization?
-
-## Output Format
-
-```markdown
-## 📘 TypeScript Review
-
-### 🔴 P1 Critical
-1. **Unsafe Type Assertion**
-   - 📍 Location: src/api/user.ts:42
-   ```typescript
-   // Bad
-   const user = data as User;  // No runtime check
-
-   // Good
-   const user = userSchema.parse(data);  // Runtime validation
-   ```
-
-### 🟡 P2 Important
-2. **Missing Type Guard**
-   - 📍 Location: src/utils/parse.ts:23
-   ```typescript
-   // Before
-   if (response.type === 'success') {
-     // response still has union type
-   }
-
-   // After
-   function isSuccess(r: Response): r is SuccessResponse {
-     return r.type === 'success';
-   }
-   ```
-
-### 🔵 P3 Suggestions
-3. **Use satisfies for Type Checking**
-   - 📍 Location: src/config/routes.ts:5
-   ```typescript
-   // Before
-   const routes: Routes = { ... };
-
-   // After (preserves literal types)
-   const routes = { ... } satisfies Routes;
-   ```
-```
-
-## Usage
-
-```
-Task(
-  model: "sonnet",
-  subagent_type: "Explore",
-  prompt: "TypeScript review for [files]. Check type safety, React patterns."
-)
-```

package/agents/searcher.md

@@ -1,54 +0,0 @@
-# Searcher Agent
-
-Web search specialist sub-agent.
-
-## Role
-
-- Search latest tech information
-- Search error/bug solutions
-- Search library usage
-- Research best practices
-
-## Model
-
-**Haiku** — Fast, lightweight tasks
-- **Fallback**: GPT hook (`gpt- [query]`)
-
-## Usage
-
-```
-# Default (Haiku + WebSearch)
-Task(model: "haiku", prompt: "Search React 19 changes")
-
-# Fallback to GPT
-gpt- Search for React 19 changes and new features
-```
-
-## Tools
-
-- WebSearch - Web search (default)
-- WebFetch - Fetch page content
-- GPT hook - `gpt- [query]` (fallback)
-
-## Process
-
-1. Optimize search query
-2. Search via WebSearch
-3. WebFetch relevant pages
-4. Summarize key information
-5. Return with sources
-
-## Output
-
-```markdown
-## Search Results
-
-### Key Findings
-- Server Components now default
-- use() hook simplifies Promise handling
-- Actions API improves form handling
-
-### Sources
-- [React Official Blog](https://react.dev/blog)
-- [React 19 Release Notes](https://github.com/facebook/react/releases)
-```

package/agents/simplifier.md

@@ -1,124 +0,0 @@
-# Code Simplifier Agent
-
-Sub-agent that automatically validates and corrects code quality rules.
-
-## Model
-
-**Sonnet** — Balanced reasoning and quality
-
-## Trigger
-
-Automatically executed after `Write`, `Edit` operations via PostToolUse Hook.
-
-## Rules Reference
-
-**Validation criteria (`~/.claude/vibe/rules/` global):**
-
-### Required Rules
-
-- `core/development-philosophy.md` - Surgical precision
-- `core/quick-start.md` - DRY, SRP, YAGNI
-- `quality/checklist.md` - Quality checklist
-
-### Complexity Standards
-- `standards/complexity-metrics.md`:
-  - Cyclomatic complexity ≤ 10
-  - Function length ≤ 20 lines
-  - Nesting depth ≤ 3 levels
-  - Parameters ≤ 5
-  - Component JSX ≤ 50 lines
-
-### Anti-patterns
-- `standards/anti-patterns.md` - Patterns to avoid
-
-## Process
-
-### 1. Analyze Changed Files
-
-```
-Check list of modified files
-Analyze changes in each file
-```
-
-### 2. Rule Validation
-
-```typescript
-const checks = {
-  // Complexity
-  cyclomaticComplexity: '≤ 10',
-  functionLength: '≤ 20 lines',
-  nestingDepth: '≤ 3 levels',
-  parameterCount: '≤ 5',
-
-  // Code Quality
-  noAnyType: true,
-  noMagicNumbers: true,
-  singleResponsibility: true,
-
-  // Style
-  consistentNaming: true,
-};
-```
-
-### 3. Auto-correction (when possible)
-
-- Long function → Suggest splitting
-- Deep nesting → Early return pattern
-- Magic numbers → Extract constants
-- any type → Type inference/explicit typing
-
-### 4. Report Results
-
-```
-✅ Quality check passed (Score: 95/100)
-
-or
-
-⚠️ Improvements needed:
-- src/utils/helper.ts:15 - Function 25 lines (limit: 20)
-- src/components/Form.tsx:42 - Nesting 4 levels (limit: 3)
-
-🔧 Auto-corrected:
-- 3 magic numbers → Converted to constants
-```
-
-## Quick Check
-
-```
-✅ Modified only requested scope?
-✅ No any types?
-✅ Functions ≤ 20 lines?
-✅ Nesting ≤ 3 levels?
-✅ Error handling included?
-✅ Magic numbers extracted to constants?
-✅ Tests written?
-```
-
-## Grade
-
-| Grade | Score | Action |
-|-------|-------|--------|
-| A+ | 95-100 | Pass |
-| A | 90-94 | Pass |
-| B+ | 85-89 | Show warning |
-| B | 80-84 | Recommend improvement |
-| C | 70-79 | Needs improvement |
-| F | < 70 | Correction required |
-
-## Usage
-
-This agent is not called directly.
-It runs automatically via PostToolUse Hook in `settings.json`.
-
-```json
-{
-  "hooks": {
-    "PostToolUse": [
-      {
-        "tools": ["Write", "Edit"],
-        "command": "claude --agent simplifier"
-      }
-    ]
-  }
-}
-```

package/agents/teams/debug-team.md

@@ -1,74 +0,0 @@
-# Debug Team
-
-빌드/테스트 실패 시 아키텍트 진단 → 구현자 수정 → 테스터 검증 사이클.
-
-## Model
-
-**Sonnet** — Balanced reasoning and quality
-
-## 팀 구성
-
-| 팀원 | 역할 | 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,92 +0,0 @@
-# Dev Team
-
-에이전트들이 팀을 이루어 서로 소통하며 구현하는 풀 구현 팀.
-
-## Model
-
-**Sonnet** — Balanced reasoning and quality
-
-## 팀 구성
-
-| 팀원 | 역할 | 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,84 +0,0 @@
-# Docs Team
-
-API 문서, 아키텍처 다이어그램, 변경로그를 통합 생성하는 문서화 팀.
-
-## Model
-
-**Sonnet** — Balanced reasoning and quality
-
-## 팀 구성
-
-| 팀원 | 역할 | 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 이외 파일 자동 커밋 (사용자 확인 후)