muno-claude-plugin 1.4.0 → 1.4.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "muno-claude-plugin",
-  "version": "1.4.0",
+  "version": "1.4.2",
   "description": "Unleash Claude Code's full power - Complete development workflow with expert personas, TDD-based agents, and automated documentation",
   "main": "bin/cli.js",
   "bin": {

package/templates/WORKFLOW.md

@@ -11,9 +11,10 @@ AI 기반 개발 워크플로우 스킬 체계입니다.
 
 | 스킬 | 설명 | 주요 입력 |
 |------|------|----------|
+| `/architecture` | System Architecture (SAD) | 시스템 정보 |
 | `/prd-generator` | PRD 생성 | 요구사항 |
 | `/epic-story-generator` | Epic & Story 생성 | PRD (선택) |
-| `/hld-generator` | High-Level Design | PRD + Epic/Story |
+| `/hld-generator` | Feature HLD | SAD + PRD + Story |
 | `/lld-generator` | Low-Level Design | HLD |
 | `/task-generator` | Implementation Task | Story + LLD |
 | `/tc-generator` | Test Case 생성 | Story AC |
@@ -74,9 +75,14 @@ AI 기반 개발 워크플로우 스킬 체계입니다.
 ```
 project/
 ├── documents/
-│   ├── prd/          # PRD 문서
-│   ├── hld/          # HLD 문서
-│   └── lld/          # LLD 문서
+│   ├── architecture/
+│   │   └── system-architecture.md   ← SAD (1개, 지속 업데이트)
+│   ├── prd/
+│   │   └── feature-prd.md
+│   ├── hld/
+│   │   └── feature-hld.md           ← Feature HLD (피처별)
+│   └── lld/
+│       └── feature-lld.md
 │
 ├── backlogs/         # Epic/Story
 │   └── feature-name/

package/templates/agents/workflow-navigator.md

@@ -20,12 +20,35 @@ color: cyan
 
 현재 프로젝트 상황을 분석하여 **다음 워크플로우를 제안**합니다.
 - 정적인 워크플로우를 강제하지 않음
-- 복잡도와 상황에 따라 유연하게 판단
+- **복잡도 + 변경 규모 + 기존 문서 커버리지**를 종합 판단
 - 불필요한 단계는 건너뛰기 제안
 
 ---
 
-## 복잡도 레벨 정의
+## 판단 기준: 3가지 축
+
+워크플로우 결정은 **복잡도**, **변경 규모**, **기존 문서 커버리지** 3가지를 종합 판단합니다.
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                    워크플로우 판단 매트릭스                        │
+├─────────────────────────────────────────────────────────────────┤
+│                                                                 │
+│   [축 1] 복잡도 (Complexity)                                     │
+│   └─ 기술적 난이도, 아키텍처 영향                                  │
+│                                                                 │
+│   [축 2] 변경 규모 (Scale)                                       │
+│   └─ 영향 범위, 파일/모듈/팀 수                                   │
+│                                                                 │
+│   [축 3] 기존 문서 커버리지 (Coverage)                            │
+│   └─ 기존 HLD/LLD가 새 변경을 커버하는지                          │
+│                                                                 │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 축 1: 복잡도 레벨 정의
 
 | Level | 설명 | 예시 |
 |-------|------|------|
@@ -37,6 +60,68 @@ color: cyan
 
 ---
 
+## 축 2: 변경 규모 (Scale)
+
+| 규모 | 기준 | 예시 |
+|------|------|------|
+| **S (Small)** | 파일 1-5개, 단일 모듈 | 버그 수정, 단일 API 변경 |
+| **M (Medium)** | 파일 6-20개, 2-3개 모듈 | 새 기능, 모듈 내 리팩토링 |
+| **L (Large)** | 파일 20개+, 4개+ 모듈 | 크로스커팅 변경, 대규모 리팩토링 |
+| **XL (Extra Large)** | 전체 시스템, 다중 팀 | 아키텍처 전환, 플랫폼 마이그레이션 |
+
+### 규모가 크면 복잡도와 무관하게 문서 필요
+
+```
+단순하지만 규모가 큰 경우 (예: 전체 API에 rate limiting 추가)
+├─ 복잡도: L2 (단일 패턴 적용)
+├─ 규모: L (20개+ 파일, 모든 API)
+└─ 결론: HLD 필요 (일관성 확보, 리뷰 용이)
+```
+
+---
+
+## 축 3: 기존 문서 커버리지 (Coverage)
+
+### 기존 HLD 커버리지 체크
+
+```
+기존 HLD가 있을 때, 새 변경이 다음에 해당하면 HLD 업데이트 필요:
+- [ ] 새 컴포넌트/서비스 추가
+- [ ] 기존 컴포넌트 간 연동 방식 변경
+- [ ] 데이터 흐름 변경
+- [ ] 기술 스택 추가/변경
+
+하나라도 해당 → HLD 업데이트 또는 신규 작성
+```
+
+### 기존 LLD 커버리지 체크
+
+```
+기존 LLD가 있을 때, 새 변경이 다음에 해당하면 LLD 업데이트 필요:
+- [ ] 새 데이터 서빙 전략
+- [ ] 새 외부 의존성 추가
+- [ ] 장애 대응 전략 변경
+- [ ] 성능 요구사항 변경
+
+하나라도 해당 → LLD 업데이트 또는 신규 작성
+```
+
+---
+
+## 복합 판단 매트릭스
+
+| 복잡도 | 규모 | 기존 문서 커버 | 권장 워크플로우 |
+|--------|------|---------------|----------------|
+| L1-L2 | S | - | 바로 구현 |
+| L1-L2 | M-L | - | Task 분해 필요, HLD 선택적 |
+| L1-L2 | L-XL | - | **HLD 필요** (규모로 인한 조정 필요) |
+| L3 | S-M | 커버됨 | Story → Task |
+| L3 | S-M | 커버 안됨 | Story → LLD 업데이트 → Task |
+| L3 | L-XL | - | **HLD 필요** → LLD → Task |
+| L4-L5 | - | - | PRD → Epic/Story → HLD → LLD → Task |
+
+---
+
 ## 레벨별 권장 워크플로우
 
 ### L1~L2: 단순 작업
@@ -152,17 +237,21 @@ color: cyan
 # 워크플로우 분석
 
 ## 현재 상태
-| 문서 | 상태 |
-|------|------|
-| PRD | ✅ 있음 / ❌ 없음 |
-| Epic/Story | ✅ 있음 / ❌ 없음 |
-| HLD | ✅ 있음 / ❌ 없음 / ⏭️ 건너뛰기 |
-| LLD | ✅ 있음 / ❌ 없음 / ⏭️ 건너뛰기 |
-| Task | ✅ 있음 / ❌ 없음 |
-| TC | ✅ 있음 / ❌ 없음 |
-
-## 복잡도 판단
-**Level: L[N]** - [설명]
+| 문서 | 상태 | 커버리지 |
+|------|------|----------|
+| PRD | ✅/❌ | - |
+| Epic/Story | ✅/❌ | - |
+| HLD | ✅/❌/⏭️ | 커버됨/커버 안됨/해당없음 |
+| LLD | ✅/❌/⏭️ | 커버됨/커버 안됨/해당없음 |
+| Task | ✅/❌ | - |
+| TC | ✅/❌ | - |
+
+## 판단 결과
+| 축 | 판단 | 근거 |
+|----|------|------|
+| 복잡도 | L[N] | [이유] |
+| 규모 | S/M/L/XL | 파일 N개, 모듈 N개 |
+| 커버리지 | 커버됨/안됨 | [기존 문서 상태] |
 
 ## 다음 스텝 제안
 1. **[권장]** `/skill-name` - [이유]
@@ -170,6 +259,9 @@ color: cyan
 
 ## 건너뛸 수 있는 단계
 - [단계명]: [건너뛰기 가능 이유]
+
+## 주의사항 (해당 시)
+- [규모가 커서 HLD 필요] 또는 [기존 문서 커버 안됨]
 ```
 
 ---
@@ -226,6 +318,8 @@ color: cyan
 
 분석 결과:
 - 복잡도: L5 (신규 시스템)
+- 규모: XL (새 시스템)
+- 커버리지: 해당 없음 (신규)
 - PRD: 필수 (이해관계자 합의 필요)
 - Epic/Story: 필수
 - HLD: 필수 (새 아키텍처)
@@ -236,6 +330,37 @@ color: cyan
 2. [이후 순서] Epic/Story → HLD → LLD → Task
 ```
 
+### 예시 5: 단순하지만 규모가 큰 경우
+```
+사용자: "모든 API 엔드포인트에 rate limiting 추가"
+
+분석 결과:
+- 복잡도: L2 (동일 패턴 반복 적용)
+- 규모: L (30개+ API, 전체 모듈 영향)
+- 커버리지: 기존 HLD에 rate limiting 미포함
+
+제안:
+1. [권장] `/hld-generator` - rate limiting 전략 문서화
+   - 규모가 커서 일관성 확보 필요
+   - 리뷰 및 합의 용이
+2. [이후] `/task-generator` - 모듈별 Task 분해
+```
+
+### 예시 6: 기존 HLD 커버 안 되는 경우
+```
+사용자: "기존 채팅 시스템에 WebSocket → gRPC 스트리밍으로 변경"
+
+분석 결과:
+- 복잡도: L3 (프로토콜 변경)
+- 규모: M (채팅 모듈 내)
+- 커버리지: 기존 HLD는 WebSocket 기반으로 작성됨 → 커버 안 됨
+
+제안:
+1. [권장] `/hld-generator` - HLD 업데이트 (gRPC 스트리밍 아키텍처)
+2. [이후] `/lld-generator` - 상세 설계
+3. [이후] `/task-generator` - 구현 Task
+```
+
 ---
 
 ## 자동 호출 조건

package/templates/commands/architecture.md

@@ -0,0 +1,5 @@
+${{skill:architecture}}
+
+---
+
+System Architecture Document 생성/업데이트 스킬이 활성화되었습니다.

package/templates/skills/architecture/SKILL.md

@@ -0,0 +1,442 @@
+---
+name: architecture
+description: |
+  전체 시스템 아키텍처 문서(SAD)를 생성하거나 업데이트합니다.
+  SAD는 시스템의 큰 그림을 담는 단일 문서로, 피처 HLD의 기반이 됩니다.
+  "아키텍처 문서 만들어줘", "시스템 구조", "전체 아키텍처" 등의 요청에 사용합니다.
+allowed-tools: Read, Glob, Grep, Write, Edit, WebSearch, WebFetch
+---
+
+# System Architecture Generator
+
+## 페르소나
+
+@.claude/personas/principal-engineer.md
+
+---
+
+## SAD란?
+
+**System Architecture Document (SAD)**는 전체 시스템의 큰 그림을 담는 **단일 문서**입니다.
+
+### SAD vs Feature HLD
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│  SAD (System Architecture Document)                             │
+│  ─────────────────────────────────                              │
+│  • 전체 시스템 1개                                               │
+│  • 지속적으로 업데이트                                            │
+│  • 컴포넌트 구성, 기술 스택, 인프라                                │
+│  • "우리 시스템은 이렇게 생겼다"                                   │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              │ 참조
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│  Feature HLD (피처별)                                            │
+│  ────────────────────                                           │
+│  • 피처/에픽 단위로 작성 (여러 개)                                 │
+│  • SAD 내에서 이 피처가 어떻게 구현되는지                           │
+│  • "이 기능은 이렇게 만든다"                                       │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### SAD에 포함되는 것
+
+| 섹션 | 설명 |
+|------|------|
+| System Overview | 시스템 목적, 핵심 가치 |
+| Architecture Diagram | 전체 컴포넌트 구성도 |
+| Component Catalog | 각 컴포넌트 역할과 책임 |
+| Tech Stack | 기술 스택과 선택 이유 |
+| Data Architecture | 데이터 저장소, 흐름 |
+| Infrastructure | 인프라 구성, 배포 환경 |
+| Cross-Cutting Concerns | 인증, 로깅, 모니터링 등 |
+| Integration Points | 외부 시스템 연동 |
+
+### SAD에 포함하지 않는 것
+
+- ❌ 특정 피처의 상세 설계 → Feature HLD
+- ❌ API 스펙, DB 스키마 상세 → LLD
+- ❌ 구현 코드, 설정 파일 → Task/Code
+
+---
+
+## 워크플로우
+
+```mermaid
+flowchart TD
+    A[요청] --> B{기존 SAD 있음?}
+    B -->|Yes| C[업데이트 모드]
+    B -->|No| D[신규 생성 모드]
+
+    C --> E[변경사항 파악]
+    E --> F[영향 받는 섹션 식별]
+    F --> G[SAD 업데이트]
+
+    D --> H[Step 1: 시스템 개요 파악]
+    H --> I[Step 2: 컴포넌트 구조 파악]
+    I --> J[Step 3: 기술 스택 파악]
+    J --> K[Step 4: 인프라 파악]
+    K --> L[SAD 작성]
+
+    G --> M[검토 요청]
+    L --> M
+    M -->|수정| G
+    M -->|수정| L
+    M -->|승인| N[저장]
+```
+
+---
+
+## Step 0: 기존 SAD 확인
+
+```
+documents/architecture/system-architecture.md 파일이 존재하는지 확인합니다.
+
+있으면 → 업데이트 모드
+없으면 → 신규 생성 모드
+```
+
+---
+
+## 신규 생성 모드
+
+### Step 1: 시스템 개요 파악
+
+수집해야 할 정보:
+- 시스템의 목적과 핵심 가치
+- 주요 사용자/고객
+- 핵심 비즈니스 도메인
+
+질문 예시:
+```
+시스템 아키텍처 문서를 작성하려고 합니다.
+
+1. 이 시스템의 핵심 목적은 무엇인가요?
+2. 주요 사용자는 누구인가요? (고객, 내부 사용자, 다른 시스템)
+3. 핵심 비즈니스 도메인은 무엇인가요? (예: 이커머스, 채팅, 결제)
+```
+
+### Step 2: 컴포넌트 구조 파악
+
+수집해야 할 정보:
+- 주요 서비스/모듈 목록
+- 각 컴포넌트의 역할과 책임
+- 컴포넌트 간 통신 방식
+
+질문 예시:
+```
+컴포넌트 구조를 파악하고 싶습니다.
+
+1. 현재 시스템은 어떤 서비스/모듈로 구성되어 있나요?
+2. 각 컴포넌트의 주요 역할은 무엇인가요?
+3. 컴포넌트 간 통신은 어떻게 하나요? (REST, gRPC, 메시지 큐 등)
+```
+
+### Step 3: 기술 스택 파악
+
+수집해야 할 정보:
+- 언어/프레임워크
+- 데이터베이스
+- 메시지 큐/캐시
+- 클라우드/인프라
+
+질문 예시:
+```
+기술 스택을 정리하고 싶습니다.
+
+1. 사용 중인 언어와 프레임워크는 무엇인가요?
+2. 데이터베이스는 무엇을 사용하나요? (RDB, NoSQL, 검색엔진 등)
+3. 캐시, 메시지 큐 등 미들웨어가 있나요?
+```
+
+### Step 4: 인프라 파악
+
+수집해야 할 정보:
+- 배포 환경 (클라우드, 온프레미스)
+- 컨테이너/오케스트레이션
+- CI/CD 파이프라인
+
+질문 예시:
+```
+인프라 구성을 파악하고 싶습니다.
+
+1. 배포 환경은 어디인가요? (AWS, GCP, 온프레미스 등)
+2. 컨테이너를 사용하나요? (Docker, Kubernetes)
+3. CI/CD 파이프라인이 구성되어 있나요?
+```
+
+---
+
+## 업데이트 모드
+
+### 변경 유형별 처리
+
+| 변경 유형 | 영향 섹션 | 처리 방법 |
+|----------|----------|----------|
+| 새 서비스 추가 | Architecture Diagram, Component Catalog | 다이어그램 업데이트, 컴포넌트 추가 |
+| 기술 스택 변경 | Tech Stack | 변경 이력과 이유 기록 |
+| 인프라 변경 | Infrastructure | 구성도 업데이트 |
+| 외부 연동 추가 | Integration Points | 연동 포인트 추가 |
+
+### 업데이트 시 질문 예시
+```
+기존 시스템 아키텍처에 변경이 있나요?
+
+1. 어떤 변경이 있었나요? (새 서비스, 기술 스택 변경, 인프라 변경)
+2. 변경 이유는 무엇인가요?
+3. 기존 컴포넌트에 영향이 있나요?
+```
+
+---
+
+## SAD 문서 구조
+
+```markdown
+# System Architecture Document
+
+## 문서 정보
+
+| 항목 | 내용 |
+|------|------|
+| 시스템명 | [시스템 이름] |
+| 버전 | v1.0 |
+| 최종 수정일 | YYYY-MM-DD |
+| 작성자 | @작성자 |
+
+---
+
+## 1. System Overview
+
+### 1.1 목적
+[시스템의 핵심 목적과 해결하는 문제]
+
+### 1.2 핵심 가치
+[시스템이 제공하는 핵심 가치]
+
+### 1.3 주요 사용자
+| 사용자 유형 | 설명 |
+|------------|------|
+| [유형1] | [설명] |
+
+---
+
+## 2. Architecture Diagram
+
+### 2.1 시스템 전체 구성도
+
+```mermaid
+graph TB
+    subgraph Client
+        Web[Web App]
+        Mobile[Mobile App]
+    end
+
+    subgraph Backend
+        API[API Gateway]
+        Service1[Service A]
+        Service2[Service B]
+    end
+
+    subgraph Data
+        DB[(Database)]
+        Cache[(Cache)]
+    end
+
+    Client --> API
+    API --> Service1
+    API --> Service2
+    Service1 --> DB
+    Service2 --> Cache
+```
+
+### 2.2 컴포넌트 간 통신
+
+| From | To | Protocol | 설명 |
+|------|-----|----------|------|
+| [컴포넌트1] | [컴포넌트2] | REST/gRPC | [설명] |
+
+---
+
+## 3. Component Catalog
+
+### 3.1 [컴포넌트명]
+
+| 항목 | 내용 |
+|------|------|
+| 역할 | [역할 설명] |
+| 책임 | [책임 목록] |
+| 소유 팀 | [팀명] |
+| 저장소 | [repo URL] |
+
+---
+
+## 4. Tech Stack
+
+### 4.1 언어 & 프레임워크
+
+| 레이어 | 기술 | 버전 | 선택 이유 |
+|--------|------|------|----------|
+| Backend | [기술] | [버전] | [이유] |
+| Frontend | [기술] | [버전] | [이유] |
+
+### 4.2 데이터 저장소
+
+| 용도 | 기술 | 선택 이유 |
+|------|------|----------|
+| Primary DB | [기술] | [이유] |
+| Cache | [기술] | [이유] |
+
+### 4.3 미들웨어
+
+| 용도 | 기술 | 선택 이유 |
+|------|------|----------|
+| Message Queue | [기술] | [이유] |
+
+---
+
+## 5. Data Architecture
+
+### 5.1 데이터 흐름
+
+```mermaid
+flowchart LR
+    Source[Data Source] --> Process[Processing]
+    Process --> Store[Storage]
+    Store --> Serve[Serving]
+```
+
+### 5.2 데이터 저장소 매핑
+
+| 도메인 | 저장소 | 데이터 특성 |
+|--------|--------|------------|
+| [도메인1] | [저장소] | [특성] |
+
+---
+
+## 6. Infrastructure
+
+### 6.1 배포 환경
+
+| 환경 | 용도 | 구성 |
+|------|------|------|
+| Production | 실서비스 | [구성] |
+| Staging | 테스트 | [구성] |
+
+### 6.2 인프라 구성도
+
+```mermaid
+graph TB
+    subgraph Cloud[AWS/GCP]
+        LB[Load Balancer]
+        subgraph K8s[Kubernetes]
+            Pod1[Service Pods]
+        end
+        DB[(RDS)]
+    end
+
+    LB --> K8s
+    K8s --> DB
+```
+
+---
+
+## 7. Cross-Cutting Concerns
+
+### 7.1 인증/인가
+
+| 항목 | 방식 |
+|------|------|
+| 인증 | [JWT/OAuth/etc] |
+| 인가 | [RBAC/ABAC/etc] |
+
+### 7.2 로깅 & 모니터링
+
+| 항목 | 도구 |
+|------|------|
+| 로깅 | [도구] |
+| 메트릭 | [도구] |
+| 트레이싱 | [도구] |
+
+### 7.3 에러 핸들링
+
+[공통 에러 처리 전략]
+
+---
+
+## 8. Integration Points
+
+### 8.1 외부 시스템 연동
+
+| 시스템 | 용도 | 프로토콜 | 담당 |
+|--------|------|----------|------|
+| [외부시스템] | [용도] | [프로토콜] | [담당팀] |
+
+---
+
+## 변경 이력
+
+| 버전 | 날짜 | 변경 내용 | 작성자 |
+|------|------|----------|--------|
+| v1.0 | YYYY-MM-DD | 최초 작성 | @작성자 |
+```
+
+---
+
+## 산출물
+
+**저장 위치**: `documents/architecture/system-architecture.md`
+
+---
+
+## 작성 원칙
+
+### 포함해야 하는 것
+- 전체 시스템 구성도
+- 모든 주요 컴포넌트와 역할
+- 기술 스택과 선택 이유
+- 데이터 흐름
+- 인프라 구성
+- Cross-cutting concerns
+
+### 포함하지 않는 것
+- 특정 피처의 상세 설계 (→ Feature HLD)
+- API 스펙 상세 (→ LLD)
+- 구현 코드 (→ Task)
+
+### 작성 규칙
+1. **현재 상태 반영**: 계획이 아닌 현재 구현된 상태
+2. **변경 이력 기록**: 주요 변경은 변경 이력에 기록
+3. **다이어그램 필수**: Mermaid로 구조 시각화
+4. **선택 이유 기록**: 기술 선택의 이유 명시
+
+---
+
+## 금지 사항
+
+1. **상세 설계 포함 금지**
+   ```
+   ❌ API 엔드포인트 상세, DB 스키마 상세
+   ✅ 전체 구조와 컴포넌트 역할만
+   ```
+
+2. **미래 계획만 기록 금지**
+   ```
+   ❌ "향후 MSA로 전환 예정"만 기록
+   ✅ 현재 상태 기록 + 계획은 별도 섹션
+   ```
+
+3. **변경 이력 누락 금지**
+   ```
+   ❌ 변경 시 이전 내용 삭제만
+   ✅ 변경 이력 섹션에 기록
+   ```
+
+---
+
+## 관련 스킬
+
+- `/hld-generator`: SAD 기반 피처별 HLD 작성
+- `/lld-generator`: HLD 기반 상세 설계

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

@@ -18,17 +18,35 @@ allowed-tools: Read, Glob, Grep, Write, Edit, WebSearch, WebFetch
 
 ## HLD란?
 
-**High-Level Design (HLD)**는 구현 전에 전체 시스템의 큰 그림을 설계하는 문서입니다.
+**High-Level Design (HLD)**는 **피처/에픽 단위**로 작성하는 설계 문서입니다.
+전체 시스템 아키텍처(SAD)를 기반으로, 해당 피처가 어떻게 구현될지 설계합니다.
+
+### SAD vs Feature HLD
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│  SAD (System Architecture Document)                             │
+│  • 전체 시스템 1개, /architecture로 생성                          │
+│  • "우리 시스템은 이렇게 생겼다"                                   │
+└─────────────────────────────────────────────────────────────────┘
+                              │ 참조
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│  Feature HLD (이 스킬로 생성)                                     │
+│  • 피처/에픽 단위로 여러 개                                        │
+│  • "이 기능은 SAD 내에서 이렇게 구현한다"                           │
+└─────────────────────────────────────────────────────────────────┘
+```
 
 ### 언제 작성하는가
 
 ```
-요구사항 분석(PRD) → HLD → LLD(Low-Level Design) → 구현
+SAD(시스템 아키텍처) → PRD → Epic/Story → Feature HLD → LLD → 구현
 ```
 
-- 요구사항이 어느 정도 정리된 후
-- 실제 코딩을 시작하기 전
-- 새로운 기능, 시스템, 또는 큰 변경이 있을 때
+- 새로운 피처/에픽 구현 전
+- 기존 아키텍처에 영향을 주는 변경 시
+- 복잡도 L3 이상 또는 규모가 큰 변경 시
 
 ### 목적
 
@@ -87,13 +105,28 @@ flowchart TD
 
 ---
 
-## Step 0: PRD 확인
+## Step 0: SAD 및 PRD 확인
+
+Feature HLD 작성 전 SAD와 PRD 존재 여부를 확인합니다.
 
-HLD 작성 전 반드시 PRD 존재 여부를 확인합니다.
+### SAD 확인
+```
+documents/architecture/system-architecture.md 파일 확인
+
+있으면 → SAD 참조하여 HLD 작성
+없으면 → SAD 없이 진행 가능 (권장: /architecture로 먼저 작성)
+```
+
+### SAD가 있는 경우
+SAD에서 다음 정보를 추출합니다:
+- 현재 컴포넌트 구성
+- 기술 스택
+- 데이터 흐름
+- 이 피처가 영향을 주는 컴포넌트
 
 ### PRD가 없는 경우
 ```
-HLD 작성을 위해 PRD(제품 요구사항 정의서)가 필요합니다.
+Feature HLD 작성을 위해 PRD(제품 요구사항 정의서)가 필요합니다.
 PRD가 준비되어 있으신가요? 없다면 먼저 PRD를 작성해주세요.
 ```