muno-claude-plugin 1.0.0

package/templates/skills/lld-generator/reference/lld-template.md

@@ -0,0 +1,286 @@
+# LLD 템플릿
+
+## 문서 구조 개요
+
+LLD는 다음 섹션으로 구성됩니다:
+
+| 섹션 | 필수 | 설명 |
+|------|:----:|------|
+| 1. Glossary | ✓ | 용어 정의 |
+| 2. Problem Statement | ✓ | 도메인별 기술적 난제 |
+| 3. Functional Requirements | ✓ | 기능 요구사항 |
+| 4. Non-Functional Requirements | ✓ | 성능/가용성 목표 |
+| 5. Goal / Non-Goal | ✓ | 설계 범위 명확화 |
+| 6. Proposed Design | ✓ | 도메인별 6가지 관점 설계 |
+| 7. Resilience & Reliability | ✓ | 공통 장애 대응 아키텍처 |
+| 8. Appendix | △ | 참고 문서 |
+
+**제외 항목**: ERD, 클래스 다이어그램, API 스펙 상세 (→ Task에서 작성)
+
+---
+
+## 전체 템플릿
+
+```markdown
+# [LLD] 기능명
+
+> **문서 정보**
+>
+> | 항목 | 내용 |
+> |------|------|
+> | 작성자 | @작성자 |
+> | 작성일 | YYYY-MM-DD |
+> | 상태 | Draft / Review / Approved |
+> | HLD | [HLD 문서 링크] |
+> | PRD | [PRD 문서 링크] |
+
+---
+
+## 1. Glossary
+
+| Term | Description |
+|------|-------------|
+| [용어1] | [정의] |
+| [용어2] | [정의] |
+| Hard Failure | 핵심 의존성 조회 실패로 인해 서비스 불능 상태가 된 경우 |
+| Soft Failure | 의존성의 조회 실패로 Default 값을 반환하여 기능이 심각하게 저하된 상태 |
+| SPOF | Single Point of Failure. 장애 시 Fail-fast 처리함 |
+| Default [Value] | 외부 시스템 장애 시 서비스 중단을 막기 위해 반환하는 사전 정의된 보수적 값 |
+
+---
+
+## 2. Problem Statement
+
+[시스템이 해결해야 할 핵심 문제와 기술적 도전 과제를 기술합니다.]
+
+[예시]
+> Core Promise System은 단일 상품 조회 시 P99 50ms, 최대 78,000 TPS라는 극한의 성능 목표를 달성해야 합니다.
+> 그러나 데이터를 처리할 때 범용적인 단일 아키텍처로는 각기 다른 특성을 가진 데이터 도메인들을 효율적으로 처리하는 데 구조적 한계가 있습니다.
+
+### 도메인별 기술적 난제 매트릭스
+
+| 도메인 | 데이터 특성 | 주요 기술적 난제 | 미해결 시 영향 (Impact) |
+|--------|------------|-----------------|------------------------|
+| [도메인1] | [특성: 변동성, 크기, 조회 패턴] | [난제] | [비즈니스 영향] |
+| [도메인2] | [특성] | [난제] | [비즈니스 영향] |
+| [도메인3] | [특성] | [난제] | [비즈니스 영향] |
+
+**작성 팁**:
+- 데이터 특성: 초고변동성, 대용량, Read-Heavy, 외부 소유 등
+- 기술적 난제: 캐싱 불가, Latency vs Consistency, Fan-out 처리, 통제 불가능한 Latency 등
+- 미해결 시 영향: 오판매, 과도한 인프라 비용, 장애 전파 등 **비즈니스 관점**으로 기술
+
+---
+
+## 3. Functional Requirements
+
+| Type | Requirement | Description |
+|------|-------------|-------------|
+| Must-have | [요구사항명] | [상세 설명] |
+| Must-have | [요구사항명] | [상세 설명] |
+| Must-have | Fail-fast ([의존성]) | [SPOF 시스템] 조회 실패 시 즉시 에러 처리하여 [비즈니스 리스크]를 원천 차단 |
+| Must-have | Fallback (Non-Critical) | [비SPOF 시스템] 장애 시 주문 흐름을 막지 않고 Default 값 반환 |
+| nice-to-have | [요구사항명] | [상세 설명] |
+
+---
+
+## 4. Non-Functional Requirements
+
+### 4.1. Performance & Scalability
+
+| Component | Type | Requirement |
+|-----------|------|-------------|
+| [컴포넌트1] 조회 API | Latency | P99 [X]ms 이하 |
+| [컴포넌트2] 조회 API | Latency | P99 [X]ms 이하 |
+| System Total | Throughput | Target [X] TPS |
+| System Total | Scalability | 트래픽 급증 시 수평 확장(Scale-out) 지원 |
+
+**TPS 산출 근거**:
+```
+현재 피크 * 연간 기대 성장률^(years)
+예: 66,000 * 1.2^3 = 114,000 TPS
+```
+
+### 4.2. Availability & Reliability
+
+| Metric | Threshold | Action |
+|--------|-----------|--------|
+| Hard Failure | HTTP 5xx > [X]% ([의존성]) | 즉시 장애 간주 (SLA 차감), Fail-fast |
+| Soft Failure | Default 반환율 ≥ [X]% | 장애 간주 (SLA 차감), 심각한 품질 저하로 판단 |
+| Degradation | Default 반환율 < [X]% | 정상 가동 간주 (SLA 차감 X), Alert 발송 |
+| Data Consistency | [도메인1] 변경 반영 | [X]분/초 이내 반영 |
+| Data Consistency | [도메인2] 변경 반영 | [X]ms 이내 반영 |
+
+---
+
+## 5. Goal / Non-Goal
+
+### 5.1. Goal: [목표 제목]
+
+본 설계의 최우선 목적은 [핵심 목표]입니다.
+
+- **[세부 목표1]**: [상세 설명]
+- **[세부 목표2]**: [상세 설명]
+- **[세부 목표3]**: [상세 설명]
+
+### 5.2. Non-Goal: [제외 범위 제목]
+
+[포함하지 않는 범위]에 집중하며, [제외하는 내용]은 본 설계의 범위에서 제외합니다.
+
+- **[제외1]**: [이유]
+- **[제외2]**: [이유]
+- **[제외3]**: [이유]
+
+---
+
+## 6. Proposed Design: [전략명]
+
+[전체 아키텍처 다이어그램 - Mermaid 또는 이미지]
+
+### 도메인별 서빙 전략 요약
+
+| 도메인 | 원천/주 저장소 | 서빙 전략 | 프로토콜 | 동기화 방식 | 장애 대응 전략 |
+|--------|--------------|----------|---------|------------|--------------|
+| [도메인1] | [저장소] | [전략] | [프로토콜] | [방식] | [Hard/Soft Failure] |
+| [도메인2] | [저장소] | [전략] | [프로토콜] | [방식] | [Hard/Soft Failure] |
+| [도메인3] | [저장소] | [전략] | [프로토콜] | [방식] | [Hard/Soft Failure] |
+
+---
+
+### 6.1. [도메인1] 조회 아키텍처: [전략명]
+
+[도메인 설명 - 왜 이 도메인이 중요한지]
+
+#### Challenge (제약 사항)
+
+- **[제약1]**: [상세 설명]
+- **[제약2]**: [상세 설명]
+- **[제약3]**: [상세 설명]
+
+#### Serving Strategy (조회 전략)
+
+- **[전략명]**: [상세 설명]
+- **[최적화1]**: [상세 설명]
+- **[최적화2]**: [상세 설명]
+
+#### Data Synchronization (데이터 동기화)
+
+- **[동기화 방식]**: [상세 설명]
+- 따라서 [결론]
+
+#### Consistency Guarantee (정합성 목표)
+
+- **[정합성 수준]**: [상세 설명 - Strong/Eventual Consistency, NRT 등]
+
+#### Key Technology (기술 스택)
+
+| 항목 | 기술 | 설명 |
+|------|------|------|
+| Protocol | [프로토콜] | [선택 이유] |
+| Serialization | [직렬화 방식] | [선택 이유] |
+| Load Balancer | [LB 방식] | [선택 이유] |
+
+#### Resilience & Fallback (장애 대응)
+
+- **[시나리오1]**: [대응 방안]
+- **[시나리오2]**: [대응 방안]
+
+---
+
+### 6.2. [도메인2] 조회 아키텍처: [전략명]
+
+[위와 동일한 구조로 작성]
+
+---
+
+### 6.3. [도메인3] 조회 아키텍처: [전략명]
+
+[위와 동일한 구조로 작성]
+
+---
+
+## 7. Resilience & Reliability Architecture (공통 장애 대응 아키텍처)
+
+개별 시스템의 전략을 넘어, 시스템 전체가 장애 상황에서 어떻게 생존할 것인지를 정의하는 계층적 방어(Tiered Defense) 구조입니다.
+
+### 7.1. 장애 등급 정의
+
+| 장애 등급 | 정의 | 판단 기준 (Threshold) | 대응 및 SLA 반영 |
+|----------|------|----------------------|-----------------|
+| Hard Failure (가용성 장애) | 서비스가 불능이거나 핵심 의존성이 실패한 상태 | HTTP 5xx Error > [X]% (5분 평균) / [SPOF 시스템] 조회 실패 | 즉시 장애 간주 (SLA 차감), Fail-fast |
+| Soft Failure (기능적 장애) | API는 정상 응답(200 OK)하나 데이터 누락으로 Default 값이 반환된 상태 | Default 반환율 ≥ [X]% (Critical Threshold) | 장애 간주 (SLA 차감), [X]% 이상 대량 발생은 시스템적 결함으로 판단 |
+| Degradation (품질 저하) | 간헐적인 데이터 누락으로 Default 값이 소량 반환된 상태 | Default 반환율 < [X]% (Warning Threshold) | 정상 가동 간주 (SLA 차감 X), Alert만 발송 |
+
+**가용성 지표 정의**:
+> 우리는 "서버가 켜져 있는가"가 아니라 "고객에게 유효한 응답을 주었는가"를 가용성의 기준으로 삼습니다.
+> 따라서 가용성 지표 산정 시 [X]%를 초과하는 Soft Failure를 다운타임에 포함합니다.
+
+```
+Availability = (전체 요청 - (Hard failure + Soft failure)) / 전체 요청
+```
+
+### 7.2. 의존성 시스템별 장애 대응 매트릭스
+
+| 의존 시스템 | 데이터 특성 | 실패 시 시스템 상태 | 대응 전략 (Action) | 근거 |
+|------------|-----------|-------------------|-------------------|------|
+| [시스템1] | [특성: 실시간성, 변동성 등] | Hard Failure (장애) | Fail-fast 또는 전면 차단 | [비즈니스 근거] |
+| [시스템2] | [특성] | Soft Failure (저하) | Local Cache → Default 반환 | [근거] |
+| [시스템3] | [특성] | Soft Failure (저하) | Redis → DB → Default 반환 | [근거] |
+
+### 7.3. Circuit Breaker 및 Fallback 정책
+
+- **[SPOF 시스템]**: Circuit Open 시 Fail-fast. 계산을 중단하고 즉시 장애를 전파합니다.
+- **[Non-Critical 시스템]**: Circuit Open 시 Fallback 모드 진입. 1차로 로컬 캐시를 확인하고, 실패 시 Default 값을 반환합니다.
+
+### 7.4. 사전 정의된 Default 값
+
+각종 예외나 시스템 failure로 인한 비정상 상태에서 서비스 중단을 막기 위해 fallback으로 제공할 default 값입니다.
+
+**Default [Object] (TBU)**:
+
+| 항목 | 값 | 설명 |
+|------|-----|------|
+| [필드1] | [값] | [설명] |
+| [필드2] | [값] | [설명] |
+| [필드3] | [값] | [설명] |
+
+---
+
+## 8. Appendix
+
+### 8.1. 참고 문서
+
+1. [문서1 제목과 링크]
+2. [문서2 제목과 링크]
+3. [문서3 제목과 링크]
+
+### 8.2. 관련 LLD
+
+- [관련 LLD 1]
+- [관련 LLD 2]
+```
+
+---
+
+## 저장 경로
+
+`documents/lld/{기능명}-lld.md`
+
+예시:
+- `documents/lld/promise-data-strategy-lld.md`
+- `documents/lld/order-processing-lld.md`
+
+---
+
+## 도메인별 6가지 관점 작성 가이드
+
+각 도메인 섹션에서 반드시 다뤄야 할 6가지 관점입니다:
+
+| 관점 | 질문 | 예시 |
+|------|------|------|
+| **Challenge** | 이 도메인이 직면한 기술적 제약은? | "초고변동성으로 캐싱 불가", "Fan-out 트래픽 처리" |
+| **Serving Strategy** | 데이터를 어떻게 서빙할 것인가? | "Direct RPC Call", "Redis-Centric CQRS", "Data Serving Layer" |
+| **Data Sync** | 원천 데이터와 어떻게 동기화? | "Real-time", "Worker/Polling", "Event-Driven" |
+| **Consistency** | 어느 수준의 정합성을 보장? | "Strong Consistency", "NRT < 10s", "Eventual < 5min" |
+| **Key Technology** | 어떤 기술을 사용? | "gRPC + Protobuf", "Redis Cluster", "Kafka" |
+| **Resilience** | 장애 시 어떻게 대응? | "Fail-fast", "Tiered Defense", "Circuit Breaker" |

package/templates/skills/prd-generator/SKILL.md

@@ -0,0 +1,352 @@
+---
+name: prd-generator
+description: |
+  간단한 아이디어나 기능 요청을 표준 PRD(Product Requirements Document)로 구체화합니다.
+  "PRD 작성해줘", "기획서 만들어줘", "이 기능 PRD로 정리해줘", "제품 요구사항 문서 작성",
+  "기획 문서 만들어줘", "요구사항 정의서 작성", "이 아이디어 PRD로" 등의 요청에 사용합니다.
+  PRD는 HLD(High Level Design) 작성의 입력 문서가 됩니다.
+  사용자의 요청만으로 알아서 작성하지 않고, 질문을 통해 충분한 정보를 수집한 후 작성합니다.
+allowed-tools: Read, Glob, Grep, Write, Edit, WebSearch, WebFetch
+---
+
+# PRD Generator
+
+## 페르소나
+
+@.claude/personas/po.md
+
+> **PRD의 역할**: "무엇을(What)"과 "왜(Why)"를 정의합니다.
+> "어떻게(How)" 구현할지는 HLD/LLD에서 다룹니다.
+
+---
+
+## 문서 체계
+
+```
+PRD (What & Why)     →  HLD (How-개략)     →  LLD (How-상세)
+─────────────────────────────────────────────────────────────
+• 문제 정의              • 시스템 아키텍처       • API 스펙
+• 비즈니스 목표          • 컴포넌트 구조         • DB 스키마
+• 사용자 요구사항        • 기술 스택 선정        • 시퀀스 다이어그램
+• 성공 지표              • 시스템 간 연동        • 에러 처리
+• 범위 정의              • 트레이드오프 분석     • 상세 구현
+```
+
+---
+
+## 워크플로우
+
+```mermaid
+flowchart TD
+    A[사용자 요청] --> B[Step 1: 문제/배경 파악]
+    B --> C{정보 충분?}
+    C -->|No| D[보충 질문 2-3개]
+    D --> E[사용자 응답]
+    E --> C
+    C -->|Yes| F[Step 2: 목표/지표 파악]
+    F --> G{정보 충분?}
+    G -->|No| H[보충 질문 2-3개]
+    H --> I[사용자 응답]
+    I --> G
+    G -->|Yes| J[Step 3: 요구사항/범위 파악]
+    J --> K{정보 충분?}
+    K -->|No| L[보충 질문 2-3개]
+    L --> M[사용자 응답]
+    M --> K
+    K -->|Yes| N[Step 4: PRD 작성]
+    N --> O[사용자 검토 요청]
+    O -->|수정| N
+    O -->|승인| P[저장: documents/feature/NAME/PRD.md]
+```
+
+---
+
+## Step 1: 문제/배경 파악
+
+### 수집해야 할 정보
+- 해결하려는 문제가 무엇인가?
+- 현재 상황(As-Is)은 어떠한가?
+- 문제의 규모는? (빈도, 손실액, 영향 받는 사용자 수)
+- 이 문제로 인한 비즈니스 영향은?
+
+### 질문 예시 (한 번에 2-3개)
+```
+1. "이 문제가 구체적으로 어떤 상황에서 발생하나요?"
+2. "현재 이 문제로 인해 어떤 영향(손실, 불편)이 있나요?"
+3. "대략적인 규모를 알 수 있을까요? (발생 빈도, 영향 받는 사용자 수 등)"
+```
+
+### 정보가 충분한 기준
+- [ ] 현재 상황이 구체적으로 기술됨
+- [ ] 문제가 정량화됨 (숫자 포함)
+- [ ] 비즈니스 영향이 명확함
+
+---
+
+## Step 2: 목표/지표 파악
+
+### 수집해야 할 정보
+- 이 프로젝트의 성공 기준은 무엇인가?
+- 어떤 지표가 개선되어야 하는가? (Before → After)
+- 어떻게 측정할 것인가?
+
+### 질문 예시 (한 번에 2-3개)
+```
+1. "이 문제가 해결되면 어떤 지표가 개선될까요?"
+2. "현재 수치와 목표 수치를 알 수 있을까요?"
+3. "성공/실패를 어떻게 판단할 수 있을까요?"
+```
+
+### 정보가 충분한 기준
+- [ ] 핵심 지표가 정의됨 (1-3개)
+- [ ] Before/After 수치가 있음
+- [ ] 측정 방법이 명확함
+
+---
+
+## Step 3: 요구사항/범위 파악
+
+### 수집해야 할 정보
+- 핵심 사용자(페르소나)는 누구인가?
+- 필수 기능(Must-have)은 무엇인가?
+- 제외할 기능(Out-of-Scope)은 무엇인가?
+- 비즈니스 제약 조건은? (일정, 예산, 인력)
+
+### 질문 예시 (한 번에 2-3개)
+```
+1. "이 기능의 핵심 사용자는 누구인가요? (연령, 직업, 특성)"
+2. "이번 버전에 반드시 포함되어야 할 기능은 무엇인가요?"
+3. "명시적으로 제외하거나 나중으로 미뤄야 할 것이 있나요?"
+4. "일정이나 예산 등 제약 조건이 있나요?"
+```
+
+### 정보가 충분한 기준
+- [ ] 핵심 사용자가 정의됨
+- [ ] 필수 기능이 3-5개로 정리됨
+- [ ] In-Scope/Out-of-Scope가 구분됨
+
+---
+
+## Step 4: PRD 작성
+
+모든 정보가 수집되면 아래 구조로 PRD를 작성합니다.
+
+### PRD 구조
+
+```markdown
+---
+document_type: PRD
+version: 1.0.0
+status: draft
+created_at: YYYY-MM-DD
+owner: [작성자]
+---
+
+# [PRD] 기능명
+
+## 1. Executive Summary
+[한 문단 요약 - 무엇을, 왜, 누구를 위해]
+
+## 2. Background & Problem
+
+### 현재 상황 (As-Is)
+- [현재 프로세스/시스템 설명]
+- [관련 데이터]
+
+### 문제
+1. **[문제 1]**: [정량적 규모]
+2. **[문제 2]**: [정량적 규모]
+
+### 비즈니스 영향
+- 정량적: [월/연 손실액]
+- 정성적: [사용자 불만, 경쟁 열위 등]
+
+## 3. Objectives & Success Metrics
+
+### 핵심 목표
+1. [목표 1]: X → Y
+
+### Success Metrics
+| 지표 | 현재 | 목표 | 측정 방법 |
+|------|------|------|----------|
+| [지표1] | [X] | [Y] | [방법] |
+
+## 4. Target Users
+
+### Primary Persona
+- **인구통계**: [연령, 성별, 직업]
+- **행동 특성**: [서비스 사용 패턴]
+- **Pain Point**: [겪고 있는 불편함]
+
+## 5. Requirements
+
+### User Stories
+1. [사용자]로서, [기능]을 원한다, [목적] 때문에
+
+### Key Features
+1. **[기능명]**: [설명]
+
+## 6. Scope
+
+### ✅ In-Scope
+- [포함 항목]
+
+### ❌ Out-of-Scope
+- [제외 항목] - 이유: [이유]
+
+### 🔮 Future
+- [향후 검토 항목]
+
+## 7. Constraints
+- 비즈니스 제약: [일정, 예산, 인력]
+- 규정 제약: [개인정보보호, 법적 요건]
+
+## 8. Risks
+| 위험 | 영향 | 완화 방안 |
+|------|------|----------|
+| [위험] | [영향] | [대응] |
+
+---
+**다음 단계**: HLD 작성
+```
+
+---
+
+## 금지 사항
+
+### ❌ 절대 하지 말 것
+
+1. **정보 없이 추측하여 작성 금지**
+   ```
+   ❌ 사용자가 "로그인 기능 PRD 써줘"라고 하면 바로 작성
+   ✅ "어떤 문제를 해결하려는 건가요?" 질문부터 시작
+   ```
+
+2. **솔루션부터 제시 금지**
+   ```
+   ❌ "챗봇 기능이 필요합니다"
+   ✅ "고객 문의 응답 시간이 평균 2시간 지연됩니다"
+   ```
+
+3. **모호한 표현 금지**
+   ```
+   ❌ "빠르게", "많이", "개선", "최적화"
+   ✅ "3초 이내", "30% 증가", "32% → 70%"
+   ```
+
+4. **기술 구현 상세 금지** (HLD/LLD 영역)
+   ```
+   ❌ "Spring AI로 구현", "Redis 캐싱 적용", "REST API 설계"
+   ✅ "AI 기반 추천 필요", "빠른 응답 필요"
+   ```
+
+5. **범위 없는 PRD 금지**
+   ```
+   ❌ "모든 필요한 기능 구현"
+   ✅ In-Scope 5개, Out-of-Scope 3개 명시
+   ```
+
+---
+
+## Good/Bad 예시
+
+### 배경 및 문제
+
+```markdown
+# ✅ Good
+## 현재 상황
+사용자는 패션 추천을 받기 위해 8개 질문에 답변해야 하며,
+평균 완료 시간은 3분 30초입니다.
+
+## 문제
+- 높은 이탈률: 68%가 온보딩 중 이탈
+- 월 손실: 4,500명 잠재 고객 손실 (추정 ₩15,000,000)
+
+# ❌ Bad
+사용자가 질문에 답하는 게 너무 오래 걸립니다.
+그래서 간편한 온보딩이 필요합니다.
+→ 문제 정량화 없음, 솔루션 먼저 제시
+```
+
+### 목표
+
+```markdown
+# ✅ Good
+| 지표 | 현재 | 목표 | 측정 방법 |
+|------|------|------|----------|
+| 온보딩 완료율 | 32% | 70%+ | GA4 funnel |
+| 완료 시간 | 3분 30초 | 1분 이내 | 세션 로그 |
+
+# ❌ Bad
+- 사용자 경험 개선
+- 더 많은 사람들이 서비스를 사용하도록
+→ 측정 불가능, Before/After 없음
+```
+
+### User Story
+
+```markdown
+# ✅ Good
+"패션 초보 사용자로서,
+사진 몇 장만 선택해서 스타일 프로필을 완성하고 싶다,
+복잡한 질문에 답하지 않아도 되도록"
+
+# ❌ Bad
+"사용자는 프로필을 만들 수 있어야 한다"
+→ 동기/맥락 없음
+```
+
+### Scope
+
+```markdown
+# ✅ Good
+**In-Scope**
+- 이미지 기반 스타일 선택 (4개)
+- 간소화된 체형 입력 (3개 필드)
+
+**Out-of-Scope**
+- 음성 입력 (기술 검증 필요, v2.0)
+- SNS 연동 (우선순위 낮음)
+
+# ❌ Bad
+- 온보딩 개선
+- 필요한 기능 추가
+→ 구체성 없음, 경계 불명확
+```
+
+---
+
+## 체크리스트
+
+### 정보 수집 완료 확인
+- [ ] 문제가 정량화되어 있는가?
+- [ ] 목표 지표가 Before/After로 정의되어 있는가?
+- [ ] 핵심 사용자가 구체적으로 정의되어 있는가?
+- [ ] In-Scope/Out-of-Scope가 명확한가?
+
+### PRD 작성 완료 확인
+- [ ] 솔루션 없이 문제가 독립적으로 기술되었는가?
+- [ ] 모든 지표가 측정 가능한가?
+- [ ] User Story가 "~로서, ~하고 싶다, ~ 때문에" 형식인가?
+- [ ] 기술 구현 상세가 포함되지 않았는가?
+- [ ] 비개발자도 이해 가능한가?
+
+---
+
+## 산출물
+
+**저장 위치**: `documents/feature/<feature-name>/PRD.md`
+
+**사용자 검토**: PRD 작성 후 반드시 사용자에게 검토 요청
+```
+PRD 초안을 작성했습니다. 검토 후 수정이 필요하면 말씀해주세요.
+승인되면 저장하고 HLD 작성으로 넘어갑니다.
+```
+
+---
+
+## 관련 스킬
+
+- `/skill:hld-generator`: PRD 기반 High Level Design 생성
+- `/skill:lld-generator`: HLD 기반 Low Level Design 생성
+- `/skill:design-orchestrator`: PRD-HLD-LLD 연계 관리