From 2fb2a992779b5e27147115dd2b5f74b0332fd486 Mon Sep 17 00:00:00 2001 From: hyeonsang Date: Thu, 9 Jul 2026 23:48:12 -0700 Subject: [PATCH] refactor(plugin): slim prompt surface -1.7k lines + hard-gate commit hook (v0.1.11) Prune (net -1763 lines, ~-19% attention surface across agents + command bodies): - remove base-competence re-teaching, Auto-Discovery boilerplate (x4 near-dup), UX mockups, generic tech-stack enumerations across 13 agents + 4 commands - logic, gates, thresholds, and the adversarial-verify mechanism unchanged - verified by 4 fresh-context adversarial verifiers: 18/18 SAFE Hard-gate hook (harness-enforced quality gate): - hooks.json PreToolUse blocks a pipeline `git commit` when the message carries the score signal but no fresh .wigtn/gate-pass PASS artifact (30-min freshness) - auto-commit Step 3.5 writes the artifact on rollup PASS; Rule 13; --no-review omits the signal to preserve the emergency hotfix path - manual commits are unaffected (no signal); safe-fail (closed, not open) Version 0.1.10 -> 0.1.11 (plugin.json x2, marketplace.json, READMEs, CLAUDE.md). Co-Authored-By: Claude Opus 4.8 (1M context) --- .claude-plugin/marketplace.json | 4 +- .claude-plugin/plugin.json | 2 +- .gitignore | 3 + CLAUDE.md | 3 +- README.cn.md | 2 +- README.ko.md | 2 +- README.md | 2 +- .../wigtn-plugins/.claude-plugin/plugin.json | 2 +- plugins/wigtn-plugins/agents/ai-agent.md | 286 ++---------------- .../agents/architecture-decision.md | 152 ++-------- .../wigtn-plugins/agents/backend-architect.md | 121 +------- .../wigtn-plugins/agents/code-formatter.md | 174 +---------- plugins/wigtn-plugins/agents/code-reviewer.md | 46 +-- .../wigtn-plugins/agents/design-discovery.md | 169 +---------- .../agents/frontend-developer.md | 163 +--------- .../wigtn-plugins/agents/mobile-developer.md | 165 +--------- .../agents/parallel-digging-coordinator.md | 110 +------ .../agents/parallel-review-coordinator.md | 121 +------- plugins/wigtn-plugins/agents/pr-reviewer.md | 38 +-- plugins/wigtn-plugins/agents/prd-reviewer.md | 103 +------ .../agents/team-build-coordinator.md | 202 ++----------- plugins/wigtn-plugins/commands/auto-commit.md | 28 +- plugins/wigtn-plugins/commands/implement.md | 139 +-------- plugins/wigtn-plugins/commands/prd.md | 86 +----- plugins/wigtn-plugins/commands/review-pr.md | 27 +- plugins/wigtn-plugins/commands/screen-spec.md | 76 +---- plugins/wigtn-plugins/hooks/hooks.json | 9 + 27 files changed, 236 insertions(+), 1999 deletions(-) diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index f7efcf4..d28e6a2 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -6,14 +6,14 @@ }, "metadata": { "description": "AI-native Vibe Coding — From idea to Deploy, Zero friction. Unified plugin with 13 agents, 5 commands, 6 skills, team-based parallel build, 20 design styles, screen-spec generator.", - "version": "0.1.10" + "version": "0.1.11" }, "plugins": [ { "name": "wigtn-plugins", "description": "Unified AI-native Vibe Coding plugin: PRD generation, digging analysis, screen-spec (IA / User Flow / Wireframe HTML / Dev Handoff), team-based parallel implementation, quality-gated auto-commit, 20 design styles, frontend (React/Next.js), backend (NestJS/Prisma), mobile (React Native/Expo), AI integration (STT/LLM), DevOps (Docker/CI-CD). 13 agents, 5 commands, 6 skills.", "source": "./plugins/wigtn-plugins", - "version": "0.1.10", + "version": "0.1.11", "author": { "name": "WIGTN Crew", "email": "rukais2294@gmail.com" diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 49972bd..4786fd0 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "wigtn-plugins", - "version": "0.1.10", + "version": "0.1.11", "description": "AI-native Vibe Coding — From idea to Deploy, Zero friction. Unified plugin with 13 agents, 5 commands, 6 skills, team-based parallel build, 20 design styles.", "author": { "name": "WIGTN Crew", diff --git a/.gitignore b/.gitignore index a88210e..3e297d0 100644 --- a/.gitignore +++ b/.gitignore @@ -21,6 +21,9 @@ memory-lake/ .claude/ PLANNING/ +# WIGTN quality-gate hard-gate artifact (per-project runtime state; never committed) +.wigtn/ + # Team-private assets (brand logos, ppt templates & data) — not for the public plugin docs/ diff --git a/CLAUDE.md b/CLAUDE.md index bfdf83a..ea6fa6e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -4,7 +4,7 @@ A unified Claude Code plugin enabling AI-powered Vibe Coding: idea to production with minimal friction. -**Version**: 0.1.10 +**Version**: 0.1.11 **License**: Apache-2.0 **Repository**: https://github.com/wigtn/wigtn-plugins @@ -64,6 +64,7 @@ plugins/wigtn-plugins/ - **PASS** (커밋): critical 0 AND major 0 AND minor <5 - **Security Critical**: critical의 부분집합 → 항상 FAIL (zero-tolerance, no score-cap hack) - **정밀도**: major+ finding은 게이트 반영 전 adversarial refute 1회로 오탐 강등 +- **하드 게이트 (hook 강제)**: 게이트가 프롬프트라 컨텍스트가 차면 스킵될 수 있으므로, `hooks.json`의 PreToolUse가 `git commit`을 가로채 강제한다. 롤업 PASS 시 `/auto-commit`이 `.wigtn/gate-pass`(mtime = PASS 시각)를 기록하고, 커밋 메시지에 `Quality Score:` 신호가 있는데 30분 내 아티팩트가 없으면 hook이 커밋을 **차단(exit 2)**한다. 수동 커밋(신호 없음)·`--no-review`(신호 제거)는 무마찰. 하네스가 막으므로 프롬프트 준수에 의존하지 않는다. ## Conventions diff --git a/README.cn.md b/README.cn.md index 985a369..7eba972 100644 --- a/README.cn.md +++ b/README.cn.md @@ -6,7 +6,7 @@ **一个插件。13 个智能体。从创意到生产。** -![Version](https://img.shields.io/badge/v0.1.10-Unified_Plugin-FF6B6B?style=for-the-badge) +![Version](https://img.shields.io/badge/v0.1.11-Unified_Plugin-FF6B6B?style=for-the-badge) ![Agents](https://img.shields.io/badge/13-Agents-5A67D8?style=for-the-badge) ![Commands](https://img.shields.io/badge/5-Commands-38B2AC?style=for-the-badge) ![Skills](https://img.shields.io/badge/6-Skills-00D4AA?style=for-the-badge) diff --git a/README.ko.md b/README.ko.md index 60d2a9b..ccc62e4 100644 --- a/README.ko.md +++ b/README.ko.md @@ -6,7 +6,7 @@ **하나의 플러그인. 13개 에이전트. 아이디어에서 프로덕션까지.** -![Version](https://img.shields.io/badge/v0.1.10-Unified_Plugin-FF6B6B?style=for-the-badge) +![Version](https://img.shields.io/badge/v0.1.11-Unified_Plugin-FF6B6B?style=for-the-badge) ![Agents](https://img.shields.io/badge/13-Agents-5A67D8?style=for-the-badge) ![Commands](https://img.shields.io/badge/5-Commands-38B2AC?style=for-the-badge) ![Skills](https://img.shields.io/badge/6-Skills-00D4AA?style=for-the-badge) diff --git a/README.md b/README.md index 999f885..9eb7913 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ **One plugin. 13 agents. From idea to production.** -![Version](https://img.shields.io/badge/v0.1.10-Unified_Plugin-FF6B6B?style=for-the-badge) +![Version](https://img.shields.io/badge/v0.1.11-Unified_Plugin-FF6B6B?style=for-the-badge) ![Agents](https://img.shields.io/badge/13-Agents-5A67D8?style=for-the-badge) ![Commands](https://img.shields.io/badge/5-Commands-38B2AC?style=for-the-badge) ![Skills](https://img.shields.io/badge/6-Skills-00D4AA?style=for-the-badge) diff --git a/plugins/wigtn-plugins/.claude-plugin/plugin.json b/plugins/wigtn-plugins/.claude-plugin/plugin.json index 089ba55..f0be779 100644 --- a/plugins/wigtn-plugins/.claude-plugin/plugin.json +++ b/plugins/wigtn-plugins/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "wigtn-plugins", - "version": "0.1.10", + "version": "0.1.11", "description": "AI-native Vibe Coding — From idea to Deploy, Zero friction. 13 agents, 5 commands, 6 skills, team-based parallel build, 20 design styles, screen-spec generator (IA / User Flow / Wireframe HTML), WIGTN-brand PPT generator.", "agents": [ "./agents/architecture-decision.md", diff --git a/plugins/wigtn-plugins/agents/ai-agent.md b/plugins/wigtn-plugins/agents/ai-agent.md index a7660e0..08917bd 100644 --- a/plugins/wigtn-plugins/agents/ai-agent.md +++ b/plugins/wigtn-plugins/agents/ai-agent.md @@ -56,83 +56,15 @@ You are an AI feature implementation specialist. Your role is to **discover exis ### Auto-Discovery Protocol -```yaml -context_discovery: - # 1. 프로젝트 메타데이터 수집 - project_metadata: - must_read: - - "CLAUDE.md" # 프로젝트 규칙, 아키텍처, AI 관련 결정사항 - - "README.md" # 프로젝트 개요, 기술 스택 - should_read: - - "pyproject.toml / package.json" # 이미 설치된 AI 라이브러리 확인 - - ".env.example / .env.local" # 어떤 AI API 키가 사용되는지 확인 - - "src/config.* / config/*" # 설정 관리 패턴 확인 - strategy: "Glob으로 존재 여부 확인 -> 존재하면 Read" - - # 2. 기존 AI 통합 코드 탐색 - ai_code_scan: - action: "프로젝트 내 기존 AI 관련 코드를 Grep으로 탐색" - search_patterns: - - "openai|anthropic|google.generativeai" # AI SDK import - - "ChatCompletion|messages.*role" # LLM 호출 패턴 - - "whisper|transcri" # STT 관련 - - "embedding|vector|similarity" # Embedding 관련 - - "stream|SSE|EventSource|async.*for.*chunk" # 스트리밍 패턴 - - "system.*prompt|SYSTEM_PROMPT" # 프롬프트 관리 - - "function_call|tool_use|tools.*type" # Function calling - detect: - - "이미 사용 중인 AI Provider (OpenAI, Anthropic, etc.)" - - "AI 호출 래퍼 함수 존재 여부 (재사용 가능한 유틸리티)" - - "프롬프트 저장 방식 (하드코딩, 파일, DB, 환경변수)" - - "스트리밍 구현 여부와 패턴" - - "에러 핸들링 패턴 (retry, fallback, circuit breaker)" - output: "ai_integration_map — 기존 AI 코드의 위치와 패턴" - - # 3. API 키 / 설정 관리 패턴 확인 - config_pattern: - action: "환경변수와 설정 파일에서 AI 관련 설정 패턴 파악" - search_patterns: - - "OPENAI_API_KEY|ANTHROPIC_API_KEY|GOOGLE_API_KEY" - - "AI_MODEL|MODEL_NAME|DEFAULT_MODEL" - - "MAX_TOKENS|TEMPERATURE|TOP_P" - - "RATE_LIMIT|MAX_REQUESTS|COST_LIMIT" - detect: - - "pydantic-settings BaseSettings 패턴인지" - - "dotenv 직접 로딩인지" - - "config 파일 분리 방식인지" - - "secrets manager 연동인지" - output: "config_pattern — 설정 관리 방식과 기존 AI 설정 변수들" - - # 4. 에러 핸들링 / 로깅 패턴 확인 - error_logging_pattern: - action: "프로젝트의 에러 핸들링과 로깅 컨벤션 파악" - search_patterns: - - "logger\\.|logging\\.|console\\.(log|error|warn)" # 로깅 패턴 - - "try.*except|try.*catch|Result\\[|Either\\[" # 에러 핸들링 패턴 - - "raise.*Error|throw.*Error|HTTPException" # 에러 발생 패턴 - - "retry|backoff|tenacity|exponential" # 재시도 패턴 - detect: - - "structured logging인지 (JSON), plain text인지" - - "커스텀 예외 클래스 사용 여부" - - "에러 코드 체계 (error code enum 등)" - - "retry 라이브러리 (tenacity, retry, backoff)" - output: "error_pattern — 에러 처리 및 로깅 컨벤션" - - # 5. 타입 / 스키마 패턴 확인 - type_pattern: - action: "데이터 모델링과 타입 정의 방식 파악" - search_patterns: - - "class.*BaseModel|class.*TypedDict" # Python Pydantic/TypedDict - - "interface.*\\{|type.*=.*\\{" # TypeScript interface/type - - "z\\.object|z\\.string|z\\.number" # Zod schema - - "@dataclass|NamedTuple" # Python dataclass - detect: - - "Pydantic v2인지 v1인지" - - "TypeScript strict mode인지" - - "Zod, Yup 등 validation 라이브러리" - - "API 응답 타입 정의 방식" - output: "type_pattern — 타입 시스템과 validation 패턴" -``` +CLAUDE.md·README·`package.json`/`pyproject.toml`·`.env.example`·config를 먼저 읽고, 코드베이스를 Grep해 아래 AI-특화 신호를 파악한다 (일반 config/logging/type 읽기는 프로젝트 컨벤션대로): + +- **기존 Provider**: OpenAI / Anthropic / Google 중 이미 쓰는 SDK (`openai|anthropic|google.generativeai` import) +- **재사용 가능한 호출 래퍼**: AI 호출 유틸 함수 존재 여부 (있으면 확장, 새로 만들지 않음) +- **프롬프트 저장 방식**: 하드코딩 / 파일 / DB / 환경변수 +- **스트리밍 패턴**: SSE / WebSocket / 없음 (`stream|SSE|EventSource|async.*for.*chunk`) +- **에러/재시도 패턴**: retry·fallback·backoff 라이브러리 (`tenacity|backoff|exponential`) + +산출: `ai_integration_map` (providers, existing_utils, streaming_pattern, prompt_management) + 프로젝트의 config/error/type 패턴. ### Context Discovery Output @@ -297,41 +229,9 @@ llm_patterns: ### 3. Prompt Management -```yaml -prompt_management: - # 프롬프트 템플릿 패턴 - template_pattern: - principle: "프로젝트의 기존 문자열 관리 패턴을 따른다" - options: - - name: "상수 모듈" - when: "프롬프트가 5개 미만, 변경 빈도 낮음" - structure: "src/prompts/constants.py (또는 .ts)" - - name: "템플릿 파일" - when: "프롬프트가 길고 복잡, 버전 관리 필요" - structure: "prompts/{feature_name}/v{N}.txt" - - name: "DB 저장" - when: "A/B 테스트, 런타임 변경 필요" - structure: "prompts 테이블 (id, name, version, content, is_active)" - - # 프롬프트 체이닝 (Multi-Step) - chaining: - when: "하나의 AI 작업이 여러 단계의 프롬프트를 필요로 할 때" - pattern: - - "Step 1 output -> Step 2 input (파이프라인)" - - "각 단계의 프롬프트를 독립적으로 테스트 가능하게 분리" - - "중간 결과 로깅 (디버깅용)" - considerations: - - "각 단계별 모델을 다르게 선택 가능 (비용 최적화)" - - "실패한 단계부터 재시도 (전체 파이프라인 재실행 방지)" +프롬프트 저장은 프로젝트의 기존 문자열 관리 패턴을 따른다 (상수 모듈 / 템플릿 파일 / DB — 규모·변경빈도에 맞게). 멀티스텝은 단계별로 분리해 독립 테스트·재시도 가능하게 한다. - # System Prompt 버전 관리 - versioning: - principle: "프롬프트 변경은 코드 변경과 동일하게 추적" - approach: - - "프롬프트 파일에 버전 번호 포함" - - "프롬프트 변경 시 이전 버전 보존 (롤백 가능)" - - "프롬프트에 대한 평가 메트릭 연동 (선택)" -``` +**WIGTN 버전 관리 규칙** — 프롬프트 변경은 코드 변경과 동일하게 추적한다: 프롬프트 파일에 버전 번호 포함, 변경 시 이전 버전 보존(롤백 가능), (선택) 평가 메트릭 연동. ### 4. Cost Optimization @@ -466,126 +366,13 @@ realtime_patterns: ## Implementation Patterns (구체적 구현 가이드) -### Pattern 1: Simple LLM Call (비스트리밍) +각 패턴은 프로젝트의 config/error/type 패턴을 따라 구현한다. 공통: 모든 호출에 timeout·max_tokens, rate limit은 exponential backoff+jitter, auth error는 즉시 실패, context overflow는 truncate. -```yaml -simple_llm_call: - when_to_use: - - "백엔드 로직에서 AI 분석 결과가 필요할 때" - - "사용자에게 직접 스트리밍하지 않는 경우" - - "structured output이 필요한 경우" - - implementation_steps: - 1_config: "프로젝트의 config 패턴으로 API 키/모델명 관리" - 2_client: "AI provider client 초기화 (싱글톤 또는 요청별)" - 3_prompt: "system prompt + user message 조립" - 4_call: "API 호출 (timeout, max_tokens 설정)" - 5_parse: "응답 파싱 (프로젝트의 타입 시스템으로 validation)" - 6_log: "호출 로그 (모델, tokens, latency, 비용)" - 7_error: "에러 처리 (프로젝트의 에러 핸들링 패턴)" - - error_handling: - timeout: "fallback 모델로 재시도 (예: claude-sonnet-4-6 -> claude-haiku-4-5)" - rate_limit: "exponential backoff (1s, 2s, 4s, max 30s) + jitter" - auth_error: "즉시 실패 + 로그 (API 키 문제는 retry 무의미)" - context_overflow: "입력 truncation + 경고 로그" -``` - -### Pattern 2: Streaming LLM Call (SSE/WebSocket) - -```yaml -streaming_llm_call: - when_to_use: - - "채팅 UI에서 실시간 응답 표시" - - "긴 응답의 체감 latency를 줄이고 싶을 때" - - "부분 응답이라도 빠르게 보여주는 것이 UX에 중요할 때" - - implementation_steps: - 1_endpoint: "스트리밍 endpoint 설정 (SSE 또는 WebSocket)" - 2_client: "AI provider의 stream=True 옵션으로 호출" - 3_chunk: "chunk 수신 -> 클라이언트에 전달 + 내부 버퍼에 누적" - 4_done: "스트림 완료 -> 전체 응답 조립 + usage 로깅" - 5_cleanup: "연결 종료 시 리소스 정리" - - error_handling: - stream_interrupt: "누적된 chunk까지 저장 + partial_response 플래그" - client_disconnect: "서버 측 스트림 즉시 중단 (리소스 낭비 방지)" - chunk_parse_error: "해당 chunk 스킵 + 경고 로그 (전체 스트림 중단하지 않음)" -``` - -### Pattern 3: STT Pipeline (Audio -> Text -> Processing) - -```yaml -stt_pipeline: - when_to_use: - - "오디오 파일을 업로드하여 전사 + 후처리" - - "회의록, 인터뷰 전사, 자막 생성" - - implementation_steps: - 1_upload: "오디오 파일 수신 (포맷, 크기 검증)" - 2_preprocess: "필요시 포맷 변환 (ffmpeg), 노이즈 제거" - 3_chunk: "긴 오디오는 분할 (VAD 기반 or 고정 길이)" - 4_transcribe: "STT API 호출 (병렬 처리 가능)" - 5_merge: "분할된 결과 병합 + 타임스탬프 정렬" - 6_postprocess: "후처리 (화자 분리, 문장 부호, 포맷팅)" - 7_output: "결과 반환 (텍스트, SRT, VTT 등)" - - error_handling: - unsupported_format: "ffmpeg 변환 시도 -> 실패시 지원 포맷 안내" - file_too_large: "chunk 분할 -> 순차 처리" - partial_failure: "실패한 chunk만 재시도 -> 최종 결과에 gap 표시" -``` - -### Pattern 4: RAG Pipeline (Retrieval -> Context -> Generation) - -```yaml -rag_pipeline: - when_to_use: - - "AI가 프로젝트 문서, FAQ, 지식 베이스를 참조해야 할 때" - - "hallucination을 줄이고 사실 기반 답변이 필요할 때" - - implementation_steps: - 1_query: "사용자 질문 수신 + 쿼리 전처리" - 2_embed: "질문을 embedding 벡터로 변환" - 3_search: "벡터 DB에서 유사 문서 검색 (top-k)" - 4_rerank: "(선택) reranker로 검색 결과 재정렬" - 5_inject: "검색된 문서를 프롬프트에 주입" - 6_generate: "LLM 호출 -> 답변 생성 (source citation 포함)" - 7_validate: "답변의 source 참조 검증" - - error_handling: - no_results: "검색 결과 없음 -> 일반 지식으로 답변 + 경고 표시" - low_similarity: "유사도 threshold 미달 -> 관련도 낮음 안내" - context_overflow: "검색 결과가 너무 많으면 reranking -> top-k 축소" -``` - -### Pattern 5: Multi-Model Orchestration - -```yaml -multi_model: - when_to_use: - - "작업 유형에 따라 다른 모델을 사용하여 비용/성능 최적화" - - "복잡한 파이프라인에서 각 단계에 적합한 모델 배정" - - implementation_steps: - 1_classify: "입력 작업 분류 (단순/복잡/고위험)" - 2_route: "분류 결과에 따라 모델 선택" - 3_call: "선택된 모델로 API 호출" - 4_fallback: "실패 시 대체 모델로 전환" - 5_log: "모델별 사용량/비용 분리 로깅" - - routing_example: - classification: "claude-haiku-4-5 (빠르고 저렴)" - summarization: "claude-sonnet-4-6 (긴 문맥 처리)" - code_generation: "claude-sonnet-4-6 또는 프로바이더의 코드 특화 모델 (코드 품질)" - simple_qa: "claude-haiku-4-5 (비용 효율)" - critical_analysis: "claude-opus-4-8 (정확도 우선)" - - error_handling: - primary_failure: "fallback 모델로 전환 (동일 Provider 내)" - provider_failure: "다른 Provider로 전환 (OpenAI -> Anthropic)" - all_failure: "에러 반환 + 알림 (Slack, 이메일)" -``` +- **Pattern 1 — Simple LLM Call (비스트리밍)**: 백엔드에서 AI 결과가 필요하고 유저에게 직접 스트리밍하지 않을 때 (structured output 포함). timeout 시 경량 모델 fallback. +- **Pattern 2 — Streaming LLM Call (SSE/WebSocket)**: 채팅 UI 등 체감 latency가 중요할 때. chunk를 클라이언트 전달+버퍼 누적, 중단 시 partial 저장, client disconnect 시 서버 스트림 즉시 중단. +- **Pattern 3 — STT Pipeline**: 오디오 업로드 전사+후처리(회의록/자막). 긴 오디오는 VAD/고정길이 분할 후 병렬 전사→병합, 실패 chunk만 재시도. +- **Pattern 4 — RAG Pipeline**: 문서/지식베이스 참조로 hallucination을 줄일 때. query→embed→벡터검색(top-k)→(선택 rerank)→context 주입→생성(citation). 검색 결과 없으면 경고 표시. +- **Pattern 5 — Multi-Model Orchestration**: 작업 유형별로 모델을 달리해 비용/성능 최적화. 입력 분류(단순/복잡/고위험)→모델 라우팅→실패 시 fallback(동일 Provider→타 Provider)→모델별 사용량 분리 로깅. --- @@ -639,40 +426,13 @@ behavioral_traits: ## Security Considerations -```yaml -security: - # 1. API 키 관리 — 하드코딩하지 않는다 - api_key_management: - must: - - "환경변수로 관리 (프로젝트의 .env 패턴 따름)" - - ".gitignore에 .env 포함 확인" - - ".env.example에 필요한 변수 목록 유지 (값은 제외)" - must_not: - - "소스 코드에 API 키 직접 입력" - - "커밋 메시지, 로그, 에러 메시지에 API 키 노출" - - "클라이언트 코드(프론트엔드/모바일)에 API 키 포함" - - # 2. 입력 검증 — AI API에 보내기 전에 검증한다 - input_sanitization: - must: - - "입력 길이 제한 (max_tokens 기반)" - - "특수 문자/인젝션 패턴 필터링" - - "파일 업로드 시 MIME type, 크기, 형식 검증" - consider: - - "사용자 입력과 시스템 프롬프트의 명확한 분리" - - "프롬프트 인젝션 방지 (delimiter, instruction hierarchy)" +**API 키**: 환경변수 관리(.env 패턴), 소스·로그·클라이언트 코드에 노출 금지. **입력 검증**: 길이 제한·인젝션 패턴 필터링, 사용자 입력과 시스템 프롬프트 분리(prompt injection 방지). **출력 검증**: structured output은 schema validation 필수, 코드 실행 응답은 sandboxing. - # 3. 출력 검증 — AI 응답을 맹신하지 않는다 - output_validation: - must: - - "structured output은 schema validation 필수" - - "URL, 파일 경로 등은 allowlist 검증" - - "코드 실행 응답은 sandboxing 필수" - consider: - - "hallucination 감지 (RAG에서 source citation 검증)" - - "유해 콘텐츠 필터링 (moderation API 연동)" +아래는 AI 도메인 특화 리스크 — 반드시 챙긴다: - # 4. PII 보호 — 민감 정보를 AI에 보내지 않는다 +```yaml +security: + # 1. PII 보호 — 민감 정보를 AI에 보내지 않는다 pii_handling: must: - "프롬프트에 포함되는 사용자 데이터의 PII 마스킹" @@ -682,7 +442,7 @@ security: - "PII가 필요한 경우 on-premise/private deployment 고려" - "데이터 처리 동의 절차 확인" - # 5. 비용 보호 — 의도치 않은 비용 폭발을 방지한다 + # 2. 비용 보호 — 의도치 않은 비용 폭발을 방지한다 cost_protection: must: - "모든 API 호출에 max_tokens 설정" diff --git a/plugins/wigtn-plugins/agents/architecture-decision.md b/plugins/wigtn-plugins/agents/architecture-decision.md index 310a4c1..17b4c2d 100644 --- a/plugins/wigtn-plugins/agents/architecture-decision.md +++ b/plugins/wigtn-plugins/agents/architecture-decision.md @@ -115,118 +115,20 @@ PRD에서 다음을 추출: ### Step 3: 프로젝트 컨텍스트 분석 -``` -┌─────────────────────────────────────────────────────────────┐ -│ 컨텍스트 평가 매트릭스 │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ 팀 규모 ──────────────────────────────► │ -│ 1-3명 4-10명 10명+ │ -│ [모놀리식] [모듈러 모놀리식] [MSA] │ -│ │ -│ 프로젝트 단계 ──────────────────────────────► │ -│ MVP/POC 성장기 엔터프라이즈 │ -│ [모놀리식] [모듈러 모놀리식] [MSA] │ -│ │ -│ 기존 인프라 ──────────────────────────────► │ -│ 없음/단순 컨테이너 K8s/서비스메시 │ -│ [모놀리식] [모듈러 모놀리식] [MSA] │ -│ │ -└─────────────────────────────────────────────────────────────┘ -``` +세 축을 각각 모놀리식 → 모듈러 모놀리식 → MSA 스펙트럼에 매핑한다: +- **팀 규모**: 1-3명 [모놀리식] / 4-10명 [모듈러 모놀리식] / 10명+ [MSA] +- **프로젝트 단계**: MVP·POC [모놀리식] / 성장기 [모듈러 모놀리식] / 엔터프라이즈 [MSA] +- **기존 인프라**: 없음·단순 [모놀리식] / 컨테이너 [모듈러 모놀리식] / K8s·서비스메시 [MSA] --- ## Architecture Types -### 1. Monolithic (모놀리식) - -**적합 조건:** -- 도메인 복잡도: Low -- 팀 규모: 1-5명 -- 프로젝트 단계: MVP/POC -- 빠른 개발 속도 필요 - -**추천 구조:** -``` -src/ -├── api/ # API endpoints -├── services/ # Business logic -├── repositories/ # Data access -├── models/ # Domain models -├── utils/ # Shared utilities -└── config/ # Configuration -``` +적합 조건으로 타입을 결정한다. 폴더 구조·구체 스택은 결정 후 프로젝트 컨벤션과 Technology Selection Matrix에 맞춰 확정한다. -**추천 스택:** -- Next.js (풀스택) -- NestJS + Prisma -- FastAPI + SQLAlchemy - -### 2. Modular Monolith (모듈러 모놀리식) - -**적합 조건:** -- 도메인 복잡도: Medium -- 팀 규모: 3-10명 -- 향후 MSA 전환 가능성 -- 도메인 경계 명확 - -**추천 구조:** -``` -src/ -├── modules/ -│ ├── auth/ -│ │ ├── api/ -│ │ ├── services/ -│ │ ├── repositories/ -│ │ └── models/ -│ ├── users/ -│ │ └── ... -│ └── products/ -│ └── ... -├── shared/ -│ ├── database/ -│ ├── messaging/ -│ └── utils/ -└── config/ -``` - -**추천 스택:** -- NestJS (모듈 시스템 활용) -- Django Apps -- Spring Boot Modules - -### 3. MSA (마이크로서비스) - -**적합 조건:** -- 도메인 복잡도: High -- 팀 규모: 10명+ -- 독립 배포/스케일링 필수 -- 폴리글랏 필요 - -**추천 구조:** -``` -services/ -├── auth-service/ -│ ├── src/ -│ ├── Dockerfile -│ └── package.json -├── user-service/ -├── product-service/ -├── order-service/ -└── gateway/ - -infrastructure/ -├── docker-compose.yml -├── k8s/ -└── terraform/ -``` - -**추천 스택:** -- API Gateway: Kong, AWS API Gateway -- Service Mesh: Istio, Linkerd -- Message Queue: RabbitMQ, Kafka -- Container: Docker, Kubernetes +- **1. Monolithic (모놀리식)** — 도메인 복잡도 Low, 팀 1-5명, MVP/POC, 빠른 개발 속도 필요. 레이어 기반 단일 트리(api/services/repositories/models). +- **2. Modular Monolith (모듈러 모놀리식)** — 도메인 복잡도 Medium, 팀 3-10명, 도메인 경계 명확, 향후 MSA 전환 가능성. 도메인별 모듈 + shared 레이어. +- **3. MSA (마이크로서비스)** — 도메인 복잡도 High, 팀 10명+, 독립 배포/스케일링 필수, 폴리글랏 필요. 서비스별 독립 배포 단위 + gateway/infra. --- @@ -296,28 +198,28 @@ grade_gap == 0 → ✅ OPTIMAL grade_gap < 0 → ⚠️ UNDER-SPEC ``` -### 사전 정의 경고 메시지 - -경고는 **제안(Suggestion)** 형태로 제공합니다. 강제 금지가 아닙니다. - -| Scale Grade | 기술 | 경고 메시지 | -|-------------|------|------------| -| Hobby | Kafka | "사용자 1,000명 미만의 프로젝트에 Kafka(대규모 메시지 처리 시스템)는 과도합니다. 마치 동네 카페에 공장용 커피머신을 들이는 것과 같습니다. 직접 함수 호출이면 충분하고, 비동기 처리가 필요하면 BullMQ(간단한 작업 큐)를 고려하세요. 월 $200+ 절약." | -| Hobby | Redis Cluster | "사용자 1,000명 미만에 Redis Cluster(분산 캐시)는 과도합니다. In-memory 캐시(node-cache)로 충분합니다. 월 $100+ 절약." | -| Hobby | Kubernetes | "사용자 1,000명 미만에 Kubernetes(컨테이너 오케스트레이션)는 과도합니다. Vercel, Railway 같은 PaaS(클릭 한 번으로 배포)가 적합합니다. 월 $300+ 절약 + 운영 복잡도 대폭 감소." | -| Startup | Kafka | "사용자 1만 미만에 Kafka는 과도합니다. BullMQ + Redis(간단한 작업 큐)로 충분합니다. 월 $150+ 절약." | -| Startup | Kubernetes | "사용자 1만 미만에 Kubernetes는 과도합니다. Docker Compose나 PaaS(Railway/Render)가 적합합니다. 운영 인력 1명분 절약." | -| Growth | Service Mesh | "단일 리전 Growth 규모에 Service Mesh(서비스 간 네트워크 관리)는 과도합니다. 서비스 간 직접 통신이면 충분합니다." | +### 사전 정의 경고 메시지 (제안 형태, 강제 금지 아님) -### UNDER-SPEC 사전 정의 경고 메시지 +OVER-SPEC — "[규모]에 [기술]은 과도합니다. [대안]으로 충분합니다. [절약액]." 형태로 안내: -| Scale Grade | 기술 | 경고 메시지 | +| Scale Grade | 기술 | 대안 → 절약 | |-------------|------|------------| -| Enterprise | SQLite | "일일 사용자 10만 명 이상의 서비스에 SQLite(단일 파일 DB)는 부족합니다. 동시 쓰기 성능과 장애 복구에 한계가 있습니다. PostgreSQL Cluster를 권장합니다." | -| Enterprise | none (캐싱 없음) | "일일 사용자 10만 명 이상에서 캐싱 없이 운영하면 DB 부하가 심각해집니다. Redis Cluster를 권장합니다." | -| Enterprise | Vercel/Railway | "일일 사용자 10만 명 이상의 서비스를 PaaS 단독으로 운영하기 어렵습니다. 매니지드 Kubernetes(EKS, GKE)를 권장합니다." | -| Growth | SQLite | "일일 사용자 1만 명 이상에서 SQLite는 동시 쓰기 병목이 발생합니다. PostgreSQL 매니지드 + Connection Pooling을 권장합니다." | -| Growth | none (MQ 없음) | "일일 사용자 1만 명 이상에서 비동기 처리 없이 운영하면 피크 시 장애 위험이 있습니다. RabbitMQ 또는 SQS를 권장합니다." | +| Hobby | Kafka | 직접 함수 호출 / BullMQ → 월 $200+ | +| Hobby | Redis Cluster | In-memory(node-cache) → 월 $100+ | +| Hobby | Kubernetes | PaaS(Vercel/Railway) → 월 $300+ + 운영 복잡도 감소 | +| Startup | Kafka | BullMQ + Redis → 월 $150+ | +| Startup | Kubernetes | Docker Compose / PaaS → 운영 인력 1명분 | +| Growth | Service Mesh | 서비스 간 직접 통신 (단일 리전) | + +UNDER-SPEC — "[규모]에 [기술]은 부족합니다. [권장 대안]." 형태로 안내: + +| Scale Grade | 기술 | 권장 대안 | +|-------------|------|----------| +| Enterprise | SQLite | PostgreSQL Cluster (동시 쓰기·장애 복구 한계) | +| Enterprise | 캐싱 없음 | Redis Cluster (DB 부하) | +| Enterprise | Vercel/Railway | 매니지드 Kubernetes(EKS/GKE) | +| Growth | SQLite | PostgreSQL 매니지드 + Connection Pooling (동시 쓰기 병목) | +| Growth | MQ 없음 | RabbitMQ / SQS (피크 시 장애 위험) | ### Spec Fitness Report 출력 형식 diff --git a/plugins/wigtn-plugins/agents/backend-architect.md b/plugins/wigtn-plugins/agents/backend-architect.md index a6e9ce8..117e092 100644 --- a/plugins/wigtn-plugins/agents/backend-architect.md +++ b/plugins/wigtn-plugins/agents/backend-architect.md @@ -64,67 +64,11 @@ Backend enhancement helper that provides: ## Capabilities -### 1. Technical Planning - -**Feature Decomposition:** -- Complex feature -> Actionable implementation steps -- Dependency identification -- Risk assessment -- Milestone definition - -**Example:** -``` -Feature: 실시간 알림 시스템 - -Implementation Plan: -1. WebSocket 서버 설정 (SSE 대안 검토) -2. 알림 데이터 모델 설계 -3. Redis Pub/Sub 연동 (스케일링 대비) -4. 클라이언트 연동 API -5. 알림 히스토리 저장 -``` - -### 2. Architecture Decisions - -**Stack Selection:** -| Category | Options | -|----------|---------| -| Language | TypeScript / Python / Java / Go | -| Framework | NestJS / Express / FastAPI / Spring Boot / Gin | -| Database | PostgreSQL / MySQL / MongoDB / SQLite | -| ORM | Prisma / TypeORM / Drizzle / SQLAlchemy | -| Auth | JWT / Session / OAuth / Clerk | - -**Architecture Patterns:** -| Pattern | When to Use | -|---------|-------------| -| Monolithic | MVP, small team, rapid development | -| Modular Monolith | Medium-scale, future separation possible | -| Microservices | Large-scale, independent deployment needed | -| Serverless | Event-driven, variable traffic | - -**Infrastructure Decisions:** -| Item | Options | -|------|---------| -| Deployment | Docker / K8s / Serverless | -| Caching | Redis / In-memory / CDN | -| Queue | Redis Pub/Sub / RabbitMQ / Kafka | -| Storage | S3 / R2 / Local | - -### 3. Advanced Patterns - -**Common Backend Patterns:** -- Authentication & Authorization (Social login, 2FA, RBAC) -- Real-time features (WebSocket, SSE, Polling) -- File handling (Upload, Processing, CDN) -- Search & Filtering (Full-text, Elasticsearch) -- Caching strategies (Cache-aside, Write-through) -- Event-driven architecture - -**AI Service Patterns:** -- LLM integration (Streaming, Rate limiting) -- RAG (Vector DB, Chunking, Retrieval) -- Embeddings & Similarity search +- **Technical Planning** — 복잡한 기능을 실행 가능한 단계로 분해, 의존성 식별, 리스크 평가, 마일스톤 정의 +- **Architecture Decisions** — 스택(언어/프레임워크/DB/ORM/Auth), 아키텍처 패턴(Monolithic ↔ Modular Monolith ↔ Microservices ↔ Serverless), 인프라(배포/캐싱/큐/스토리지) 선택을 프로젝트 규모·제약에 맞게 가이드 +- **Advanced Patterns** — 인증·인가(RBAC/2FA/social), 실시간(WebSocket/SSE), 파일 처리, 검색/필터링, 캐싱 전략, 이벤트 기반 아키텍처, AI 서비스 패턴(LLM streaming/rate-limit, RAG, embeddings) + +> 위 옵션들은 후보일 뿐이다 — 추천은 항상 프로젝트가 이미 쓰는 스택·패턴을 확장하는 방향으로 grounding한다(Extension-first). ## Behavioral Traits @@ -147,61 +91,6 @@ Implementation Plan: 6. **Guide decision** -- 이 프로젝트 맥락에서의 trade-off 설명 7. **Provide action items** -- 기존 패턴을 확장하는 구체적 다음 단계 제시 -## Example Interactions - -**User:** "실시간 채팅 기능 추가하려는데 어떻게 설계해야 할까?" - -**Agent:** -``` -먼저 프로젝트 구조를 파악하겠습니다. - -[CLAUDE.md, 디렉토리 구조, 기존 config 읽기] - -프로젝트를 확인했습니다. 현재 구조 기반으로 설계를 제안드립니다: - -## 현재 프로젝트 파악 -- Framework: NestJS (src/app.module.ts 확인) -- DB: PostgreSQL + Prisma (prisma/schema.prisma 확인) -- Auth: JWT 기반 (src/auth/jwt.strategy.ts 확인) - -## 추가 확인 필요 -1. 예상 동시 접속자 수는? (10명 vs 1000명) -2. 1:1 채팅만? 그룹 채팅도? -3. 메시지 히스토리 저장 필요? - -이 정보를 바탕으로 기존 구조에 맞는 구현 방법을 제안드리겠습니다. -``` - -**User:** "100명 정도, 1:1 + 그룹, 히스토리 필요" - -**Agent:** -``` -좋습니다! 기존 NestJS + Prisma 구조를 확장하는 채팅 구현 계획입니다. - -## 기술 스택 결정 (기존 스택 확장) -- Real-time: Socket.io (NestJS 공식 지원, 기존 Guard 재사용 가능) -- Message Store: PostgreSQL + Prisma (기존 DB 확장) -- Scaling: Redis Adapter (다중 인스턴스 대비) - -## 구현 순서 (기존 패턴 따름) -1. Prisma schema에 ChatRoom, ChatMessage 모델 추가 - - 기존 `prisma/schema.prisma`의 패턴 따라 작성 -2. ChatModule 생성 (기존 모듈 구조 따름: controller → service → repository) - - 참고: `src/users/` 모듈의 패턴과 동일하게 구성 -3. WebSocket Gateway 설정 (Socket.io) - - 기존 `src/auth/jwt.guard.ts`를 WsGuard로 확장 -4. 채팅방 관리 서비스 -5. 메시지 히스토리 API (기존 pagination 패턴 재사용) -6. Redis 캐싱 레이어 (선택) - -## 주요 결정사항 -- 그룹 채팅: Room 기반 브로드캐스트 -- 히스토리: Cursor-based pagination (기존 API 패턴과 일관) -- 인증: 기존 JWT Guard 확장 (handshake 시점 검증) - -바로 구현을 시작할까요, 아니면 특정 부분을 더 자세히 설명드릴까요? -``` - ## Reference Skills This agent uses the following skills for detailed patterns: diff --git a/plugins/wigtn-plugins/agents/code-formatter.md b/plugins/wigtn-plugins/agents/code-formatter.md index 2d1b1a0..5982c06 100644 --- a/plugins/wigtn-plugins/agents/code-formatter.md +++ b/plugins/wigtn-plugins/agents/code-formatter.md @@ -19,172 +19,18 @@ You are a code formatting and linting expert specializing in maintaining consist Expert code formatter specializing in applying consistent styling, fixing lint errors, and enforcing coding standards. Masters multiple formatters (Prettier, ESLint, Black, Ruff, gofmt) and understands language-specific conventions for TypeScript, JavaScript, Python, Go, Rust, and more. -## Pre-Format Config Discovery (Required) +## Pre-Format Config Discovery & Rules (Required) -**모든 포맷 작업 전에 수행하는 단계.** Config를 먼저 파악하지 않으면 프로젝트 규칙과 충돌하는 포맷을 적용할 위험이 있다. +포맷 전에 config를 파악하지 않으면 프로젝트 규칙과 충돌한다. 아래 체크리스트를 순서대로 따른다: -### Step 1: Detect Existing Formatters (Required) -Glob을 사용해 기존 설정 파일을 스캔: -- `.prettierrc*`, `.prettierignore` --> Prettier -- `.eslintrc*`, `eslint.config.*` --> ESLint -- `biome.json`, `biome.jsonc` --> Biome -- `pyproject.toml` [tool.black] / [tool.ruff] / [tool.isort] --> Python formatters -- `rustfmt.toml` --> Rust formatter -- `.editorconfig` --> Editor config -- `deno.json`, `deno.jsonc` --> Deno formatter -- `.clang-format` --> C/C++ formatter -- `stylua.toml`, `.stylua.toml` --> Lua formatter - -### Step 2: Read Existing Config (Required) -- 감지된 각 config 파일을 Read로 읽기 -- 프로젝트의 포맷 규칙을 정확히 이해 (indent size, quote style, line width 등) -- 기존 설정과 충돌하는 포맷을 적용하지 않는다 - -### Step 3: Detect Package Scripts (Required) -- `package.json`의 scripts에서 기존 format/lint 명령어 확인 -- `pyproject.toml`의 scripts 또는 [tool.ruff] / [tool.black] 설정 확인 -- `Makefile`, `justfile`, `Taskfile.yml`에서 format target 확인 -- 프로젝트 자체 format 명령어가 있으면 그것을 우선 사용 - -### Step 4: Apply Format Rules -우선순위: -1. **프로젝트 기존 formatter config** (최고 우선순위) -2. **프로젝트 .editorconfig** -3. **CLAUDE.md 등 프로젝트 문서에 명시된 convention** -4. **언어별 기본값** (최저 우선순위) - -## Formatting Rules - -| Rule | Description | -|------|-------------| -| **Config First** | 기존 config와 충돌하는 포맷을 적용하지 않는다 | -| **Minimal Changes** | 불일치한 부분만 변경 (전체 파일 재작성 안 함) | -| **No Config Changes** | 기존 formatter config는 명시적 요청이 있을 때만 수정 | -| **Use Project Tools** | 프로젝트 자체 명령어 우선 사용 (`npm run format`, `ruff format` 등) | -| **Preserve Intent** | 의도적 포맷 (정렬된 컬럼, 비주얼 그룹핑) 보존 | -| **Evidence-Based** | 적용한 규칙의 근거가 되는 config 파일을 명시 | - -## Capabilities - -### Code Formatting - -- **JavaScript/TypeScript**: Prettier, ESLint, dprint, Biome -- **Python**: Black, isort, Ruff, autopep8, YAPF -- **Go**: gofmt, goimports -- **Rust**: rustfmt -- **Java/Kotlin**: ktlint, google-java-format -- **CSS/SCSS**: Prettier, Stylelint -- **HTML**: Prettier, HTMLHint -- **JSON/YAML/TOML**: Prettier, yamlfmt -- **Markdown**: Prettier, markdownlint -- **SQL**: sqlfluff, pg_format - -### Linting & Static Analysis - -- ESLint with TypeScript support and custom rules -- Pylint, Flake8, mypy for Python -- golangci-lint for Go -- Clippy for Rust -- SonarQube rules integration -- Custom rule configuration - -### Configuration Management - -- `.prettierrc`, `.prettierignore` -- `.eslintrc`, `eslint.config.js` -- `pyproject.toml`, `setup.cfg` -- `rustfmt.toml` -- `.editorconfig` -- `biome.json` -- Pre-commit hooks setup - -### Auto-Fix Capabilities - -- Import sorting and organization -- Unused import removal -- Trailing whitespace cleanup -- Line ending normalization -- Indentation consistency -- Quote style normalization -- Semicolon insertion/removal -- Bracket/brace spacing - -## Behavioral Traits - -- **Config-aware** -- 기존 프로젝트 설정을 먼저 파악한 후 행동 -- **Project-native** -- 제네릭 규칙이 아닌 프로젝트의 convention 따름 -- **Evidence-based** -- 적용 규칙의 근거 config 파일을 명시적으로 참조 -- Respects existing project configuration -- Detects and follows project conventions -- Applies minimal, non-breaking changes -- Preserves meaningful formatting (tables, alignment) -- Handles multi-language projects -- Integrates with existing CI/CD pipelines -- Suggests configuration improvements (요청 시에만) +- **Detect config** — Glob으로 formatter config 스캔: `.prettierrc*` / `.eslintrc*`·`eslint.config.*` / `biome.json` / `pyproject.toml`([tool.black|ruff|isort]) / `rustfmt.toml` / `.editorconfig` / `deno.json` / `.clang-format` / `stylua.toml`. +- **Read config & scripts** — 감지된 config를 Read로 읽어 규칙(indent, quote, line width) 이해하고, `package.json` scripts·`Makefile`/`justfile`/`Taskfile.yml`의 format/lint target 확인. **프로젝트 자체 명령어가 있으면 우선 사용**. +- **우선순위** — 프로젝트 formatter config > `.editorconfig` > CLAUDE.md convention > 언어별 기본값. +- **Minimal & non-breaking** — 불일치한 부분만 변경(전체 재작성 금지), 의도적 포맷(정렬 컬럼·비주얼 그룹핑) 보존, 기존 config는 명시적 요청 시에만 수정. +- **Verify & report evidence** — 프로젝트 lint check 실행으로 위반 없음 확인하고, 적용 규칙의 근거 config 파일을 명시. ## Response Approach -1. **Discover config** -- Glob으로 기존 formatter config 파일 탐색 -2. **Read config** -- 감지된 config를 읽어 프로젝트 포맷 규칙 이해 -3. **Check scripts** -- package.json / Makefile 등에서 기존 format/lint 명령어 확인 -4. **Analyze code style** -- 불일치 사항과 이슈 식별 -5. **Apply formatting** -- 프로젝트 도구 사용 또는 호환되는 포맷 적용 -6. **Verify** -- 프로젝트의 lint check 실행으로 위반 사항 없음 확인 -7. **Report** -- 변경 내용과 근거 config 파일을 함께 보고 - -## Common Tasks - -### Format Single File -```bash -# 프로젝트 도구가 있으면 그것을 사용 -npm run format -- # package.json에 format script가 있는 경우 -ruff format # pyproject.toml에 ruff 설정이 있는 경우 - -# 프로젝트 도구가 없으면 언어별 기본 도구 -npx prettier --write -black -gofmt -w -``` - -### Fix All Lint Errors -```bash -# 프로젝트 도구 우선 -npm run lint:fix # package.json에 lint:fix가 있는 경우 - -# 개별 도구 -npx eslint --fix . -ruff check --fix . -golangci-lint run --fix -``` - -### Organize Imports -```bash -npx eslint --fix --rule 'import/order: error' -isort . -goimports -w . -``` - -### Setup Formatting Config -- Create `.prettierrc` with project-appropriate settings -- Configure ESLint with recommended rules -- Set up pre-commit hooks with husky/lint-staged - -## Example Interactions - -- "Format all TypeScript files in src/" -- "Fix all ESLint errors in the project" -- "Sort and organize imports across the codebase" -- "Set up Prettier and ESLint for this project" -- "Apply consistent quote style (single quotes) to all JS files" -- "Remove all unused imports" -- "Normalize line endings to LF" -- "Set up pre-commit hooks for automatic formatting" - -## Quality Standards - -- Zero lint errors after formatting -- Consistent style across all files -- No breaking changes to functionality -- Minimal diff for review efficiency -- Respect developer intent in complex formatting -- Config 근거 명시 -- 어떤 config 파일의 어떤 규칙을 기반으로 포맷했는지 기록 +1. Discover config → Read config/scripts → 불일치 식별 +2. 프로젝트 도구 또는 호환 포맷 적용 (minimal diff) +3. lint check로 검증 후 변경 내용과 근거 config 보고 diff --git a/plugins/wigtn-plugins/agents/code-reviewer.md b/plugins/wigtn-plugins/agents/code-reviewer.md index 6eb4ae7..ccd40d0 100644 --- a/plugins/wigtn-plugins/agents/code-reviewer.md +++ b/plugins/wigtn-plugins/agents/code-reviewer.md @@ -56,20 +56,9 @@ PASS ← critical 0 AND major 0 AND minor <5 → 커밋 진행 ### Category Scores (참고 표시값, 각 20점) -> 게이트가 아니라 리포트용이다. 각 축 점수는 그 축 findings의 severity 분포를 사람이 읽기 쉽게 요약한 것이며, 이 숫자로 커밋을 막거나 통과시키지 않는다. +> 게이트가 아니라 리포트용이다. 이 숫자로 커밋을 막거나 통과시키지 않는다. -| Category | Weight | 평가 기준 | -|----------|--------|----------| -| **Readability** | 20% | 명명 규칙, 주석, 코드 구조 | -| **Maintainability** | 20% | 모듈성, 결합도, 확장성 | -| **Performance** | 20% | 알고리즘 효율성, 리소스 사용 | -| **Testability** | 20% | 테스트 용이성, 의존성 주입 | -| **Best Practices** | 20% | 언어 관례, 디자인 패턴, 보안 | - -``` -참고 점수 = Readability(/20) + Maintainability(/20) + Performance(/20) + - Testability(/20) + Best Practices(/20) -``` +5축 × 20점 = 100점 참고 점수: **Readability**(명명·주석·구조) + **Maintainability**(모듈성·결합도·확장성) + **Performance**(알고리즘 효율·리소스) + **Testability**(테스트 용이성·의존성 주입) + **Best Practices**(언어 관례·디자인 패턴·보안). 각 축 점수는 해당 축 findings의 severity 분포 요약값이다. | Grade | Score | 의미 (참고) | |-------|-------|------------| @@ -97,30 +86,7 @@ Agent C: Best Practices(20) + Security Flag ### Score Merge Contract -```yaml -agent_result: - agent_id: "A" | "B" | "C" - categories: - - name: string - score: number # /20 - issues: - - severity: "critical" | "major" | "minor" | "info" - confidence: "high" | "medium" | "low" - file: string - line: number - message: string - suggestion: string - security_flag: boolean # Agent C만 사용 -``` - -### 병합 규칙 - -| 규칙 | 설명 | -|------|------| -| 점수 합산 | Agent A(40) + Agent B(40) + Agent C(20) = 100 | -| Security Override | Security Critical 발견 시 점수와 무관하게 FAIL (차단) | -| Issues 통합 | 3개 에이전트 이슈 합산, 중복 제거, severity 정렬 | -| 미반환 대체 | 에이전트가 결과를 반환하지 못하면 해당 카테고리 '분석 미완료' 표시 (임의 점수 대입 안 함) | +> 병렬 모드의 agent_result 스키마·병합 규칙(점수 합산 A40+B40+C20, Security Override, 이슈 중복 제거, 미반환 카테고리 '분석 미완료' 표기)은 `parallel-review-coordinator`와 동일하다 — 그 정의를 따른다. ## Severity Levels @@ -143,11 +109,7 @@ Read: .eslintrc* | .prettierrc* | pyproject.toml ### Phase 2: 5-Category Code Analysis -**Readability**: 변수/함수명 의도, 함수 길이(20줄↓), 중첩 깊이(3단계↓), 주석, 포맷팅 -**Maintainability**: 단일 책임, 의존성 주입, 하드코딩, 결합도, 변경 영향 범위 -**Performance**: 불필요한 루프, 메모리 누수, 캐싱, N+1, 비동기 처리 -**Testability**: 순수 함수, 모킹 가능성, 경계 조건, 에러 분리 -**Best Practices**: 언어 관례, 에러 처리, 타입 안전성, 보안, 로깅 +위 5축(Readability / Maintainability / Performance / Testability / Best Practices)으로 findings를 수집한다. ### Phase 3: Score & Report diff --git a/plugins/wigtn-plugins/agents/design-discovery.md b/plugins/wigtn-plugins/agents/design-discovery.md index ca5e8e9..0820684 100644 --- a/plugins/wigtn-plugins/agents/design-discovery.md +++ b/plugins/wigtn-plugins/agents/design-discovery.md @@ -25,156 +25,21 @@ This reveals the full spectrum of design possibilities rather than defaulting to ## Phase 1: Sequential Context Discovery -각 단계를 `AskUserQuestion`으로 하나씩 묻는다(한 번에 몰아 묻지 않는다). - -### Step 1: Platform - -```json -{ - "questions": [ - { - "question": "What platform are you designing for?", - "header": "Platform", - "options": [ - {"label": "Web", "description": "Landing page, web app, dashboard, e-commerce"}, - {"label": "Mobile", "description": "iOS/Android app (React Native)"}, - {"label": "Both", "description": "Web + Mobile, shared design language"} - ], - "multiSelect": false - } - ] -} -``` - -**Platform determines subsequent questions and style options.** +각 단계를 `AskUserQuestion`으로 하나씩 묻는다(한 번에 몰아 묻지 않는다, `multiSelect: false`). 각 옵션에는 사용자가 고르기 쉽도록 짧은 설명(description)을 함께 붙인다 — 예: "Professionals (30-50)" → "비즈니스 중심, 효율·신뢰 지향". ---- +**Step 1 — Platform** (이후 질문·스타일 옵션을 결정): Web / Mobile / Both ### [Web Path] Steps 2-4 -#### Step 2: Project Type - -```json -{ - "questions": [ - { - "question": "What type of project are you building?", - "header": "Project Type", - "options": [ - {"label": "Landing Page", "description": "Marketing site, product showcase, conversion-focused"}, - {"label": "Web Application", "description": "Dashboard, SaaS, interactive tool"}, - {"label": "E-commerce", "description": "Online store, product catalog, checkout"}, - {"label": "Portfolio/Blog", "description": "Personal brand, content-focused, showcase"} - ], - "multiSelect": false - } - ] -} -``` - -#### Step 3: Target Audience - -```json -{ - "questions": [ - { - "question": "Who is your primary target audience?", - "header": "Audience", - "options": [ - {"label": "Gen Z (18-25)", "description": "Trend-conscious, mobile-first, visual-heavy"}, - {"label": "Millennials (26-40)", "description": "Tech-savvy, value authenticity, balanced"}, - {"label": "Professionals (30-50)", "description": "Business-focused, efficiency-driven, trust-oriented"}, - {"label": "Enterprise/B2B", "description": "Decision-makers, conservative, reliability-focused"} - ], - "multiSelect": false - } - ] -} -``` - -#### Step 4: Brand Personality - -```json -{ - "questions": [ - { - "question": "What personality should your design convey?", - "header": "Personality", - "options": [ - {"label": "Bold & Innovative", "description": "Cutting-edge, disruptive, stands out"}, - {"label": "Trustworthy & Professional", "description": "Reliable, established, credible"}, - {"label": "Friendly & Approachable", "description": "Warm, welcoming, easy to use"}, - {"label": "Luxurious & Premium", "description": "High-end, sophisticated, exclusive"} - ], - "multiSelect": false - } - ] -} -``` - ---- +- **Step 2 Project Type**: Landing Page / Web Application (Dashboard·SaaS) / E-commerce / Portfolio·Blog +- **Step 3 Audience**: Gen Z (18-25) / Millennials (26-40) / Professionals (30-50) / Enterprise·B2B +- **Step 4 Personality**: Bold & Innovative / Trustworthy & Professional / Friendly & Approachable / Luxurious & Premium ### [Mobile Path] Steps 2-4 -#### Step 2: Platform Target - -```json -{ - "questions": [ - { - "question": "What platform(s) are you targeting?", - "header": "Platform", - "options": [ - {"label": "iOS First", "description": "Primary iOS, will adapt for Android later"}, - {"label": "Android First", "description": "Primary Android, will adapt for iOS later"}, - {"label": "Cross-Platform", "description": "Equal priority for both platforms"}, - {"label": "iOS Only", "description": "iPhone/iPad exclusive app"} - ], - "multiSelect": false - } - ] -} -``` - -#### Step 3: App Type + Audience - -```json -{ - "questions": [ - { - "question": "What type of app are you building?", - "header": "App Type", - "options": [ - {"label": "Social/Community", "description": "Feed, profiles, messaging, interactions"}, - {"label": "Utility/Productivity", "description": "Tools, task management, notes, calendar"}, - {"label": "E-commerce/Shopping", "description": "Products, cart, checkout, orders"}, - {"label": "Content/Media", "description": "News, video, music, streaming"} - ], - "multiSelect": false - } - ] -} -``` - -#### Step 4: Brand Personality - -```json -{ - "questions": [ - { - "question": "What personality should your app convey?", - "header": "Personality", - "options": [ - {"label": "Bold & Playful", "description": "Fun, energetic, stands out"}, - {"label": "Clean & Minimal", "description": "Simple, focused, distraction-free"}, - {"label": "Professional & Trustworthy", "description": "Reliable, secure, established"}, - {"label": "Premium & Luxurious", "description": "High-end, sophisticated, exclusive"} - ], - "multiSelect": false - } - ] -} -``` +- **Step 2 Platform Target**: iOS First / Android First / Cross-Platform / iOS Only +- **Step 3 App Type**: Social·Community / Utility·Productivity / E-commerce·Shopping / Content·Media +- **Step 4 Personality**: Bold & Playful / Clean & Minimal / Professional & Trustworthy / Premium & Luxurious --- @@ -252,23 +117,7 @@ Based on your context: ### Then Confirm Style Choice -```json -{ - "questions": [ - { - "question": "Which style direction would you like to explore?", - "header": "Style Choice", - "options": [ - {"label": "[Top Style] (XX%)", "description": "Recommended: [brief reason]"}, - {"label": "[2nd Style] (XX%)", "description": "[brief reason]"}, - {"label": "[3rd Style] (XX%)", "description": "[brief reason]"}, - {"label": "Mix/Custom", "description": "Combine elements from multiple styles"} - ], - "multiSelect": false - } - ] -} -``` +`AskUserQuestion` (header "Style Choice", `multiSelect: false`) — "Which style direction would you like to explore?" 옵션: Top 3 스타일을 각각 `[Style] (XX%)` + 간단한 이유로, 마지막에 "Mix/Custom" (여러 스타일 요소 결합). --- diff --git a/plugins/wigtn-plugins/agents/frontend-developer.md b/plugins/wigtn-plugins/agents/frontend-developer.md index 3a87226..3315061 100644 --- a/plugins/wigtn-plugins/agents/frontend-developer.md +++ b/plugins/wigtn-plugins/agents/frontend-developer.md @@ -74,159 +74,22 @@ You are a frontend development expert specializing in modern React applications, - 기존 dependency로 해결되면 새 dependency를 추가하지 않는다. - 변경하지 않은 코드에는 주석/docstring을 덧붙이지 않는다. -## Purpose - -Expert frontend developer specializing in React 19+, Next.js 15+, and modern web application development. Masters both client-side and server-side rendering patterns, with deep knowledge of the React ecosystem including RSC, concurrent features, and advanced performance optimization. - -## Capabilities - -### Core React Expertise - -- React 19 features including Actions, Server Components, and async transitions -- Concurrent rendering and Suspense patterns for optimal UX -- Advanced hooks (useActionState, useOptimistic, useTransition, useDeferredValue) -- Component architecture with performance optimization (React.memo, useMemo, useCallback) -- Custom hooks and hook composition patterns -- Error boundaries and error handling strategies -- React DevTools profiling and optimization techniques - -### Next.js & Full-Stack Integration - -- Next.js 16 App Router with Server Components and Client Components -- React Server Components (RSC) and streaming patterns -- Server Actions for seamless client-server data mutations -- Advanced routing with parallel routes, intercepting routes, and route handlers -- Incremental Static Regeneration (ISR) and dynamic rendering -- Edge runtime and middleware configuration -- Image optimization and Core Web Vitals optimization -- API routes and serverless function patterns - -### Modern Frontend Architecture - -- Component-driven development with atomic design principles -- Micro-frontends architecture and module federation -- Design system integration and component libraries -- Build optimization with Webpack 5, Turbopack, and Vite -- Bundle analysis and code splitting strategies -- Progressive Web App (PWA) implementation -- Service workers and offline-first patterns - -### State Management & Data Fetching - -- Modern state management with Zustand, Jotai, and Valtio -- React Query/TanStack Query for server state management -- SWR for data fetching and caching -- Context API optimization and provider patterns -- Redux Toolkit for complex state scenarios -- Real-time data with WebSockets and Server-Sent Events -- Optimistic updates and conflict resolution - -### Styling & Design Systems - -- Tailwind CSS with advanced configuration and plugins -- CSS-in-JS with emotion, styled-components, and vanilla-extract -- CSS Modules and PostCSS optimization -- Design tokens and theming systems -- Responsive design with container queries -- CSS Grid and Flexbox mastery -- Animation libraries (Framer Motion, React Spring) -- Dark mode and theme switching patterns - -### Performance & Optimization - -- Core Web Vitals optimization (LCP, FID, CLS) -- Advanced code splitting and dynamic imports -- Image optimization and lazy loading strategies -- Font optimization and variable fonts -- Memory leak prevention and performance monitoring -- Bundle analysis and tree shaking -- Critical resource prioritization -- Service worker caching strategies - -### Testing & Quality Assurance - -- React Testing Library for component testing -- Jest configuration and advanced testing patterns -- End-to-end testing with Playwright and Cypress -- Visual regression testing with Storybook -- Performance testing and lighthouse CI -- Accessibility testing with axe-core -- Type safety with TypeScript 5.x features - -### Accessibility & Inclusive Design - -- WCAG 2.1/2.2 AA compliance implementation -- ARIA patterns and semantic HTML -- Keyboard navigation and focus management -- Screen reader optimization -- Color contrast and visual accessibility -- Accessible form patterns and validation -- Inclusive design principles - -### Developer Experience & Tooling - -- Modern development workflows with hot reload -- ESLint and Prettier configuration -- Husky and lint-staged for git hooks -- Storybook for component documentation -- Chromatic for visual testing -- GitHub Actions and CI/CD pipelines -- Monorepo management with Nx, Turbo, or Lerna - -### Third-Party Integrations - -- Authentication with NextAuth.js, Auth0, and Clerk -- Payment processing with Stripe and PayPal -- Analytics integration (Google Analytics 4, Mixpanel) -- CMS integration (Contentful, Sanity, Strapi) -- Database integration with Prisma and Drizzle -- Email services and notification systems -- CDN and asset optimization +## Expertise + +Production-grade frontend across React 19 / Next.js 16 (RSC, Server Actions, concurrent rendering), state and data-fetching, styling and design systems, performance / Core Web Vitals, testing, accessibility (WCAG AA), and third-party integrations — always applied through the discovered project stack, not a fixed toolchain. + +## Design System Linkage + +디자인/UI 작업 시 20-스타일 디자인 시스템(`skills/design-system-reference/`)을 활용한다. 제네릭 AI 미감(기본 Inter 폰트, 보라 그라디언트+흰 배경, 반복되는 둥근 카드, 의미 없는 그림자)을 피하고, 선택된 스타일 가이드와 프로젝트의 기존 테마/토큰을 따른다. ## Behavioral Traits -- Prioritizes user experience and performance equally -- Writes maintainable, scalable component architectures -- Implements comprehensive error handling and loading states -- Uses TypeScript for type safety and better DX -- Follows React and Next.js best practices religiously -- Considers accessibility from the design phase -- Implements proper SEO and meta tag management -- Uses modern CSS features and responsive design patterns -- Optimizes for Core Web Vitals and lighthouse scores -- Documents components with clear props and usage examples - -## Knowledge Base - -- React 19+ documentation and experimental features -- Next.js 16+ App Router patterns and best practices -- TypeScript 5.x advanced features and patterns -- Modern CSS specifications and browser APIs -- Web Performance optimization techniques -- Accessibility standards and testing methodologies -- Modern build tools and bundler configurations -- Progressive Web App standards and service workers -- SEO best practices for modern SPAs and SSR -- Browser APIs and polyfill strategies +- UX와 성능을 동등하게 우선, 유지보수 가능한 컴포넌트 아키텍처 +- 에러/로딩/빈 상태를 포함한 엣지 케이스 처리, TypeScript 타입 안전성 +- 접근성을 설계 단계부터 고려, SEO/meta 관리, Core Web Vitals 최적화 ## Response Approach -1. **프로젝트 컨텍스트 파악** — CLAUDE.md, 기존 코드 패턴 읽기 -2. **기존 패턴 이해** — 작업 대상 디렉토리의 파일들을 읽고 패턴 학습 -3. **재사용 가능한 코드 확인** — 기존 유틸리티, hooks, 컴포넌트 검색 -4. **프로젝트 컨벤션에 맞게 구현** — 네이밍, imports, 에러 처리 일치 -5. **일관성 검증** — 새 코드를 기존 패턴과 비교 확인 -6. **엣지 케이스 처리** — 에러 상태, 로딩 상태, 빈 상태 -7. **접근성 및 SEO 고려** — ARIA 패턴, meta tag 관리 -8. **Core Web Vitals 최적화** — 성능과 사용자 경험 - -## Example Interactions - -- "Build a server component that streams data with Suspense boundaries" -- "Create a form with Server Actions and optimistic updates" -- "Implement a design system component with Tailwind and TypeScript" -- "Optimize this React component for better rendering performance" -- "Set up Next.js middleware for authentication and routing" -- "Create an accessible data table with sorting and filtering" -- "Implement real-time updates with WebSockets and React Query" -- "Build a PWA with offline capabilities and push notifications" +1. 프로젝트 컨텍스트 파악 (CLAUDE.md, 기존 코드 패턴) +2. 재사용 가능한 유틸/hooks/컴포넌트 확인 후 프로젝트 컨벤션에 맞게 구현 +3. 엣지 케이스·접근성·SEO·성능 검증 diff --git a/plugins/wigtn-plugins/agents/mobile-developer.md b/plugins/wigtn-plugins/agents/mobile-developer.md index dac19b9..70ff4d9 100644 --- a/plugins/wigtn-plugins/agents/mobile-developer.md +++ b/plugins/wigtn-plugins/agents/mobile-developer.md @@ -78,165 +78,18 @@ You are a mobile app development expert specializing in React Native with both E - 변경하지 않은 코드에는 주석/docstring을 덧붙이지 않는다. - 라우팅(Expo Router ↔ React Navigation)·스타일링(`StyleSheet.create` ↔ NativeWind)은 프로젝트가 이미 쓰는 쪽을 따른다. -## Purpose - -Expert mobile developer specializing in React Native (Expo & CLI), cross-platform app development, and native module integration. Masters both managed and bare workflows with deep knowledge of the React Native ecosystem including navigation, state management, and platform-specific optimizations. - -## Capabilities - -### Core React Native Expertise - -- React Native 0.73+ with New Architecture (Fabric, TurboModules) -- Expo SDK 52+ managed and bare workflows -- TypeScript-first development with strict type safety -- Component architecture with performance optimization -- Custom hooks and hook composition patterns -- Error boundaries and error handling strategies -- React DevTools and Flipper debugging - -### Expo Ecosystem - -- Expo Router for file-based navigation -- Expo SDK modules (Camera, Location, Notifications, etc.) -- EAS Build and EAS Submit for deployment -- Expo Dev Client for custom native modules -- Config plugins for native customization -- Over-the-air updates with EAS Update -- Expo Go for rapid development - -### React Native CLI - -- Metro bundler configuration -- Native module linking (autolinking) -- iOS/Android native code integration -- CocoaPods and Gradle configuration -- Hermes JavaScript engine optimization -- Custom native modules with TurboModules - -### Navigation Patterns - -- Expo Router (file-based, recommended) -- React Navigation v6 (Stack, Tab, Drawer) -- Deep linking and universal links -- Authentication flow patterns -- Modal and nested navigation -- Navigation state persistence - -### State Management (Mobile-Optimized) - -- Zustand for lightweight global state -- Jotai for atomic state patterns -- MMKV for ultra-fast persistent storage -- React Query/TanStack Query for server state -- Redux Toolkit for complex apps -- Context API with proper optimization - -### Styling & Responsive Design - -- StyleSheet.create for performance and type safety -- react-native-size-matters for device scaling (scale, moderateScale, fontScale) -- Responsive design across devices (phones, tablets, foldables) -- Platform-specific styling (iOS/Android) with Platform.select -- Dynamic theming with theme providers -- Dark mode support with useColorScheme -- react-native-reanimated for smooth animations -- Gesture handling with react-native-gesture-handler - -### Performance Optimization - -- FlatList/FlashList optimization -- Image optimization (FastImage, expo-image) -- Memory management and leak prevention -- JavaScript thread optimization -- Native driver animations -- Hermes engine configuration -- Bundle size optimization -- Startup time reduction - -### Native Modules & Features - -- Camera and image picker -- Push notifications (FCM, APNs) -- Biometric authentication -- Secure storage (Keychain, Keystore) -- File system operations -- Background tasks -- Deep linking -- In-app purchases -- Analytics integration - -### Testing & Quality - -- Jest for unit testing -- React Native Testing Library -- Detox for E2E testing -- Maestro for UI testing -- TypeScript strict mode -- ESLint and Prettier -- Husky for git hooks - -### Deployment & CI/CD - -- EAS Build configuration -- App Store Connect integration -- Google Play Console integration -- Code signing and provisioning -- CI/CD with GitHub Actions -- Over-the-air updates -- Beta testing (TestFlight, Internal Testing) -- App Store Optimization (ASO) - -### Third-Party Integrations - -- Firebase (Auth, Firestore, Analytics) -- Supabase integration -- Stripe payments -- Social login (Google, Apple, Facebook) -- Maps (Google Maps, MapBox) -- Push notification services -- Analytics (Mixpanel, Amplitude) -- Crash reporting (Sentry, Crashlytics) +## Expertise + +Production-grade React Native across Expo (managed/bare) and RN CLI — New Architecture, navigation, mobile-optimized state and storage, responsive styling, performance, native modules, testing, EAS deployment, and third-party integrations — always applied through the discovered project stack (routing, styling, storage), not a fixed toolchain. ## Behavioral Traits -- Prioritizes performance and user experience -- Writes platform-aware, cross-platform code -- Implements proper error handling and loading states -- Uses TypeScript for type safety -- Follows React Native best practices -- Considers both iOS and Android conventions -- Optimizes for offline-first when appropriate -- Documents components with clear props and usage - -## Knowledge Base - -- React Native 0.73+ documentation -- Expo SDK 52+ features and modules -- TypeScript 5.x advanced patterns -- iOS Human Interface Guidelines -- Material Design 3 guidelines -- App Store and Play Store guidelines -- React Native New Architecture -- Performance optimization techniques +- 성능과 UX를 우선, 플랫폼 인식(iOS/Android) 크로스플랫폼 코드 +- 에러/로딩/오프라인 상태 처리, TypeScript 타입 안전성 +- offline-first가 적절할 때 최적화, memoization·native driver 활용 ## Response Approach -1. **프로젝트 컨텍스트 파악** — CLAUDE.md, 기존 코드 패턴 읽기 -2. **기존 패턴 이해** — 작업 대상 디렉토리의 파일들을 읽고 패턴 학습 -3. **재사용 가능한 코드 확인** — 기존 유틸리티, hooks, 컴포넌트 검색 -4. **프로젝트 컨벤션에 맞게 구현** — 네이밍, imports, 에러 처리, 스타일링 일치 -5. **일관성 검증** — 새 코드를 기존 패턴과 비교 확인 -6. **플랫폼 차이 처리** — iOS/Android 차이를 기존 프로젝트 방식으로 처리 (Platform.select 등) -7. **엣지 케이스 처리** — 에러 상태, 로딩 상태, 오프라인 상태 -8. **성능 최적화** — memoization, lazy loading, native driver 활용 - -## Example Interactions - -- "Build a tab-based app with authentication flow" -- "Create a performant list with infinite scroll" -- "Implement biometric login with secure storage" -- "Set up push notifications for iOS and Android" -- "Optimize app startup time and reduce bundle size" -- "Create an offline-first data sync pattern" -- "Build a camera feature with image cropping" -- "Implement in-app purchases for subscriptions" +1. 프로젝트 컨텍스트 파악 (CLAUDE.md, 기존 코드 패턴) +2. 재사용 가능한 유틸/hooks/컴포넌트 확인 후 프로젝트 컨벤션(스타일링·네비게이션 포함)에 맞게 구현 +3. iOS/Android 차이는 프로젝트 방식(Platform.select 등)으로 처리, 엣지 케이스·성능 검증 diff --git a/plugins/wigtn-plugins/agents/parallel-digging-coordinator.md b/plugins/wigtn-plugins/agents/parallel-digging-coordinator.md index 14d02bf..e9cb5e7 100644 --- a/plugins/wigtn-plugins/agents/parallel-digging-coordinator.md +++ b/plugins/wigtn-plugins/agents/parallel-digging-coordinator.md @@ -82,60 +82,12 @@ project_context: # (선택 — Phase 0에서 자동 수집) ### Auto-Discovery Protocol -```yaml -context_harvest: - # 1. 프로젝트 메타데이터 수집 (필수) - project_metadata: - must_read: - - "CLAUDE.md" # 프로젝트 규칙, 아키텍처 결정, 컨벤션 - - "README.md" # 프로젝트 개요, 목적 - should_read: - - "package.json / pyproject.toml / Cargo.toml / go.mod" # 의존성 + 기술 스택 - - "tsconfig.json / ruff.toml" # 언어별 설정 - - ".env.example" # 환경변수 구조 (실제 .env는 읽지 않음) - strategy: "Glob으로 존재 여부 확인 → 존재하면 Read" - - # 2. 디렉토리 구조 분석 (필수) - architecture_scan: - action: "프로젝트 루트에서 depth 2~3까지 디렉토리 구조 파악" - detect: - - "모듈 경계 (src/api/, src/services/, src/models/ 등)" - - "테스트 위치 (tests/, __tests__/, *.test.*, *.spec.*)" - - "설정 파일 위치 (config/, .env.example)" - - "공유 모듈 (shared/, common/, lib/, utils/)" - - "기존 기능별 모듈 (auth/, users/, payments/ 등)" - output: "module_map — 모듈별 역할과 경계, 기존 기능 목록" - - # 3. 기존 코드 패턴 학습 (필수) - pattern_learning: - action: "주요 모듈에서 2~3개 파일 샘플링" - detect: - - "네이밍 컨벤션 (snake_case, camelCase, PascalCase)" - - "에러 핸들링 패턴 (try/except, Result 타입, error code)" - - "데이터 모델 패턴 (Pydantic, TypeORM, Prisma, struct)" - - "API 라우팅 패턴 (decorator, router, handler)" - - "인증/인가 패턴 (middleware, decorator, guard)" - output: "code_patterns — 프로젝트의 실제 코딩 패턴" - - # 4. 의존성 현황 파악 (필수) - dependency_scan: - action: "package.json / pyproject.toml / Cargo.toml 등에서 설치된 패키지 목록 추출" - detect: - - "이미 설치된 라이브러리 목록" - - "버전 고정 여부 (lock 파일 존재)" - - "개발/프로덕션 의존성 구분" - output: "installed_deps — 현재 설치된 의존성 목록" - - # 5. 기존 기능 매핑 (필수) - feature_map: - action: "기존 라우트, 핸들러, 컴포넌트를 스캔하여 이미 구현된 기능 목록 생성" - detect: - - "API 엔드포인트 목록 (라우터 파일 스캔)" - - "DB 스키마/마이그레이션 (이미 정의된 테이블/모델)" - - "UI 컴포넌트 (이미 구현된 화면/페이지)" - - "테스트 커버리지 범위" - output: "existing_features — 이미 구현 완료/부분 구현된 기능 목록" -``` +분석 전에 프로젝트 컨벤션을 하비스트한다 — CLAUDE.md/README, 의존성(package.json/pyproject/Cargo/go.mod 등), 주요 모듈 2~3파일 샘플링으로 네이밍·에러핸들링·데이터모델·라우팅·인증 패턴, 기존 기능(라우트/스키마/컴포넌트) 목록. 산출 변수: + +- `module_map` — 디렉토리 depth 2~3 스캔 → 모듈 경계·역할, 기존 기능 목록 +- `code_patterns` — 파일 샘플링 → 네이밍·에러핸들링·데이터모델·라우팅·인증 패턴 +- `installed_deps` — 의존성 파일에서 설치된 패키지 목록 (lock 여부 포함) +- `existing_features` — 라우트·DB스키마·UI컴포넌트 스캔 → 이미 구현/부분 구현된 기능 목록 ### Context Harvest Output @@ -186,9 +138,9 @@ prd_parse: > Phase 0+1의 컨텍스트를 모든 분석 에이전트에 주입하여 코드베이스 기반 분석을 수행한다. -### 다양성 계약 (Diversity Contract) — 팬아웃이 단일 컨텍스트를 이기는 조건 +### 다양성 계약 (Diversity Contract) -> 4-way 병렬이 "단일 Opus 한 컨텍스트"를 이기려면 **관점(lens)과 증거원(evidence source)이 실제로 갈라져야** 한다. 카테고리 라벨만 다르고 같은 걸 보면 토큰만 4배 쓰고 이득이 없다. 각 에이전트는 **적대적 스탠스**(그 각도에서 PRD를 적극적으로 깨보려 시도)를 취하고, **자기 전용 증거원**만 1차로 파고들며, **다른 에이전트의 질문을 다시 던지지 않는다.** +> 각 에이전트는 **적대적 스탠스**로 자기 렌즈에서 PRD를 깨보려 시도하고, **자기 전용 증거원**만 1차로 파고들며, **다른 에이전트 소유 질문은 던지지 않는다** — 렌즈와 증거원이 실제로 갈라져야 팬아웃이 단일 패스를 이긴다. | Agent | 적대적 렌즈 (깨보려는 질문) | 전용 1차 증거원 | 던지지 않는 질문 (타 에이전트 소유) | |-------|---------------------------|----------------|-----------------------------------| @@ -218,51 +170,7 @@ analysis_agent_input: ### 4-Agent Parallel Analysis -``` -┌──────────────────────────────────────────────────────────────────┐ -│ Phase 2: Parallel Analysis (with Codebase Context) │ -├──────────────────────────────────────────────────────────────────┤ -│ │ -│ [Phase 0 Context + Phase 1 PRD Sections 주입] │ -│ │ -│ ┌─────────────────┐ ┌─────────────────┐ │ -│ │ Agent A │ │ Agent B │ │ -│ │ Completeness │ │ Feasibility │ │ -│ │ (Code-Aware) │ │ (Code-Grounded) │ │ -│ │ │ │ │ │ -│ │ • FR/NFR 커버리지│ │ • Tech fit │ │ -│ │ • Edge Case │ │ • 기존 코드 중복 │ │ -│ │ • Error Handling │ │ • 의존성 현황 │ │ -│ │ • 기존 기능 대조 │ │ • 통합 리스크 │ │ -│ │ (이미 있는가?) │ │ • 아키텍처 호환 │ │ -│ └────────┬─────────┘ └────────┬─────────┘ │ -│ │ │ │ -│ ┌─────────────────┐ ┌─────────────────┐ │ -│ │ Agent C │ │ Agent D │ │ -│ │ Security │ │ Consistency │ │ -│ │ (Arch-Aware) │ │ (PRD ↔ Code) │ │ -│ │ │ │ │ │ -│ │ • OWASP Top 10 │ │ • 용어 통일 │ │ -│ │ • Auth/AuthZ │ │ • 우선순위 균형 │ │ -│ │ • 기존 보안 패턴 │ │ • PRD↔Code 용어 │ │ -│ │ 과 비교 │ │ 불일치 │ │ -│ │ • Data Protection│ │ • 아키텍처 정합 │ │ -│ └────────┬─────────┘ └────────┬─────────┘ │ -│ │ │ │ -│ └──────────┬──────────┘ │ -│ ▼ │ -│ ┌────────────────────┐ │ -│ │ Phase 3: Cross- │ │ -│ │ Category Synthesis │ │ -│ ├────────────────────┤ │ -│ │ Phase 4: Merge + │ │ -│ │ Quality Gate │ │ -│ └────────────────────┘ │ -│ │ -│ ──────── 완전 독립 병렬 (4x speedup) ──────── │ -│ │ -└──────────────────────────────────────────────────────────────────┘ -``` +Phase 0 컨텍스트 + Phase 1 PRD 섹션을 주입한 뒤 Agent A/B/C/D를 **완전 독립 병렬**로 디스패치(4x speedup) → Phase 3 Cross-Category Synthesis → Phase 4 Merge + Quality Gate로 수렴. 각 에이전트의 렌즈·증거원은 위 다양성 계약 표, 세부 출력은 아래 각 Agent 정의를 따른다. ### Agent A: Completeness (Code-Aware) diff --git a/plugins/wigtn-plugins/agents/parallel-review-coordinator.md b/plugins/wigtn-plugins/agents/parallel-review-coordinator.md index 7319a76..ed59d1b 100644 --- a/plugins/wigtn-plugins/agents/parallel-review-coordinator.md +++ b/plugins/wigtn-plugins/agents/parallel-review-coordinator.md @@ -79,50 +79,12 @@ project_context: ### Auto-Discovery Protocol -```yaml -context_harvest: - # 1. 프로젝트 메타데이터 수집 (필수) - project_metadata: - must_read: - - "CLAUDE.md" # 프로젝트 규칙, 아키텍처 결정 - - "README.md" # 프로젝트 개요, 목적 - should_read: - - ".eslintrc* / .prettierrc*" # JS/TS 린팅 규칙 - - "ruff.toml / pyproject.toml" # Python 린팅/패키지 규칙 - - "tsconfig.json / Cargo.toml / go.mod" # 언어/프레임워크 감지 - - ".editorconfig" # 에디터 설정 - strategy: "Glob으로 존재 여부 확인 → 존재하면 Read" - - # 2. 디렉토리 구조 분석 (필수) - architecture_scan: - action: "프로젝트 루트에서 depth 2~3까지 디렉토리 구조 파악" - detect: - - "모듈 경계 (src/api/, src/services/, src/models/ 등)" - - "테스트 위치 (tests/, __tests__/, *.test.*, *.spec.*)" - - "설정 파일 위치 (config/, .env.example)" - - "공유 모듈 (shared/, common/, lib/, utils/)" - output: "module_map — 모듈별 역할과 경계" - - # 3. 최근 변경 흐름 파악 (선택, review_level >= 2) - git_context: - action: "git log --oneline -20 으로 최근 변경 흐름 파악" - detect: - - "최근 커밋 패턴 (feat/fix/refactor 비율)" - - "활발히 변경 중인 모듈" - - "관련된 최근 리팩토링 여부" - - # 4. 기존 코드 패턴 학습 (필수) - pattern_learning: - action: "변경된 파일과 같은 디렉토리의 기존 파일 2~3개를 샘플링" - detect: - - "에러 핸들링 패턴 (try/except, Result 타입, error code)" - - "로깅 패턴 (logger.info, console.log, print 사용 여부)" - - "네이밍 컨벤션 (snake_case, camelCase, PascalCase)" - - "import 정렬 방식" - - "함수/메서드 시그니처 스타일 (type hints, JSDoc, 반환 타입)" - - "테스트 패턴 (fixture 사용, mock 패턴, assertion 스타일)" - output: "project_patterns — 프로젝트의 실제 코딩 패턴" -``` +프로젝트 컨벤션을 코드베이스에서 직접 수확한다. 다음 신호를 harvest하고 아래 출력 변수로 정리한다: + +- **`project_rules`** — CLAUDE.md·README + lint 설정(.eslintrc/prettier/ruff/pyproject/tsconfig)에서 추출한 규칙·언어/프레임워크 +- **`module_map`** — depth 2~3 디렉토리 구조에서 파악한 모듈 경계·테스트 위치·공유 모듈 +- **`project_patterns`** — 변경 파일과 같은 디렉토리의 기존 파일 2~3개를 샘플링해 학습한 실제 코딩 패턴(에러 핸들링·로깅·네이밍·import 정렬·시그니처 스타일·테스트 패턴). **감점의 baseline이 되므로 필수.** +- (review_level ≥ 2, 선택) `git log --oneline -20`으로 최근 변경 흐름·활발히 변경 중인 모듈 파악 ### Context Harvest Output @@ -284,50 +246,20 @@ file_distribution: ### Evidence-Based Scoring -```yaml -scoring_rules: - # 모든 감점에는 증거가 필요하다 - every_deduction: - required_fields: - file: "파일 경로" - line: "라인 번호 (또는 범위)" - code_snippet: "문제가 되는 코드 인용 (최대 3줄)" - reason: "구체적 이유 — 왜 문제인지" - suggestion: "개선안 — 어떻게 고쳐야 하는지" - evidence_type: "rule_violation | pattern_inconsistency | contract_break | security_risk | performance_concern" - - forbidden: - - "가독성이 떨어집니다 (코드 인용 없음)" - - "일반적으로 ~하는 게 좋습니다 (프로젝트 패턴 근거 없음)" - - "성능이 우려됩니다 (구체적 시나리오 없음)" - - "테스트가 부족합니다 (어떤 케이스가 빠졌는지 명시 없음)" - - # 감점 기준: 프로젝트 자체 패턴이 기준 - baseline: "project_patterns (Phase 0에서 학습)" - rule: "프로젝트의 기존 패턴과 다르면 감점, 일반론으로 감점하지 않음" -``` +모든 감점은 file·line·code_snippet(≤3줄)·reason·suggestion·evidence_type(`rule_violation | pattern_inconsistency | contract_break | security_risk | performance_concern`)을 갖춰야 하며, 근거의 baseline은 Phase 0에서 학습한 `project_patterns`다 — 일반론으로 감점하지 않는다(증거 없는 지적은 무효). --- ## Phase 2.5: Adversarial Verify (major+ findings 정밀도 보정) -> coverage-first(전량 보고)로 recall은 챙기되, **major 이상 finding은 게이트에 반영하기 전에 한 번 반증(refute)한다.** 목적: 그럴듯하지만 틀린 finding이 WARN/FAIL을 유발하는 노이즈를 줄인다. minor/info는 비용 대비 이득이 낮아 스킵한다. +> coverage-first(전량 보고)로 recall을 챙기되, **severity ∈ [critical, major] finding은 게이트 반영 전 1회 반증(refute)한다** (minor/info는 스킵 — 비용 대비 이득 낮음). 그럴듯하지만 틀린 finding이 WARN/FAIL을 유발하는 노이즈를 줄이는 게 목적. -```yaml -adversarial_verify: - scope: "severity in [critical, major] 인 finding만" # 비용 상한 - per_finding: - action: "각 finding을 독립 스킵틱 관점으로 1회 반증 시도" - prompt: "이 지적이 실제로 성립하는가? 코드·컨텍스트를 근거로 반박하라. 불확실하면 refuted=false로 두되 confidence를 낮춰라." - verdict: - holds: "반증 실패 → finding 유지 (게이트 반영)" - refuted: "반증 성공(근거 제시) → info로 강등 + 사유 기록 (게이트 미반영)" - uncertain: "판단 불가 → 유지하되 confidence=low로 하향" - cost_note: "critical은 반드시, major는 병렬로 한 번에 검증. 파일당 소수 finding이므로 팬아웃 비용은 제한적." - concurrency: "major+ finding들을 동시(병렬) 검증" -``` +각 finding을 독립 스킵틱 관점으로 반박한다 ("이 지적이 실제로 성립하는가? 코드·컨텍스트 근거로 반박하라"). major+ finding들은 병렬로 동시 검증. verdict: +- **holds** (반증 실패) → finding 유지 (게이트 반영) +- **refuted** (반증 성공, 근거 제시) → **info로 강등 + 사유 기록 (게이트 미반영)** +- **uncertain** (판단 불가) → 유지하되 confidence=low로 하향 -> **롤업 반영 순서**: Phase 2.5 검증을 통과한 finding만 Step 5 롤업의 critical/major 카운트에 들어간다. refuted된 것은 info로 빠져 게이트를 흔들지 않는다. (confidence low로 강등된 critical은 Step 5 규칙대로 major 취급 + 사람 확인 플래그.) +> **롤업 반영 순서**: Phase 2.5를 통과한 finding만 Step 5 롤업의 critical/major 카운트에 들어간다. refuted된 것은 info로 빠져 게이트를 흔들지 않는다. (confidence low로 강등된 critical은 Step 5 규칙대로 major 취급 + 사람 확인 플래그.) ## Phase 3: Contract Verification (Post-Review) @@ -578,32 +510,7 @@ full_failure: ## Review Level & Phase Mapping -```yaml -review_level_phases: - level_1: # 빠른 리뷰 - phase_0: "CLAUDE.md + lint config만 읽기" - phase_1: "SKIP" - phase_2: "변경 파일만 리뷰" - phase_3: "SKIP" - - level_2: # 표준 리뷰 - phase_0: "전체 Context Harvest" - phase_1: "caller 추적까지" - phase_2: "변경 파일 + caller 포함 리뷰" - phase_3: "시그니처 검증만" - - level_3: # 심층 리뷰 - phase_0: "전체 Context Harvest + git log" - phase_1: "전체 Blast Radius" - phase_2: "영향 체인 전체 리뷰" - phase_3: "전체 Contract Verification" - - level_4: # 최대 리뷰 - phase_0: "전체 Context Harvest + git log + PR 단위 변경 추적" - phase_1: "전체 Blast Radius + 간접 영향까지" - phase_2: "영향 체인 + 관련 모듈 전체" - phase_3: "전체 Contract + 모듈 경계 + 테스트 커버리지" -``` +리뷰 레벨이 높을수록 각 phase의 깊이가 커진다: **L1** = CLAUDE.md/lint만 읽고 변경 파일만 리뷰(Phase 1/3 SKIP). **L2** = 전체 Context Harvest + caller 추적 + 시그니처 검증. **L3** = + git log + 전체 Blast Radius + 전체 Contract Verification. **L4** = + PR 단위 변경/간접 영향/관련 모듈 전체 + 모듈 경계·테스트 커버리지. --- diff --git a/plugins/wigtn-plugins/agents/pr-reviewer.md b/plugins/wigtn-plugins/agents/pr-reviewer.md index ad2508d..6fb2fe2 100644 --- a/plugins/wigtn-plugins/agents/pr-reviewer.md +++ b/plugins/wigtn-plugins/agents/pr-reviewer.md @@ -58,15 +58,7 @@ Read: .eslintrc* | tsconfig.json | pyproject.toml ### Phase 3: 5-Category 평가 -`code-reviewer` 에이전트와 동일한 100점 평가 체계를 사용합니다. - -| Category | Weight | 평가 기준 | -|----------|--------|----------| -| **Readability** | 20% | 명명 규칙, 코드 구조, 가독성 | -| **Maintainability** | 20% | 모듈성, 결합도, 확장성 | -| **Performance** | 20% | 알고리즘 효율성, 리소스 사용 | -| **Testability** | 20% | 테스트 용이성, 커버리지 | -| **Best Practices** | 20% | 언어 관례, 디자인 패턴, 보안 | +`code-reviewer.md`의 5축 100점 평가 체계(Readability / Maintainability / Performance / Testability / Best Practices, 각 20점)를 동일하게 사용한다 — 그 정의를 따른다. **PR 리뷰 특화 추가 체크:** - PR 설명과 실제 변경의 일치 여부 @@ -210,34 +202,6 @@ pr_review_result: - 존댓말 사용 - 이모지 최소화 (상태 표시에만 사용: ✅ ⚠️ ❌) -### 예시 - -**Good:** -``` -⚠️ **Major**: `src/api/auth.ts:45` - -에러 응답에 내부 스택 트레이스가 노출되고 있습니다. -프로덕션 환경에서 보안 위험이 될 수 있습니다. - -**수정 제안:** -```ts -// Before -catch (error) { - res.status(500).json({ error: error.stack }); -} - -// After -catch (error) { - logger.error(error); - res.status(500).json({ error: 'Internal server error' }); -} -``` - -**Bad:** -``` -에러 처리가 별로입니다. -``` - ## Security Review 보안 관련 체크리스트: diff --git a/plugins/wigtn-plugins/agents/prd-reviewer.md b/plugins/wigtn-plugins/agents/prd-reviewer.md index 9e4b891..fdfcdf2 100644 --- a/plugins/wigtn-plugins/agents/prd-reviewer.md +++ b/plugins/wigtn-plugins/agents/prd-reviewer.md @@ -41,82 +41,15 @@ Critical 이슈 1개+ → ❌ BLOCKED → 수정 필요 > **이유**: §5.4.1·§5.5는 `/screen-spec`의 필수 입력. FE가 있는데 누락되면 막힌다. FE가 없는 백엔드/리팩터 PRD엔 부당 Critical을 만들지 않는다. > **Fail-safe**: 유형 판정이 모호하면 strict(제품) 모드로 auth·rate-limiting·GDPR Critical을 정상 발화시킨다. -## Analysis Categories +## Analysis Categories & Parallel Mode -### 1. 요구사항 완전성 (Completeness) +4개 카테고리(**Completeness / Feasibility / Security / Consistency**)의 적대적 렌즈·전용 증거원·병렬 실행 조건·병합 규칙은 `parallel-digging-coordinator`와 동일하다 — 그 정의를 따른다. 요약: -| 체크 항목 | 설명 | -|----------|------| -| 기능 요구사항 누락 | 명시되지 않은 필수 기능 | -| 비기능 요구사항 누락 | 성능, 보안, 확장성 정의 | -| Scale Grade 정의 | Hobby/Startup/Growth/Enterprise | -| SLA/SLO 기준 | p95, Uptime, 데이터 요구 | -| 엣지 케이스 | 예외 상황 고려 | -| 에러 처리 | 실패 시나리오 정의 | -| 사용자 시나리오 | 모든 유형 고려 | -| **User Roles (§2.3)** | Role Key가 영문 문자열로 통일 선언됨 | -| **Pages 인벤토리 (§5.4)** | 페이지마다 Audience/Auth/Linked FRs/Has FE Components 채워짐 | -| **Page State Matrix (§5.4.1)** | `Has FE Components: Yes`인 페이지가 1개+면 상태 매트릭스 필수 | -| **User Flow (§5.5)** | FE 페이지가 있으면 Mermaid 플로우 1개+ 필수 | +- 병렬은 PRD가 클 때만(섹션 5개+ **그리고** Growth/Enterprise, 또는 FR 8개+). 소형 PRD·`--sequential`은 순차. **순차여도 4개 렌즈는 모두 적용**한다. +- 렌즈별 각도/증거원: A Completeness(누락·엣지·미정의 | PRD 본문+기존 기능), B Feasibility(통합 리스크·breaking change | 코드·의존성·모듈 경계), C Security(OWASP·인증·데이터 노출 | 아키텍처·인증 흐름·.env.example), D Consistency(용어·우선순위·정합 | PRD 교차+네이밍). +- 각 렌즈는 "PRD를 깨는" 구체 시나리오를 최소 1개 찾으려 시도하고, 모든 지적에 PRD 섹션 번호를 증거로 단다. -### 2. 기술적 실현 가능성 (Feasibility) - -| 체크 항목 | 설명 | -|----------|------| -| 기술 스택 적합성 | 요구사항에 적합한가 | -| 구현 복잡도 | 과도하게 복잡한가 | -| 의존성 리스크 | 외부 의존도 | -| 성능 병목 | 예상 성능 이슈 | -| 확장성 한계 | 스케일링 문제 | - -### 3. 보안 및 리스크 (Security & Risk) - -| 체크 항목 | 설명 | -|----------|------| -| 인증/인가 | 접근 제어 정의 | -| 데이터 보호 | 민감 데이터 처리 | -| 입력 검증 | 사용자 입력 검증 | -| API 보안 | Rate limiting, CORS | -| 규정 준수 | GDPR, 개인정보보호법 | - -### 4. 일관성 및 명확성 (Consistency) - -| 체크 항목 | 설명 | -|----------|------| -| 용어 일관성 | 동일 개념에 다른 용어 | -| 요구사항 충돌 | 상충되는 요구사항 | -| 우선순위 명확성 | P0/P1/P2 적절 분배 | -| 의존성 순환 | 순환 의존 요구사항 | -| 측정 가능성 | 성공 기준 측정 가능성 | -| Scale Grade-NFR 정합성 | Grade와 NFR 목표값 일관성 | -| Scale Grade-기술 스택 정합성 | Grade와 기술 선택 적합성 | - -## Parallel Analysis Mode - -> 4개 카테고리를 독립 에이전트로 병렬 실행합니다 (각 카테고리를 동시 분석). - -### 병렬 모드 - -PRD 규모가 클 때만(섹션 5개+ **그리고** Scale Grade Growth/Enterprise, 또는 FR 8개+) 4개 카테고리를 병렬 실행한다. 소형 PRD(Hobby/Startup·FR<8·500자 미만)는 단일 컨텍스트가 같은 걸 대부분 잡으므로 순차가 더 싸고 충분하다. `--sequential`이면 순차 강제. **순차여도 4개 렌즈는 모두 적용**한다(병렬을 끄는 것이지 렌즈를 줄이는 게 아니다). - -### 에이전트별 담당 (적대적 렌즈 + 전용 증거원) - -> 4-way가 단일 컨텍스트를 이기려면 관점과 증거원이 실제로 갈라져야 한다. 각 렌즈는 **그 각도에서 PRD를 적극적으로 깨보고**, 자기 전용 증거원만 1차로 파며, 다른 렌즈의 질문을 다시 던지지 않는다. - -``` -Agent A Completeness — "무엇이 빠져 실패하는가?" (누락·엣지케이스·미정의) | 증거원: PRD 본문 + 기존 기능 -Agent B Feasibility — "정말 만들 수 있는가?" (통합 리스크·breaking change) | 증거원: 코드/의존성/모듈 경계 -Agent C Security — "공격자면 어디를 뚫는가?" (OWASP·인증·데이터 노출) | 증거원: 아키텍처·인증 흐름·.env.example -Agent D Consistency — "스스로/코드와 모순되는 곳은?" (용어·우선순위·정합) | 증거원: PRD 전체 교차 + 네이밍 패턴 -``` - -각 렌즈는 최소 1개 이상 "PRD를 깨는" 구체 시나리오를 찾으려 시도하고(못 찾으면 근거와 함께 "결함 없음" 명시), 모든 지적에 PRD 섹션 번호를 증거로 단다. - -### 병합 규칙 - -- 동일 섹션의 동일 이슈 → 중복 제거 (높은 severity 채택) -- Severity별 정렬 (Critical → Major → Minor) -- Quality Gate: Critical 0개 = PASS, 1개+ = BLOCKED +Completeness 렌즈는 FE 페이지 존재 시 §2.3 User Roles / §5.4 Pages 인벤토리 / §5.4.1 Page State Matrix / §5.5 User Flow Mermaid의 필수 충족 여부를 반드시 점검한다(위 Quality Gate의 Critical 기준과 연동). ## Analysis Protocol @@ -218,27 +151,3 @@ Read: ✅ **PRD 수정 완료 후**: 위 안내에 따라 다음 명령을 실행하세요. ``` - -## Checklist Templates - -### 인증 시스템 PRD -- [ ] 회원가입/로그인/로그아웃 플로우 -- [ ] 비밀번호 정책 -- [ ] 세션/토큰 관리 -- [ ] OAuth 에러 처리 -- [ ] Rate Limiting -- [ ] 계정 잠금 정책 - -### API 설계 PRD -- [ ] 엔드포인트 목록 -- [ ] 요청/응답 형식 -- [ ] 에러 코드 표준화 -- [ ] 인증 요구사항 -- [ ] Rate Limiting -- [ ] CORS 정책 - -### 데이터베이스 PRD -- [ ] 엔티티 관계 다이어그램 -- [ ] 필수/선택 필드 -- [ ] 인덱스/마이그레이션 전략 -- [ ] 백업/복구 정책 diff --git a/plugins/wigtn-plugins/agents/team-build-coordinator.md b/plugins/wigtn-plugins/agents/team-build-coordinator.md index 7ca547e..968d80b 100644 --- a/plugins/wigtn-plugins/agents/team-build-coordinator.md +++ b/plugins/wigtn-plugins/agents/team-build-coordinator.md @@ -293,39 +293,18 @@ phase_0_context_harvesting_and_setup: description: "프로젝트 컨텍스트 수집 + 팀 실행 준비" steps: - # --- 기존 Setup (유지) --- - 1. "MEMORY.md 읽기 → 프로젝트 컨벤션, 기존 패턴 파악" - 2. "SHARED_CONTEXT_{feature}.md 생성 (docs/shared/ 디렉토리)" + # --- 팀 셋업 (SHARED_CONTEXT/TaskCreate 와이어링) --- + 1. "MEMORY.md 읽기 → 프로젝트 컨벤션·기존 패턴 파악" + 2. "SHARED_CONTEXT_{feature}.md 생성 (docs/shared/, 아래 template 사용)" 3. "팀별 TaskCreate 등록" 4. "파일 락 할당 (팀별 exclusive lock)" 5. "팀 간 의존성 그래프 확인" - # --- Context Harvesting (신규) --- - 6. "CLAUDE.md 읽기 → 프로젝트 규칙, 아키텍처 결정, 컨벤션 확인" - 7. "디렉토리 구조 스캔 → 모듈 경계 파악": - method: "ls -R 또는 tree로 source_root 구조 확인" - output: "모듈 목록, 디렉토리 네이밍 패턴" - 8. "기존 코드 패턴 학습 → 각 팀 담당 영역의 기존 파일 2-3개 샘플링": - per_team: - BACKEND: "기존 API/서비스 파일에서 패턴 추출" - FRONTEND: "기존 컴포넌트/페이지 파일에서 패턴 추출" - AI_SERVER: "기존 AI 모듈 파일에서 패턴 추출" - OPS: "기존 Docker/CI 파일에서 패턴 추출" - extract: - - "함수/변수 네이밍 (snake_case vs camelCase)" - - "에러 핸들링 패턴 (try/catch, Result type, error codes)" - - "import 스타일 (absolute vs relative, path alias)" - - "파일 구조 (export default vs named export)" - - "타입 정의 방식 (interface vs type, Pydantic vs dataclass)" - 9. "린트/포맷 설정 읽기": - files_to_check: - - ".eslintrc*", "eslint.config.*" - - ".prettierrc*", "prettier.config.*" - - "ruff.toml", "pyproject.toml [tool.ruff]" - - "tsconfig.json" - - ".editorconfig" - extract: "들여쓰기, 따옴표 스타일, trailing comma, line length 등" - 10. "harvest_result를 SHARED_CONTEXT의 Project Patterns 섹션에 기록" + # --- Context Harvesting --- + # CLAUDE.md(규칙)·디렉토리 구조(모듈 경계)·각 팀 담당 영역 기존 파일 2~3개 샘플링 + # (네이밍·에러핸들링·import·파일구조·타입정의 패턴)·린트포맷 설정(eslint/prettier/ruff/tsconfig) + # 을 수집해 harvest_result → SHARED_CONTEXT의 Project Patterns 섹션에 기록. + 6. "harvest_result 수집 후 SHARED_CONTEXT Project Patterns에 기록" # 파일이 없는 영역 (새 프로젝트/새 모듈)의 경우 no_existing_files_fallback: @@ -434,81 +413,30 @@ phase_2_parallel: - 타입 정의 방식은 기존 코드의 방식을 사용하세요 (interface vs type, Pydantic vs dataclass) - 테스트 작성 시 기존 테스트의 fixture/setup 패턴을 따르세요 + # 모든 팀 프롬프트는 {common_context}(위)를 헤더로 받는다 — MEMORY.md/SHARED_CONTEXT 읽기, + # Project Patterns 준수, 같은 디렉토리 기존 파일 구조 참조는 거기서 이미 지시됨. 아래는 팀 전용 wiring만. team_prompts: BACKEND: subagent_type: "wigtn-plugins:backend-architect" - prompt: | - {common_context} - - ## 할당된 작업 - {backend_tasks} - - ## 파일 목록 - {backend_files} - - ## 프로젝트 컨텍스트 - {project_context} - - ## 지시사항 - - 기존 프로젝트 컨벤션을 따르세요 (MEMORY.md 참조) - - API 엔드포인트 구현 후 SHARED_CONTEXT의 API Contract를 업데이트하세요 - - 공유 타입 생성 시 SHARED_CONTEXT의 Shared Types에 기록하세요 - - 환경 변수 추가 시 SHARED_CONTEXT의 Environment Variables에 기록하세요 - - 새 파일 생성 시 같은 디렉토리 기존 파일의 구조/패턴을 참조하세요 + inputs: "{backend_tasks}, {backend_files}, {project_context}" + task_focus: "구현 후 SHARED_CONTEXT의 API Contract·Shared Types·Environment Variables를 업데이트 (쓰기 권한 보유 팀)" FRONTEND: subagent_type: "wigtn-plugins:frontend-developer" - prompt: | - {common_context} - - ## 할당된 작업 - {frontend_tasks} - - ## 파일 목록 - {frontend_files} - - ## API 모킹 - Backend API가 아직 완성되지 않았을 수 있습니다. - SHARED_CONTEXT의 API Contract를 참조하여 필요 시 모킹하세요. - needs_api_mock: {needs_api_mock} - - ## 지시사항 - - 기존 디자인 패턴을 따르세요 (MEMORY.md 참조) - - SHARED_CONTEXT의 Shared Types를 import하여 타입 일관성을 유지하세요 - - 컴포넌트는 기존 프로젝트의 네이밍 컨벤션을 따르세요 - - 새 컴포넌트 생성 시 같은 디렉토리의 기존 컴포넌트 구조를 참조하세요 + inputs: "{frontend_tasks}, {frontend_files}" + task_focus: | + Backend 미완 시 SHARED_CONTEXT의 API Contract 참조해 모킹(needs_api_mock: {needs_api_mock}). + Shared Types를 import해 타입 일관성 유지. AI_SERVER: subagent_type: "wigtn-plugins:ai-agent" - prompt: | - {common_context} - - ## 할당된 작업 - {ai_tasks} - - ## 공유 타입 참조 - {shared_types} - - ## 지시사항 - - SHARED_CONTEXT의 Shared Types와 API Contract를 참조하세요 - - AI 엔드포인트 추가 시 SHARED_CONTEXT의 API Contract에 기록하세요 - - STT/LLM 설정은 환경 변수로 관리하고 SHARED_CONTEXT에 기록하세요 - - 기존 AI 모듈의 패턴 (에러 핸들링, 로깅 등)을 따르세요 + inputs: "{ai_tasks}, {shared_types}" + task_focus: "Shared Types·API Contract 참조; AI 엔드포인트는 API Contract에, STT/LLM 설정은 환경변수로 SHARED_CONTEXT에 기록" OPS: subagent_type: "general-purpose" - prompt: | - {common_context} - - ## 할당된 작업 - {ops_tasks} - - ## 지시사항 - - devops-patterns 스킬을 참조하여 실행하세요 - - SHARED_CONTEXT의 Environment Variables를 참조하세요 - - Docker/CI 설정에 필요한 환경 변수를 SHARED_CONTEXT에 기록하세요 - - 다른 팀이 추가한 환경 변수도 포함해야 합니다 - - 기존 인프라 설정 파일의 스타일/구조를 따르세요 + inputs: "{ops_tasks}" + task_focus: "devops-patterns 스킬 참조; 모든 팀이 등록한 환경변수를 SHARED_CONTEXT Environment Variables에 통합" execution: method: "Task tool로 각 팀 subagent 동시 실행" @@ -539,24 +467,15 @@ phase_3_integration_and_pattern_verification: - "index.ts 등 공유 파일의 export 통합" # --- 패턴 일관성 검증 (신규) --- + # 각 check는 새 코드를 Phase 0 harvest_result / 기존 코드와 비교하는 방식이다. 6. "패턴 일관성 검증 (Pattern Consistency Check)": - checks: - naming_consistency: - description: "새 파일이 Phase 0에서 학습한 네이밍 패턴을 따르는지" - method: "새로 생성된 파일명, 함수명, 변수명을 기존 패턴과 비교" - cross_team: "팀 간 네이밍 일관성 확인 (Backend: snake_case, Frontend: camelCase → OK if project convention)" - error_handling_consistency: - description: "에러 핸들링 패턴이 프로젝트 기존 패턴과 일치하는지" - method: "새 코드의 try/catch, error type, error response 형식을 기존 코드와 비교" - import_style_consistency: - description: "import 스타일이 프로젝트 기존 방식과 일치하는지" - method: "absolute/relative import, path alias 사용 여부 확인" - file_structure_consistency: - description: "새 파일의 구조가 같은 디렉토리의 기존 파일과 일관되는지" - method: "export 방식, 파일 구성 (imports → types → logic → export) 비교" - test_pattern_consistency: - description: "새 테스트가 기존 테스트 패턴을 따르는지" - method: "fixture 사용, setup/teardown 패턴, assertion 스타일 비교" + # | check | 비교 대상 | + # | naming | 새 파일명·함수명·변수명 vs 기존 네이밍 (팀 간 크로스: Backend snake_case / Frontend camelCase는 프로젝트 컨벤션이면 OK) | + # | error_handling| 새 try/catch·error type·response 형식 vs 기존 | + # | import_style | absolute/relative·path alias 사용 여부 vs 기존 | + # | file_structure| export 방식·파일 구성(imports→types→logic→export) vs 같은 디렉토리 기존 파일 | + # | test_pattern | fixture·setup/teardown·assertion 스타일 vs 기존 테스트 | + checks: ["naming", "error_handling", "import_style", "file_structure", "test_pattern"] 7. "패턴 위반 보고 (Pattern Violation Report)": on_violation: @@ -641,70 +560,9 @@ phase_4_verification: 🔗 Shared Context: docs/shared/SHARED_CONTEXT_user-auth.md ``` -### Phase 완료 표시 +### 완료 표시 -``` -✅ Team BUILD 완료! - -┌─────────────────────────────────────────────────────────────┐ -│ 📊 Team BUILD 결과 │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ [Team: BACKEND] ✅ 완료 (5/5 tasks) │ -│ [Team: FRONTEND] ✅ 완료 (3/3 tasks) │ -│ [Team: OPS] ✅ 완료 (2/2 tasks) │ -│ │ -│ 📊 전체: 10/10 tasks (100%) │ -│ ⚡ 병렬 실행으로 독립 작업을 동시 처리 │ -│ │ -│ 🔗 Shared Context: docs/shared/SHARED_CONTEXT_user-auth.md │ -│ 📝 Memory Updated: 2 new patterns recorded │ -│ │ -│ 검증 결과: │ -│ ✅ API 계약 일관성 확인 │ -│ ✅ 타입 일관성 확인 │ -│ ✅ 파일 충돌 없음 │ -│ ✅ 패턴 일관성 확인 │ -│ 📝 Pattern warnings: 0 │ -│ │ -└─────────────────────────────────────────────────────────────┘ -``` - -### Pattern Warning 발생 시 - -``` -✅ Team BUILD 완료! - -┌─────────────────────────────────────────────────────────────┐ -│ 📊 Team BUILD 결과 │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ [Team: BACKEND] ✅ 완료 (5/5 tasks) │ -│ [Team: FRONTEND] ✅ 완료 (3/3 tasks) │ -│ [Team: OPS] ✅ 완료 (2/2 tasks) │ -│ │ -│ 📊 전체: 10/10 tasks (100%) │ -│ ⚡ 병렬 실행으로 독립 작업을 동시 처리 │ -│ │ -│ 🔗 Shared Context: docs/shared/SHARED_CONTEXT_user-auth.md │ -│ 📝 Memory Updated: 2 new patterns recorded │ -│ │ -│ 검증 결과: │ -│ ✅ API 계약 일관성 확인 │ -│ ✅ 타입 일관성 확인 │ -│ ✅ 파일 충돌 없음 │ -│ ⚠️ 패턴 일관성: 2 warnings (minor) │ -│ │ -│ Pattern Warnings: │ -│ ⚠️ [FRONTEND] LoginForm.tsx: import style │ -│ Expected: relative ("./utils") | Found: absolute │ -│ → Auto-fixed ✅ │ -│ ⚠️ [BACKEND] AuthService.ts: error handling │ -│ Expected: custom AppError | Found: generic Error │ -│ → Manual fix needed │ -│ │ -└─────────────────────────────────────────────────────────────┘ -``` +완료 시 위와 같은 형식으로 팀별 완료 tasks, 전체 진행률, Shared Context 경로, Memory 업데이트 건수, 검증 결과(API 계약·타입·파일 충돌·패턴 일관성)를 출력한다. 패턴 위반이 있으면 각 warning에 [팀] 파일:항목, Expected vs Found, 자동수정/수동수정 여부를 minor로 덧붙인다. ## Error Handling & Graceful Degradation diff --git a/plugins/wigtn-plugins/commands/auto-commit.md b/plugins/wigtn-plugins/commands/auto-commit.md index eeaf229..7272f25 100644 --- a/plugins/wigtn-plugins/commands/auto-commit.md +++ b/plugins/wigtn-plugins/commands/auto-commit.md @@ -218,6 +218,21 @@ ls PLAN_*.md PRD.md 2>/dev/null - 재계산이 PASS(critical 0, major 0, minor <5)면 커밋 진행. - 자동 개선 후에도 major/critical가 남으면(포맷터로 안 고쳐지는 로직·설계 이슈) 수동 수정 필요 항목(파일·라인·이유)을 나열하고 커밋 중단. 수정 후 다시 `/auto-commit` 실행 안내. +### Step 3.5: 게이트 통과 기록 (하드 게이트 연동) — PASS 경로에서만 + +> **왜**: 품질 게이트는 프롬프트 지시라 컨텍스트가 차면 조용히 스킵될 수 있다. hook(`hooks.json` PreToolUse)이 커밋을 실제로 차단하려면, "게이트가 방금 PASS했다"는 **검증 아티팩트**가 필요하다. 이 단계는 롤업이 **PASS**로 확정됐을 때만 실행한다(FAIL/WARN-잔존이면 실행하지 않음 → 아티팩트 없음 → 커밋 hook 차단). + +```bash +# 롤업이 PASS로 확정된 경우에만 실행한다. +grep -qxF '.wigtn/' .git/info/exclude 2>/dev/null || echo '.wigtn/' >> .git/info/exclude # 아티팩트가 커밋에 섞이지 않도록 (tracked .gitignore 미변경) +mkdir -p .wigtn +echo "PASS $(git rev-parse --short HEAD 2>/dev/null || echo INITIAL) $(git rev-parse --abbrev-ref HEAD 2>/dev/null)" > .wigtn/gate-pass # mtime = PASS 시각. hook이 30분 신선도로 검증 +``` + +- **아티팩트 의미**: 파일의 **mtime**이 곧 "게이트 PASS 시각"이다. hook은 `find .wigtn/gate-pass -mmin -30`으로 **30분 이내 PASS**만 유효 처리한다 — 지난 세션의 오래된 통과나, 게이트를 건너뛴 커밋을 막는다. +- **재작성 금지**: 이 파일은 오직 이 단계(PASS 확정)에서만 쓴다. Step 6에서 커밋 직전에 `touch`하거나 미리 생성하지 않는다 — 그러면 하드 게이트가 무의미해진다. +- **커밋 후 자동 무효화**: 다음 게이트 실행 전까지 mtime이 늙으므로 재사용되지 않는다. 별도 삭제 로직 불필요. + ### Step 4: 변경 분석 및 타입 결정 | 변경 패턴 | 커밋 타입 | 예시 | @@ -248,6 +263,8 @@ Co-Authored-By: Claude - **Subject**: 50자 이내, 동사 원형으로 시작(Add/Update/Fix/Remove), 마침표 없음 - **Body**: 변경된 주요 파일/기능 나열, 72자 줄바꿈 +- **`Quality Score:` 줄은 게이트가 실제로 실행됐을 때만 넣는다.** 하드 게이트 hook은 이 줄을 "게이트를 거친 파이프라인 커밋" 신호로 본다 → `.wigtn/gate-pass` 아티팩트가 없으면 차단한다. + - **`--no-review`(게이트 스킵)**: `Quality Score:` 줄을 **넣지 않고** 대신 `Quality Gate: SKIPPED (--no-review)`로 표기한다. 신호가 없으므로 hook을 우회한다(긴급 핫픽스 경로 보존). ### Step 5.5: Safety Guard (최종 확인) @@ -380,10 +397,12 @@ EOF 1. 변경사항 수집 + 브랜치 확인 2. `code-reviewer` findings 수집 (severity + confidence) 3. findings 롤업으로 분기 (결정론적): - - **PASS** (critical 0, major 0, minor <5) → Step 5.5 Safety Guard로 진행 - - **WARN** (critical 0, major ≥1 또는 minor ≥5) → `code-formatter` 자동 개선 → 롤업 재계산 → PASS면 Safety Guard, major 잔존이면 STOP(수동 수정) - - **FAIL** (critical ≥1) → STOP (수동 수정) + - **PASS** (critical 0, major 0, minor <5) → **Step 3.5에서 게이트 통과 아티팩트(`.wigtn/gate-pass`) 기록** → Step 5.5 Safety Guard로 진행 + - **WARN** (critical 0, major ≥1 또는 minor ≥5) → `code-formatter` 자동 개선 → 롤업 재계산 → PASS면 Step 3.5 기록 후 Safety Guard, major 잔존이면 STOP(수동 수정) + - **FAIL** (critical ≥1) → STOP (수동 수정) — 아티팩트 미기록 → 커밋 hook 차단 - **Security Critical** → critical의 부분집합 → FAIL → STOP + +> **하드 게이트 (hook 강제)**: `hooks.json`의 PreToolUse가 `git commit`을 가로채, 메시지에 `Quality Score:`가 있는데 30분 이내 `.wigtn/gate-pass`가 없으면 커밋을 **차단(exit 2)**한다. 게이트가 프롬프트라 스킵돼도 하네스가 커밋을 막는다. 수동 커밋(신호 없음)·`--no-review`(신호 제거)는 영향받지 않는다. 4. Safety Guard에서 AskUserQuestion("PR 생성?") → 선택에 따라: - PR 생성 → BRANCH + COMMIT + PUSH + PR - Draft PR → BRANCH + COMMIT + PUSH + Draft PR @@ -430,6 +449,7 @@ EOF 10. **기존 PR 확인**: 같은 브랜치에 open PR이 이미 있으면 새 PR 생성하지 않고 커밋만 추가 11. **Multiple Remote 처리** (Direct 모드): remote가 2개 이상이면 push 전 반드시 사용자 확인, tracking branch가 설정된 remote를 기본값으로 제안 12. **점수 근거 동반**: 보고하는 모든 Quality Score에는 구체적 findings를 함께 제시한다 (근거 없는 숫자 금지) +13. **하드 게이트 아티팩트**: 롤업 PASS 시에만 Step 3.5에서 `.wigtn/gate-pass`를 기록한다. 커밋 hook이 이 아티팩트로 게이트 실행을 강제하므로, 게이트를 우회하려 파일을 미리 만들거나 `touch`하지 않는다. ## Skip Quality Gate @@ -439,4 +459,6 @@ EOF /auto-commit --no-review --direct --message "hotfix: 긴급 버그 수정" ``` +- `--no-review`는 게이트를 실행하지 않으므로 커밋 메시지에 `Quality Score:` 줄을 넣지 않는다(대신 `Quality Gate: SKIPPED (--no-review)`). 하드 게이트 hook은 `Quality Score:` 신호가 없는 커밋을 통과시키므로 이 경로가 정상 동작한다. + ⚠️ **경고**: 품질 검사 스킵은 권장하지 않습니다. 가능하면 `/review-pr`로 리뷰를 받으세요. diff --git a/plugins/wigtn-plugins/commands/implement.md b/plugins/wigtn-plugins/commands/implement.md index 1b2cc5c..8441fc7 100644 --- a/plugins/wigtn-plugins/commands/implement.md +++ b/plugins/wigtn-plugins/commands/implement.md @@ -31,12 +31,7 @@ PRD에 정의된 기능을 구현합니다. ## Two-Phase Approach -DESIGN(설계) → **사용자 확인(Y/n) 필수** → BUILD(구현)의 2단계로 진행합니다. - -- **DESIGN**: PRD 분석, Task Plan 로드, 아키텍처 결정(subagent), 구현 계획, 파일 구조 수립. -- **사용자 승인**: BUILD로 넘어가기 전 반드시 사용자 확인을 받습니다. -- **BUILD**: 코드 작성, Phase별 실행, TodoWrite 연동, 테스트/빌드 검증, PLAN 파일 업데이트. -- **1-Click Complete**: `auto_commit: true` 이면 BUILD 완료 후 자동으로 `/auto-commit`을 트리거합니다. +DESIGN(설계) → **사용자 확인(Y/n) 필수** → BUILD(구현)의 2단계로 진행합니다. 상세 동작은 아래 DESIGN Phase / BUILD Phase Step 정의를 따릅니다. `auto_commit: true` 이면 BUILD 완료 후 자동으로 `/auto-commit`을 트리거합니다. ## 작업 규모 triage (Triage) — 진입 시 최초 1회 @@ -143,16 +138,7 @@ DESIGN 완료 후, **이슈 트래커(Linear) 연동 여부**에 따라 BUILD ### Parallel DESIGN (병렬 모드 시) -병렬 모드에서는 Steps 0-4를 3개 에이전트로 동시 실행한 뒤 Step 5에서 병합합니다. - -| Agent | 담당 Steps | 역할 | Step 5로 넘기는 결과 | -|-------|-----------|------|---------------------| -| A | Step 0 (+0.5) + 1 | PRD 검색, 품질 게이트 확인, 이슈 트래커 감지(읽기 전용) | PRD 내용 + QG 상태 + 트래커 감지 결과 | -| B | Step 2 | 아키텍처 결정 (architecture-decision 위임) | 아키텍처 결정 + 폴더 구조 | -| C | Step 3 + 4 | 프로젝트 상태 분석, Gap Analysis | 기존 코드 상태 + Gap 목록 | - -- Step 0.5는 읽기 전용이므로 Agent A 레인에 포함합니다. -- **Quality Gate BLOCKED 처리**: Agent A가 BLOCKED 판정 시 즉시 Agent B, C를 중단하고, Critical 이슈 목록을 사용자에게 표시한 뒤 수정 후 재시도를 안내합니다. +병렬 모드에서는 Steps 0-4를 3개 에이전트로 나눠 동시 실행 후 Step 5에서 병합합니다: **A** = Step 0+0.5+1(PRD 검색·QG·트래커 감지, 모두 읽기 전용), **B** = Step 2(아키텍처 결정), **C** = Step 3+4(프로젝트 분석·Gap Analysis). Agent A가 **Quality Gate BLOCKED** 판정 시 즉시 B·C를 중단하고 Critical 이슈를 표시한 뒤 수정 후 재시도를 안내합니다. 순차 모드에서는 아래 Step 0~7을 순서대로 실행합니다. @@ -669,24 +655,7 @@ npm run build # 빌드 확인 ## Code Pattern Discovery -**API 엔드포인트 발견:** -```bash -Glob: "**/api/**/*.{ts,js,py}" -Grep: "@router|@Controller|router\." -``` - -**컴포넌트 패턴 발견:** -```bash -Glob: "**/components/**/*.{tsx,jsx}" -Grep: "export (default )?function|export const" -``` - -**데이터베이스 스키마 발견:** -```bash -Glob: "**/prisma/schema.prisma" # Prisma -Glob: "**/models/*.py" # SQLAlchemy -Glob: "**/entities/*.ts" # TypeORM -``` +기존 패턴을 Glob/Grep으로 파악해 컨벤션을 따른다: API 엔드포인트(`**/api/**`, 라우터/컨트롤러 데코레이터), 컴포넌트(`**/components/**`, export 패턴), DB 스키마(Prisma `schema.prisma` / SQLAlchemy `models/` / TypeORM `entities/`). --- @@ -755,101 +724,17 @@ Glob: "**/entities/*.ts" # TypeORM ## Error Recovery Protocol (에러 복구 프로토콜) -구현 중 발생할 수 있는 오류 상황과 복구 방법을 정의합니다. - -### 1. 아키텍처 결정 실패 - -**상황**: `architecture-decision` 에이전트가 응답하지 않거나 오류 발생. - -복구 옵션: ① 기본 아키텍처(Modular Monolith, 가장 안전)로 진행 ② 수동 선택("Monolithic"/"Modular Monolith"/"MSA") ③ 재시도. - -**복구 절차**: 에이전트 상태 확인(3회 재시도) → 실패 시 기본값(Modular Monolith) 제안 → 사용자에게 선택권 제공. - -### 2. Phase 중간 실패 - -**상황**: 특정 Phase 실행 중 오류 발생 (빌드 실패, 테스트 실패 등). 실패 지점(Phase/Task/진행률)과 오류 내용을 표시합니다. - -**자동 복구 가능한 오류:** - -| 오류 유형 | 자동 복구 방법 | -|----------|---------------| -| 의존성 누락 | `npm install` / `pip install` 자동 실행 | -| 타입 오류 (단순) | 타입 수정 후 재컴파일 | -| 린트 오류 | `code-formatter` 에이전트 호출 | -| 포트 충돌 | 대체 포트 자동 할당 | - -**자동 복구 불가능한 오류:** 수동 개입이 필요함을 알리고 오류·원인·해결 방법을 안내합니다. 진행 상태는 PLAN 파일에 현재 Phase/Task로 저장되어, 재개 시("계속 진행" 또는 `/implement --resume`) 실패 지점부터 이어서 진행합니다. - -### 3. PLAN 파일 동기화 오류 - -**상황**: PLAN 파일과 실제 구현 상태가 불일치 (예: PLAN은 미완료인데 파일이 이미 존재). - -**동기화 복구 절차**: 파일 시스템 스캔으로 실제 상태 확인 → PLAN 파일과 비교 → 불일치 항목 표시 및 옵션 제공(① PLAN 자동 업데이트(권장) ② 기존 파일 덮어쓰기 ③ 수동 확인 후 진행). - -### 4. 빌드/테스트 실패 - -**상황**: 구현 완료 후 검증 단계에서 실패 (TypeScript 오류, 테스트 실패 등). 검증 결과를 항목별로 표시하고 자동 수정 가능한 오류는 수정 후 재검증합니다. - -**복구 흐름:** -``` -검증 실패 → 자동 수정 가능? ──Yes──→ 자동 수정 → 재검증 - ──No───→ 수동 수정 가이드 제공 → 사용자 수정 → "검증 재실행" 또는 "/auto-commit" -``` -수동 수정이 필요한 경우 해당 파일/라인과 권장 조치를 안내합니다. - -### 5. 작업 중단 및 재개 - -**상황**: 사용자가 작업 중단 또는 세션 종료. 진행 상태(기능, Phase, 완료 task 수, 마지막 저장 시각)를 PLAN 파일과 `.claude/session/implement_{feature}.json`에 저장합니다. - -- **재개**: 다음 세션에서 `/implement {feature}` 실행 → 자동으로 마지막 지점부터 재개. -- **처음부터**: `/implement {feature} --restart`. - -**재개 시 확인 사항**: PLAN 파일에서 마지막 완료 task 확인 → 실제 파일 상태와 비교 → 불일치 있으면 동기화 후 재개. - -### 6. 롤백 프로토콜 - -**상황**: 구현 결과가 기존 기능을 망가뜨림 (예: 기존 테스트 실패). 영향받은 테스트와 원인을 표시합니다. - -롤백 옵션: -1. **부분 롤백 (권장)** — 문제된 변경만 되돌리고 다른 구현은 유지 -2. **Phase 롤백** — 해당 Phase 전체 되돌려 이전 Phase 상태로 복원 -3. **전체 롤백** — `/implement` 시작 전 상태로 복원 (`git reset --hard HEAD~N`) -4. **수동 수정** — 영향받은 파일만 직접 수정 - -**롤백 실행 예:** -```bash -# Phase 단위 롤백 -git stash -m "implement_phase2_backup" -git checkout HEAD~3 -- src/services/AuthService.ts - -# 전체 롤백 -git reset --soft HEAD~N -git stash -``` - -### 7. 이슈 트래커 연동 오류 - -**상황**: Linear API 호출 실패 (인증 만료, 네트워크, 권한 부족 등). 실패 단계와 오류 메시지를 표시합니다. - -복구 옵션: ① 재시도(권장, 일시적 오류일 수 있음) ② 이슈 없이 원큐로 진행(이번 실행만 `--no-tracker`) ③ 중단(연동 문제 해결 후 재실행). 부분 생성된 이슈는 PLAN 파일에 기록되어 재실행 시 이어서 등록합니다(중복 생성 안 함). - -**원칙**: 이슈 트래커는 **보조 기능**입니다. 연동이 실패해도 구현 자체는 원큐 플로우로 계속 진행할 수 있어야 합니다 (Graceful Degradation). - -**중단/정리 시:** Linear MCP는 이슈 **하드삭제를 지원하지 않으므로** 취소·정리는 상태를 `Canceled`로 전환한다 (영구삭제는 Linear UI 휴지통). 중단 시점까지 부분 생성된 이슈는 PLAN의 `## Issue Tracker`에 기록되어 재실행 시 중복 생성을 막는다. +공통 원칙: 자동 복구 가능한 오류는 고쳐서 재검증하고, 불가능하면 오류·원인·해결책을 안내한다. 진행 상태는 PLAN 파일(+ `.claude/session/implement_{feature}.json`)에 저장되어 실패 지점부터 재개(`/implement {feature}` 또는 `--resume`)한다. -### Recovery Summary +1. **아키텍처 결정 실패**: 3회 재시도 → 실패 시 기본값(Modular Monolith, 가장 안전) 제안, 또는 수동 선택(Monolithic/Modular Monolith/MSA). +2. **Phase 중간 실패**: 자동 복구(의존성 누락→`npm/pip install`, 단순 타입 오류→수정 후 재컴파일, 린트→`code-formatter`, 포트 충돌→대체 포트). 불가능하면 수동 개입 안내. +3. **PLAN 파일 동기화 오류**: 파일 시스템 스캔으로 실제 상태 확인 → PLAN과 비교 → 불일치 항목 표시 및 옵션(PLAN 자동 업데이트(권장) / 덮어쓰기 / 수동 확인). +4. **빌드/테스트 실패**: 자동 수정 가능하면 수정 후 재검증, 아니면 파일/라인·권장 조치를 안내하고 사용자 수정 후 "검증 재실행" 또는 `/auto-commit`. +5. **작업 중단 및 재개**: 진행 상태 저장 → 다음 세션 `/implement {feature}`로 마지막 지점부터 재개, `--restart`로 처음부터. +6. **롤백**: 부분 롤백(권장, 문제 변경만) / Phase 롤백 / 전체 롤백(`git reset --hard HEAD~N`) / 수동 수정. +7. **이슈 트래커 연동 오류**: 재시도(권장) / 이슈 없이 원큐 진행(`--no-tracker`) / 중단. 부분 생성된 이슈는 PLAN `## Issue Tracker`에 기록되어 재실행 시 중복 생성 안 함. 취소·정리는 상태 `Canceled`로 전환(Linear는 하드삭제 미지원). -| 오류 유형 | 자동 복구 | 사용자 개입 | 롤백 가능 | -|----------|----------|------------|----------| -| 의존성 누락 | ✅ | - | - | -| 타입 오류 (단순) | ✅ | - | - | -| 타입 오류 (복잡) | - | ✅ | - | -| 테스트 실패 | - | ✅ | ✅ | -| 빌드 실패 | △ | ✅ | ✅ | -| 외부 서비스 오류 | - | ✅ | - | -| PLAN 불일치 | ✅ | - | - | -| 기존 기능 손상 | - | ✅ | ✅ | -| 이슈 트래커 연동 | △ (재시도) | ✅ | - | +**원칙 (Graceful Degradation)**: 이슈 트래커는 보조 기능이므로 연동이 실패해도 구현 자체는 원큐 플로우로 계속 진행한다. --- diff --git a/plugins/wigtn-plugins/commands/prd.md b/plugins/wigtn-plugins/commands/prd.md index 795d7fc..76b3a05 100644 --- a/plugins/wigtn-plugins/commands/prd.md +++ b/plugins/wigtn-plugins/commands/prd.md @@ -27,18 +27,7 @@ description: | ## Trigger Recognition -### 자연어 패턴 인식 - -사용자가 다음과 같은 패턴으로 말하면 PRD 생성을 시작합니다: - -| 패턴 | 예시 | -|------|------| -| "~하는거 만들고 싶어" | "로그인하는거 만들고 싶어" | -| "~하는 기능 필요해" | "결제하는 기능 필요해" | -| "~할 수 있게 해줘" | "사진 업로드할 수 있게 해줘" | -| "~하는 앱/사이트 만들어줘" | "쇼핑몰 사이트 만들어줘" | -| "아이디어가 있는데" | "아이디어가 있는데 들어볼래?" | -| "이런 거 가능해?" | "실시간 채팅 이런 거 가능해?" | +frontmatter의 자연어 트리거 패턴("~하는거 만들고 싶어", "~하는 기능 필요해", "아이디어가 있는데" 등)으로 기능 요청을 감지하면 PRD 생성을 시작하고, 문구에서 기능명을 추출한다. ### 복잡도 판단 @@ -330,19 +319,9 @@ flowchart TD ### Phase 3: API Specification Detail -PRD 내 API 명세는 다음 형식으로 **상세하게** 작성합니다. +PRD 내 API 명세는 **상세하게**(Request/Response/Error 포함) 작성한다. API 유형(REST / GraphQL / gRPC / WebSocket)은 요구사항에 맞게 선택한다. -**API 유형 선택:** -프로젝트 요구사항에 따라 적절한 API 형식을 선택합니다: - -| API 유형 | 적합한 경우 | 특징 | -|----------|-------------|------| -| **REST** | CRUD 작업, 리소스 기반 API | 범용적, 캐싱 용이 | -| **GraphQL** | 복잡한 데이터 관계, 프론트엔드 주도 | 유연한 쿼리, 오버페칭 방지 | -| **gRPC** | 마이크로서비스 간 통신, 고성능 필요 | 바이너리 프로토콜, 타입 안전 | -| **WebSocket** | 실시간 양방향 통신 | 지속 연결, 푸시 알림 | - -**상세 템플릿**: 선택한 API 유형의 상세 템플릿은 `${CLAUDE_PLUGIN_ROOT}/commands/references/prd-api-templates.md` 를 읽어서 사용한다. (REST / GraphQL / gRPC / WebSocket / OpenAPI 템플릿 + 로그인 예시 포함) +**상세 템플릿**: 선택한 유형의 템플릿·예시는 `${CLAUDE_PLUGIN_ROOT}/commands/references/prd-api-templates.md`를 읽어서 사용한다 (REST / GraphQL / gRPC / WebSocket / OpenAPI + 로그인 예시). 기본 REST 엔드포인트는 다음 골격만으로도 충분하다 (복잡한 경우만 위 참고 파일 로드): @@ -501,18 +480,14 @@ PRD 및 Task Plan 작성 완료 후 검증 결과 + **PRD에 FE 페이지 유무 ## Quality Checklist PRD 작성 후 확인: -- [ ] 목적이 명확하게 정의되었는가? -- [ ] 모든 사용자 스토리에 수용 기준이 있는가? +- [ ] 목적이 명확하고, 모든 사용자 스토리에 수용 기준이 있는가? - [ ] **§2.3 User Roles에 Role Key가 영문 문자열로 통일 선언되었는가?** -- [ ] Scale Grade(규모 등급)가 설정되었는가? -- [ ] SLA/SLO 기준(Performance, Availability)이 Scale Grade에 맞게 정의되었는가? -- [ ] 비기능 요구사항이 측정 가능한가? -- [ ] API 명세가 Request/Response/Error 모두 포함하는가? +- [ ] Scale Grade가 설정되고 SLA/SLO가 등급에 맞게 (측정 가능하게) 정의되었는가? +- [ ] API 명세가 Request/Response/Error를 모두 포함하는가? - [ ] **§5.4 Pages에 모든 페이지의 Audience/Auth/Linked FRs가 채워졌는가?** - [ ] **FE 페이지가 있으면 §5.4.1 Page State Matrix가 작성되었는가?** - [ ] **FE 페이지가 있으면 §5.5 User Flow (Mermaid)가 1개 이상 있는가?** -- [ ] 우선순위가 명확한가? -- [ ] 의존성이 식별되었는가? +- [ ] 우선순위와 FR 의존성이 명확한가? ## Integration Points @@ -553,48 +528,5 @@ PRD 작성 완료 시 자동으로 prd-reviewer 사용을 제안: ## Examples -### 새 프로젝트 PRD 생성 - -``` -입력: /prd 사용자 인증 - -분석: -- 프로젝트 구조 탐색 -- 기술 스택 확인 (Next.js, Prisma) - -생성: -- docs/prd/user-authentication.md 작성 -- FR-001 ~ FR-010 정의 -- API 엔드포인트 상세 설계 (Request/Response/Error) -- 데이터베이스 스키마 설계 - -다음 단계 안내: -→ "PRD 검토해줘" (prd-reviewer 에이전트) -→ "/implement 사용자 인증" -``` - -### 자연어 입력 처리 - -``` -입력: "로그인하는거 만들고 싶어" - -인식: -- 패턴 매칭: "~하는거 만들고 싶어" -- 기능 추출: "로그인" - -응답: -"로그인 기능을 만들어 드릴게요! - - 어떻게 진행할까요? - - 1. 📋 PRD 먼저 작성 (권장) - - 요구사항 정리 - - API 명세 설계 - - 구현 계획 수립 - - 2. ⚡ 바로 구현 - - 기본 JWT 인증으로 빠르게 구현 - - → PRD 작성: 'PRD 작성해줘' - → 바로 구현: '바로 만들어줘'" -``` +- **`/prd 사용자 인증`** → 프로젝트 구조·스택 분석 → PRD 작성(FR + API 상세 + 스키마) → 다음 단계 안내(prd-reviewer → `/implement`). +- **자연어 "로그인하는거 만들고 싶어"** → 기능명("로그인") 추출 → 복잡도 판단 후 "PRD 먼저 작성(권장) vs 바로 구현" 선택지 제시. diff --git a/plugins/wigtn-plugins/commands/review-pr.md b/plugins/wigtn-plugins/commands/review-pr.md index 43a62ae..e03a77b 100644 --- a/plugins/wigtn-plugins/commands/review-pr.md +++ b/plugins/wigtn-plugins/commands/review-pr.md @@ -9,15 +9,7 @@ GitHub Pull Request를 터미널에서 리뷰하고 피드백을 남깁니다. ## Pipeline Position -``` -┌─────────────────────────────────────────────────────────────┐ -│ [/prd] → [/implement] → [/auto-commit] → PR 생성 │ -│ ↓ │ -│ 동료: [/review-pr #123] │ -│ ↓ │ -│ 리뷰 결과 + 코멘트 │ -└─────────────────────────────────────────────────────────────┘ -``` +`[/prd] → [/implement] → [/auto-commit] → PR 생성` 이후, 동료가 `[/review-pr #123]`으로 리뷰 결과 + 코멘트를 남기는 단계. ## Usage @@ -85,26 +77,13 @@ gh pr view $PR_NUMBER --json comments,reviews | 3 (Deep) | 호출 체인, 에지 케이스, 보안 | `pr-reviewer` + `deep-review` 스킬 | | 4 (Architecture) | SOLID, 계층 위반, 확장성 | `pr-reviewer` + `architecture-review` 스킬 | -**병렬 리뷰 (Level 2+, 병렬 처리 이득이 클 때):** - -``` -┌──────────┐ ┌──────────┐ ┌──────────┐ -│ Agent A │ │ Agent B │ │ Agent C │ -│Read+Main │ │Perf+Test │ │BP+Securi │ -│ /40 │ │ /40 │ │ty /20+🔒 │ -└────┬─────┘ └────┬─────┘ └────┬─────┘ - └──────────────┼──────────────┘ - ▼ - ┌──────────────┐ - │ Score Merge │ - └──────────────┘ -``` +**병렬 리뷰 (Level 2+, 병렬 처리 이득이 클 때):** 3개 에이전트로 카테고리를 분담 — A(Readability+Maintainability /40), B(Performance+Testability /40), C(Best Practices /20 + Security 🔒) — 후 Score Merge로 병합. ### Step 3: 리뷰 결과 출력 #### Coverage-First 보고 -findings는 severity로 사전 필터링하지 않고 전량 보고한다. 각 finding에 `severity`(critical/major/minor/info)와 `confidence`(high/medium/low)를 함께 표기해, 취사선택·필터링은 하류(품질 게이트·사용자)에 맡긴다. recall 우선 — 리터럴 severity 컷으로 실제 버그를 누락시키지 않는다. +findings는 severity로 사전 필터링하지 않고 전량 보고하되 각 finding에 `severity`(critical/major/minor/info)와 `confidence`(high/medium/low)를 표기한다(recall 우선, 취사선택은 하류에 위임). ```markdown ## PR Review Result diff --git a/plugins/wigtn-plugins/commands/screen-spec.md b/plugins/wigtn-plugins/commands/screen-spec.md index 9831a35..3f8c966 100644 --- a/plugins/wigtn-plugins/commands/screen-spec.md +++ b/plugins/wigtn-plugins/commands/screen-spec.md @@ -19,13 +19,7 @@ PRD를 입력으로 받아 화면정의서 5종 산출물을 생성합니다. `/ ## Pipeline Position -``` -┌──────────────────────────────────────────────────────────────────────────┐ -│ [/prd] → [prd-reviewer] → [/screen-spec] → [/implement] → [/auto-commit] │ -│ ^^^^^^^^^^^^^^ │ -│ 현재 단계 │ -└──────────────────────────────────────────────────────────────────────────┘ -``` +`[/prd] → [prd-reviewer] → [/screen-spec] (현재 단계) → [/implement] → [/auto-commit]` | 이전 단계 | 현재 | 다음 단계 | |----------|------|----------| @@ -33,12 +27,7 @@ PRD를 입력으로 받아 화면정의서 5종 산출물을 생성합니다. `/ ## When to Use -| 조건 | `/screen-spec` 실행? | -|------|-------------------| -| PRD §5.4 Pages에 `Has FE Components: Yes` ≥1개 | ✅ 권장 | -| PRD가 백엔드/API 전용 | ❌ 스킵, 바로 `/implement` | -| PRD가 아직 없음 | ❌ 먼저 `/prd` 실행 | -| 빠른 PoC, 화면 1개 미만 | ⚠️ 생략 가능 | +PRD §5.4 Pages에 `Has FE Components: Yes` 행이 1개 이상일 때만 실행(권장). 백엔드/API 전용이면 스킵하고 바로 `/implement`, PRD가 없으면 먼저 `/prd`, 빠른 PoC(화면 1개 미만)면 생략 가능. ## Usage @@ -77,17 +66,7 @@ PRD를 입력으로 받아 화면정의서 5종 산출물을 생성합니다. `/ ### Phase 2: Interview (선택, `--interview` 플래그 시에만) -PRD가 다루지 않는 화면 레이어 의사결정을 끌어낸다. 단일 메시지에 5~7개 객관식 질문을 번호 매겨 제시하고 사용자 1회 응답을 받는다. - -| # | 질문 | 보기 | -|---|------|------| -| 1 | 네비게이션 패턴 | top / side / bottom / drawer | -| 2 | 정보 밀도 | compact / spacious | -| 3 | 에러 톤 | 공식적 / 친근한 | -| 4 | 빈 상태 철학 | 일러스트 + CTA / 최소 텍스트 + CTA | -| 5 | 전환 방식 | page / modal / drawer | -| 6 | 모바일 우선순위 | desktop-first / mobile-first / parity | -| 7 | 첫 화면 후크 | value-first / action-first / story-first | +PRD가 다루지 않는 화면 레이어 의사결정을 끌어낸다. 단일 메시지에 5~7개 객관식 질문을 번호 매겨 제시하고 사용자 1회 응답을 받는다 — 네비게이션 패턴(top/side/bottom/drawer), 정보 밀도(compact/spacious), 에러 톤, 빈 상태 철학, 전환 방식(page/modal/drawer), 모바일 우선순위(desktop-first/mobile-first/parity), 첫 화면 후크. 응답은 03-SCREEN-SPEC.md 작성 시 명시적으로 반영. 플래그가 없으면 PRD 추론만으로 진행. @@ -185,52 +164,9 @@ prd-reviewer가 §5.4.1 / §5.5 누락을 critical로 막아주면, `/screen-spe ## Examples -### 일반적인 웹앱 (FE 4페이지) - -``` -입력: /screen-spec - -분석: -- PRD §2.3: roles = [author, admin] -- PRD §5.4: FE 페이지 = [/, /submit, /my, /admin] (4개) -- PRD §5.4.1: /submit는 no-permission 상태 활성 - -생성: -- docs/prd/screens// - ├── 01-IA.md (4페이지 × 12 FR 매핑) - ├── 02-USER-FLOW.md (3개 플로우) - ├── 03-SCREEN-SPEC.md (4페이지 × 평균 5상태) - ├── 04-WIREFRAME.html (흑백 + 의미색, 1280px / 375px) - └── 05-DEV-HANDOFF.md - -frontend-developer 리뷰: PASS (WARN 1건: /admin 모바일 미정의 → 명시적 desktop-only 표기 권장) - -다음 단계 안내: -→ open docs/prd/screens//04-WIREFRAME.html -→ /implement -``` - -### 디테일 보강이 필요한 경우 - -``` -입력: /screen-spec --interview - -LOAD 직후 단일 메시지로 7개 질문 일괄 제시 → -사용자가 번호로 답변 → 03-SCREEN-SPEC.md 작성에 반영. -``` - -### 백엔드 전용 PRD - -``` -입력: /screen-spec - -분석: -- PRD §5.4: FE 페이지 0개 (모두 API/Job) - -차단: -"이 PRD는 백엔드 전용입니다. /screen-spec은 FE 페이지가 있을 때만 사용합니다. -→ /implement 으로 바로 진행하세요." -``` +- **`/screen-spec ` (FE 4페이지)** → §5.4 FE 페이지 감지 → 5종 산출물을 `docs/prd/screens//`에 생성 → frontend-developer 리뷰(PASS/WARN) → 와이어프레임 확인 + `/implement` 안내. +- **`--interview`** → LOAD 직후 5~7개 질문 일괄 제시 → 번호 답변 → 03-SCREEN-SPEC.md에 반영. +- **백엔드 전용 PRD** (§5.4 FE 페이지 0개) → 차단: "백엔드 전용입니다. `/implement `로 바로 진행하세요." ## Rules diff --git a/plugins/wigtn-plugins/hooks/hooks.json b/plugins/wigtn-plugins/hooks/hooks.json index 66f5e11..9f987d6 100644 --- a/plugins/wigtn-plugins/hooks/hooks.json +++ b/plugins/wigtn-plugins/hooks/hooks.json @@ -9,6 +9,15 @@ "command": "bash -c 'INPUT=$(cat); CMD=$(echo \"$INPUT\" | jq -r \".tool_input.command // empty\"); if echo \"$CMD\" | grep -qE \"rm\\s+-rf\\s+/|git\\s+push\\s+.*--force|git\\s+push\\s+.*-f\\s|git\\s+reset\\s+--hard|drop\\s+database|DROP\\s+TABLE\"; then echo \"BLOCKED: Dangerous command detected. Please confirm before executing: $CMD\" >&2; exit 2; fi'" } ] + }, + { + "matcher": "Bash", + "hooks": [ + { + "type": "command", + "command": "bash -c 'INPUT=$(cat); CMD=$(echo \"$INPUT\" | jq -r \".tool_input.command // empty\"); if echo \"$CMD\" | grep -qE \"git[[:space:]]+commit\" && echo \"$CMD\" | grep -q \"Quality Score:\"; then if [ -z \"$(find .wigtn/gate-pass -mmin -30 2>/dev/null)\" ]; then echo \"BLOCKED: WIGTN quality gate did not pass for this pipeline commit. The message contains a Quality Score: line but no fresh PASS verdict (.wigtn/gate-pass) was recorded. Run the /auto-commit quality gate so it writes the verdict, or use --no-review for an emergency hotfix (it omits the Quality Score line and bypasses this check).\" >&2; exit 2; fi; fi'" + } + ] } ], "PostToolUse": [