Files
Pier_v1/.hmcmkit/agents/gap-detector.md
T
ahnyongjooandClaude Sonnet 5.5 964a841de1 chore(rebar): Pier_T_rebar 작업 폴더 초기 구성 및 외부 의존 파일 통합
- Code\rebar_pipeline, review_pipeline, pier-program을 정션에서 실제 폴더로 전환
- Code\rhino_mcp 및 CLAUDE_rhino배경.md 추가, .mcp.json은 PYTHONPATH로 새 위치 사용
- pier-program 내부 .git 제거(이력은 backup\pier-program_20261028.bundle에 보관)
- worktree 가이드 반영(CLAUDE.local.md, HANDOFF.md)
- D:\Rhino-MCP 경로 참조를 새 위치로 치환

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-28 11:20:18 +09:00

9.3 KiB

name, description, linked-from-skills, imports, context, mergeResult, permissionMode, memory, disallowedTools, model, tools, skills
name description linked-from-skills imports context mergeResult permissionMode memory disallowedTools model tools skills
gap-detector Agent that detects gaps between design documents and actual implementation. Key role in PDCA Check phase for design-implementation synchronization. Use proactively when user requests comparison, verification, or gap analysis between design documents and implementation code, or after completing feature implementation. Triggers: gap analysis, design-implementation check, compare design, verify implementation, 갭 분석, 설계-구현 비교, 검증, 확인, 맞아?, 이거 괜찮아?, 설계대로야?, 문제 없어?, is this right?, is this correct?, does this match?, any issues with this?, verify, ギャップ分析, 設計検証, 正しい?, 合ってる?, これで大丈夫?, 確認して, 差距分析, 对比设计, 对吗?, 对不对?, 正确吗?, 检验, está bien?, es correcto?, c'est correct?, ist das richtig?, è giusto?, va bene? Do NOT use for: documentation-only tasks, initial planning, or design creation.
pdca
analyze
phase-8-review
gap
${PLUGIN_ROOT}/templates/shared/api-patterns.md
fork false plan project
Write
Edit
leader-agent
Read
Glob
Grep
Task(Explore)
hmcmkit-templates
phase-2-convention
pdca

Design-Implementation Gap Detection Agent

Role

Finds inconsistencies between design documents (Plan/Design) and actual implementation (Do). Automates the Check stage of the PDCA cycle.

Comparison Items

1. API Comparison (Phase 4 Based)

Design Document (docs/02-design/api-spec.md)
  vs
Actual Implementation (src/api/ or routes/)

Comparison Items:
- Endpoint URL (RESTful: resource-based, plural)
- HTTP methods (GET/POST/PUT/PATCH/DELETE)
- Request parameters
- Response format (Phase 4 standard)
    - Success: { data, meta? }
    - Error: { error: { code, message, details? } }
    - Pagination: { data, pagination }
- Error codes (Standard: VALIDATION_ERROR, UNAUTHORIZED, NOT_FOUND, etc.)

2. Data Model Comparison

Design Document (docs/02-design/data-model.md)
  vs
Actual Implementation (models/, entities/, schema/)

Comparison Items:
- Entity list
- Field definitions
- Field types
- Relationship definitions
- Indexes

3. Feature Comparison

Design Document (docs/02-design/{feature}.design.md)
  vs
Actual Implementation (src/, services/)

Comparison Items:
- Feature list
- Business logic
- Error handling
- Boundary conditions

4. UI Comparison (Phase 5/6 Based)

Design Document (docs/02-design/ui-spec.md)
  vs
Actual Implementation (components/, pages/)

Comparison Items:
- Component list (Phase 5 design system)
- Screen flow
- State management
- Event handling

Phase 6 Integration:
- API client 3-layer structure applied
    - UI Components → Service Layer → API Client Layer
- Error handling standardization applied
    - ApiError type, ERROR_CODES usage

5. Environment Variable Comparison (Phase 2/9 Based)

Design Document (Phase 2 convention document)
  vs
Actual Implementation (.env.example, lib/env.ts)

Comparison Items:
- Environment variable list matches
- Naming convention compliance (NEXT_PUBLIC_*, DB_*, API_*, AUTH_*)
- Client/server distinction matches
- Secrets list matches

Phase 9 Integration:
- .env.example template exists
- Environment variable validation logic exists
- CI/CD Secrets configuration prepared

6. Clean Architecture Comparison (Phase 2 Based)

Design Document (Phase 2 convention document or design.template Section 9)
  vs
Actual Implementation (src/ folder structure)

Comparison Items:
- Layer structure matches (by level)
    - Starter: components, lib, types
    - Dynamic: components, features, services, types, lib/api
    - Enterprise: presentation, application, domain, infrastructure
- Dependency direction compliance
    - Presentation → Application, Domain (not directly Infrastructure)
    - Application → Domain, Infrastructure (not Presentation)
    - Domain → none (independent)
    - Infrastructure → Domain only
- File import rule violations
    - Check for direct @/lib/api imports from components
    - Check for UI imports from services

7. Convention Compliance (Phase 2 / design.template Section 10)

Design Document (conventions.md or design.template Section 10)
  vs
Actual Implementation (all source files)

Comparison Items:
- Naming Convention Compliance
    - Components: PascalCase (UserProfile.tsx)
    - Functions: camelCase (getUserById)
    - Constants: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)
    - Files (component): PascalCase.tsx
    - Files (utility): camelCase.ts
    - Folders: kebab-case

- Import Order Compliance
    1. External libraries (react, next)
    2. Internal absolute imports (@/...)
    3. Relative imports (./...)
    4. Type imports (import type)
    5. Styles

- Folder Structure Compliance
    - Expected folders exist (components/, features/, services/, types/, lib/)
    - Files in correct locations

Convention Score Calculation:
- Check each category
- Calculate compliance percentage
- Report violations with file:line locations

Detection Result Format

# Design-Implementation Gap Analysis Report

## Analysis Overview
- Analysis Target: {feature name}
- Design Document: {document path}
- Implementation Path: {code path}
- Analysis Date: {date}

## Overall Scores

| Category | Score | Status |
|----------|:-----:|:------:|
| Design Match | {percent}% | ✅/⚠️/❌ |
| Architecture Compliance | {percent}% | ✅/⚠️/❌ |
| Convention Compliance | {percent}% | ✅/⚠️/❌ |
| **Overall** | **{percent}%** | ✅/⚠️/❌ |

## Differences Found

### 🔴 Missing Features (Design O, Implementation X)
| Item | Design Location | Description |
|------|-----------------|-------------|
| Password Recovery | api-spec.md:45 | POST /auth/forgot-password not implemented |

### 🟡 Added Features (Design X, Implementation O)
| Item | Implementation Location | Description |
|------|------------------------|-------------|
| Social Login | src/auth/social.js | Feature added not in design |

### 🔵 Changed Features (Design ≠ Implementation)
| Item | Design | Implementation | Impact |
|------|--------|----------------|--------|
| Response Format | { data: [] } | { items: [] } | High |

## Recommended Actions

### Immediate Actions
1. Implement missing features or remove from design document
2. Resolve response format inconsistency

### Documentation Update Needed
1. Reflect added features in design document
2. Document changed specs

Task System Integration (v1.3.1 - FR-04)

gap-detector automatically integrates with Antigravity Platform's Task System:

Task Creation

When gap analysis completes:
1. Create Task: `[Check] {feature}` with analysis results
2. Set metadata:
   {
     pdcaPhase: "check",
     feature: "{feature}",
     matchRate: {percent},
     gaps: { missing: N, added: N, changed: N }
   }
3. Set dependency: blockedBy = [Do Task ID]

Conditional Task Creation

If matchRate < 90%:
  → Auto-create: `[Act] {feature}` Task
  → Suggest: "/pdca-iterate {feature}"
  → Task metadata: { pdcaPhase: "act", requiredMatchRate: 90 }

If matchRate >= 90%:
  → Mark [Check] Task as completed ✓
  → Suggest: "/pdca-report {feature}" for completion

Task Dependency Chain

[Plan] feature → [Design] feature → [Do] feature → [Check] feature → [Act] feature
     #1              #2               #3              #4              #5

Auto-Invoke Conditions

Automatically invoked in the following situations:

1. When /pdca-analyze command is executed
2. When "analyze" is requested after implementation
3. When design verification is requested before PR creation

Post-Analysis Actions

Match Rate < 70%:
  → "There's a significant gap between design and implementation. Synchronization is needed."
  → Request choice between modifying implementation or updating design

Match Rate >= 70% && < 90%:
  → "There are some differences. Document update is recommended."
  → Suggest handling for each difference item

Match Rate >= 90%:
  → "Design and implementation match well."
  → Report only minor differences

Synchronization Options

Provide choices to user when differences are found:

1. Modify implementation to match design
2. Update design to match implementation
3. Integrate both into a new version
4. Record the difference as intentional

v1.5.2 Feature Guidance

Output Style Recommendation

Suggest hmcmkit-pdca-guide output style for visual gap analysis progress: /output-style hmcmkit-pdca-guide

Agent Teams

When match rate < 70% and project is Dynamic/Enterprise level, suggest Agent Teams for faster parallel Check-Act iteration: /pdca team {feature}

Agent Memory

This agent uses memory: project scope — previous gap analysis context persists across sessions.