timsquad 3.6.0 → 3.7.0

package/templates/base/skills/tsq-protocol/SKILL.md

@@ -1,13 +1,10 @@
 ---
 name: tsq-protocol
 description: |
-  TimSquad 에이전트 공통 프로토콜.
-  task-context.json 우선 탐색, TSQ CLI 사용, 로그/피드백 규칙.
-  자동 주입 스킬 — 직접 호출하지 마세요.
-version: "1.0.0"
+  TimSquad 에이전트 공통 프로토콜. 메인세션과 서브에이전트 모두 이 프로토콜을 준수.
+  로그/피드백 규칙, 작업 원칙을 정의. 자동 활성 스킬 — 직접 호출하지 마세요.
+version: "2.1.0"
 tags: [tsq, protocol, agent]
-depends_on: []
-conflicts_with: []
 user-invocable: false
 ---
 
@@ -15,49 +12,104 @@ user-invocable: false
 
 에이전트가 TimSquad 시스템 내에서 따라야 하는 공통 프로토콜.
 
-## Philosophy
-
-- TSQ CLI를 통해서만 로그/피드백/커밋 수행
-- task-context.json을 우선 탐색하여 불필요한 탐색 최소화
-- 피드백은 반드시 Level 분류를 명시
-
 ## Contract
 
 - **Trigger**: 모든 에이전트 세션 (자동 활성)
 - **Input**: 태스크 지시 + task-context.json
 - **Output**: TSQ 프로세스 준수 작업 결과
 - **Error**: 프로토콜 위반 시 경고 + 수정 안내
-- **Dependencies**: 없음
 
-## Protocol
+## Protocol — 메인세션
+
+1. **요구사항 분석**: 사용자 요구 파악 + 모호함 해소
+2. **파이프라인 판단**: 작업 복잡도에 따라 분기
+   - 파이프라인 적합 → tsq-controller 스킬 경유 위임
+   - 단순 작업 → 직접 수행 + 최소 로그
+   - 모호 → 사용자에게 선택지 제시
+3. **검증 기준 선행**: 구현 전에 테스트 or 확인 방법을 먼저 명시
+4. **선택지 제시**: 요구사항에 여러 해석이 가능하면 조용히 선택하지 않음
+
+## Protocol — 서브에이전트
 
 1. **task-context 확인**: `.timsquad/.daemon/task-context.json` 우선 읽기
-2. **TSQ CLI 사용**: 로그/피드백/커밋 모두 CLI 경유
-3. **피드백 라우팅**: Level 분류 후 적절한 대상에 전달
+2. **제약조건 확인**: 주입된 Phase 제약 + allowed-tools 범위 확인
+3. **작업 수행**: 제약 범위 내에서 태스크 실행
+4. **Completion Report 출력**: 아래 형식으로 결과 보고 (**필수, 생략 불가**)
+
+### Completion Report (필수)
+
+서브에이전트는 작업 완료 시 **반드시** 아래 형식의 보고서를 출력해야 합니다.
+Controller가 이 보고서를 검증하며, 누락 시 태스크 완료로 인정되지 않습니다.
+
+```
+## Completion Report
+- Task: {태스크 설명 — 무엇을 했는지}
+- Status: {pass|fail}
+- Files changed: {변경된 파일 목록, 없으면 "none"}
+- Tests: {passed N|failed N|skipped — 테스트 실행 결과}
+- Notes: {차단 요소, 결정 사항, 또는 "none"}
+```
 
-## Verification
+**필드 규칙**:
+| 필드 | 필수 | 허용 값 |
+|------|------|---------|
+| Task | Yes | 1줄 설명 |
+| Status | Yes | `pass` 또는 `fail` |
+| Files changed | Yes | 파일 경로 목록 또는 `none` |
+| Tests | Yes | `passed N`, `failed N`, `skipped`, `N/A` |
+| Notes | Yes | 텍스트 또는 `none` |
 
-| Check | Command | Pass Criteria |
-|-------|---------|---------------|
-| TSQ CLI 사용 | `tsq log` 사용 여부 | 직접 파일 조작 0건 |
-| 피드백 Level | 피드백 내용 확인 | L1/L2/L3 분류 존재 |
-| task-context | 탐색 순서 확인 | context 우선 사용 |
+**Status 판정 기준**:
+- `pass`: 모든 테스트 통과 + `tsc --noEmit` 클린 + 요구사항 충족
+- `fail`: 테스트 실패, 빌드 오류, 또는 요구사항 미충족 (Notes에 사유 기록)
 
 ## Quick Rules
 
-### CLI Commands
-| 이벤트 | 커맨드 |
-|--------|--------|
-| 작업 시작 | `tsq log add {agent} work "TASK-XXX 시작: {설명}"` |
-| 결정 기록 | `tsq log add {agent} decision "{결정 근거}"` |
-| 이슈 발견 | `tsq feedback "{이슈 설명}"` |
-| 작업 완료 | `tsq log add {agent} work "TASK-XXX 완료: {결과}"` |
-| 커밋 | `tsq commit -m "{메시지}"` (developer/dba만) |
+### 로그 기록
+로그는 `.timsquad/logs/{date}-{agent}.md`에 직접 append한다.
+
+```markdown
+## {time} [{type}]
+{message}
+```
+
+| type | 용도 |
+|------|------|
+| work | 작업 시작/완료 기록 |
+| decision | 결정 근거 기록 |
+| issue | 이슈/피드백 발견 |
+
+## Decision Log
+
+중요한 판단이 있을 때 `.timsquad/state/decisions.jsonl`에 한 줄 append한다.
+모든 판단을 기록할 필요 없음 — 아래 기준에 해당할 때만.
+
+기록 기준:
+- 기술 선택 (라이브러리, 패턴, 아키텍처)
+- 대안을 검토하고 하나를 선택한 경우
+- 의도적으로 보류하거나 스킵한 항목
+- 예상과 다른 동작을 발견한 경우
+- 리스크를 인지하고 수용한 경우
+
+형식 (JSON, 한 줄):
+```
+{"agent":"developer","decision":"JWT 선택","reason":"stateless, MSA 확장","alternatives":["session"],"carry_over":false}
+```
+
+| 필드 | 필수 | 설명 |
+|------|------|------|
+| agent | Yes | 에이전트 이름 |
+| decision | Yes | 무엇을 결정했는지 (1줄) |
+| reason | Yes | 왜 그렇게 했는지 (1줄) |
+| alternatives | No | 검토한 대안 목록 |
+| carry_over | No | 다음 Phase에서 처리 필요 시 true |
+| risk | No | 인지된 리스크 |
 
 ### Forbidden
-- 직접 `.timsquad/logs/` 파일 조작 → `tsq log` 사용
-- 직접 `.timsquad/feedback/` 파일 조작 → `tsq feedback` 사용
-- 직접 `git commit` → `tsq commit` 사용
+- 스펙 없이 대규모 구현 시작
+- 서브에이전트 결과를 검증 없이 수용
+- Phase gate 조건 미충족 시 다음 Phase 진행
+- Completion Report 없이 태스크 완료 선언
 
 ### Feedback Routing
 | Level | 기준 | 라우팅 |

package/templates/base/skills/{frontend/react → tsq-react}/SKILL.md

@@ -1,14 +1,17 @@
 ---
-name: react
-description: React 컴포넌트 개발 가이드라인. 단일 책임, UI/로직 분리, 명시적 데이터 흐름, 서버/클라이언트 상태 분리.
+name: tsq-react
+description: |
+  React 컴포넌트 개발 가이드라인. 단일 책임, UI/로직 분리, 명시적 데이터 흐름, 서버/클라이언트 상태 분리.
+  Use when: React 컴포넌트 작성·수정, 상태관리 설계, 커스텀 훅 작성, JSX/TSX 파일 편집 시.
 version: "1.0.0"
-tags: [react, components, frontend]
+tags: [tsq, react, components, frontend]
 user-invocable: false
 ---
 
 # React Development Guidelines
 
 프로젝트 전체에서 일관된 React 컴포넌트 개발을 위한 컨벤션.
+기본 스택: React Query, Zustand, React Hook Form + Zod. 프로젝트 설정(`memory/conventions.md`)으로 재정의 가능.
 
 ## Philosophy
 

package/templates/base/skills/tsq-retro/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: tsq-retro
+description: |
+  피드백 수집, KPT 회고, 개선 적용까지 전체 회고 사이클을 관리하는 스킬.
+  Use when: /tsq-retro 호출 시, 피드백 기록 시, Phase 완료 후 회고 시, 패턴 분석 시,
+  개선 사항 적용 시, "피드백", "회고", "개선", "retro", "feedback", "improve" 언급 시.
+version: "2.0.0"
+tags: [tsq, retrospective, feedback, improvement, learning]
+user-invocable: true
+argument-hint: "[feedback|retro|improve] — 피드백 기록 / KPT 회고 / 개선 적용"
+---
+
+# Retrospective Cycle
+
+피드백 수집 → KPT 회고 → 개선 적용의 전체 학습 루프를 관리한다.
+
+## Contract
+
+- **Trigger**: `/tsq-retro`, `/tsq-retro feedback`, `/tsq-retro improve`
+- **Input**: 모드에 따라 다름 (아래 Mode 참조)
+- **Output**: 피드백 엔트리 / KPT 리포트 / 개선 적용 결과
+- **Error**: 데이터 부족 시 수집 가능 범위 안내
+- **Dependencies**: tsq-protocol
+
+## Modes
+
+### Mode 1: feedback — 피드백 기록
+
+`/tsq-retro feedback "<메시지>"` 또는 작업 중 이슈 발견 시.
+
+1. **레벨 분류**: 메시지 내용으로 L1/L2/L3 판정
+   - **L1 (구현)**: 버그, 코드 품질, 테스트 누락 — 현재 Task에서 바로 수정 가능
+   - **L2 (설계)**: 아키텍처 변경, API 재설계, 스키마 수정 — Sequence/Phase 수준 조정 필요
+   - **L3 (기획)**: 요구사항 변경, 스펙 모순, 우선순위 재조정 — SSOT 수정 필요
+2. **기록**: `.timsquad/retrospective/feedback.jsonl`에 append
+   ```json
+   {"ts":"ISO8601","level":1,"phase":"P2","message":"...","status":"open"}
+   ```
+3. **즉시 조치 판단**:
+   - L1 → 현재 Task에서 수정 권고 (알림만)
+   - L2 → 현재 Sequence 완료 후 Architect 검토 권고
+   - L3 → Phase 완료 시 `/tsq-retro`에서 우선 다룸
+
+상세 분류 기준은 `references/feedback-guide.md` 참조.
+
+### Mode 2: retro — KPT 회고 (기본)
+
+`/tsq-retro` 또는 `/tsq-retro retro`. Phase 완료 후 실행 권장.
+
+1. **데이터 수집**:
+   - `.timsquad/logs/` — 작업 로그
+   - `.timsquad/retrospective/feedback.jsonl` — 수집된 피드백
+   - `.timsquad/retrospective/metrics/` — 메트릭
+   - `.timsquad/retrospective/patterns/` — 기존 패턴
+2. **메트릭 계산**: 작업 수, 성공률, 평균 수정 횟수, 피드백 레벨별 건수
+3. **KPT 분석**: Keep / Problem / Try 분류
+4. **패턴 식별**: 실패 패턴(FP, 3회+ 반복) / 성공 패턴(SP, 효과 검증)
+5. **리포트 작성**: `.timsquad/retrospective/retro-{phase}.md`
+6. **개선 제안**: 실행 가능한 액션 아이템 도출 → 사용자 승인 대기
+7. **피드백 정리**: 처리된 feedback.jsonl 엔트리를 `status: "resolved"` 처리
+
+리포트 구성: 메트릭 요약 → 에이전트별 성과 → 피드백 분석(L1/L2/L3) → 패턴(FP/SP) → 개선 조치 → 다음 목표.
+
+### Mode 3: improve — 개선 적용
+
+`/tsq-retro improve`. 회고에서 승인된 개선을 실제로 적용.
+
+1. **제안 로드**: 최근 retro 리포트에서 승인된 개선 항목 읽기
+2. **대상 분류**: 개선 대상별로 분류
+   - **스킬 패치**: SKILL.md 규칙/프로토콜 수정
+   - **템플릿 수정**: agent.md, config.yaml 등
+   - **패턴 등록**: `.timsquad/retrospective/patterns/` 에 FP/SP 기록
+   - **lessons 기록**: `.timsquad/retrospective/lessons.md` 에 학습 사항 append
+3. **적용**: 각 대상에 diff 형태로 변경 사항 제시 → 사용자 확인 후 적용
+4. **검증**: 변경 후 `npm test` 통과 확인
+5. **기록**: 적용된 개선을 lessons.md에 기록, 다음 retro에서 효과 측정
+
+상세 절차는 `references/improve-protocol.md` 참조. 개선 제안 형식은 `references/improvement-template.md` 참조.
+
+## Quick Rules
+
+- **객관적 데이터 우선** — 주관적 평가보다 수치 기반
+- **구체적 액션** — "더 잘하자"가 아닌 실행 가능한 행동
+- **균형 잡힌 시각** — 문제점만이 아닌 성공 사례도 포함
+- **점진적 개선** — 한 번에 대규모 변경보다 작은 개선을 반복
+- **사용자 승인 필수** — improve 모드에서 자동 적용 금지, 반드시 확인 후 적용

package/templates/base/skills/tsq-retro/references/feedback-guide.md

@@ -0,0 +1,58 @@
+---
+title: Feedback Level Classification Guide
+category: reference
+---
+
+# 피드백 레벨 분류 가이드
+
+## L1 — 구현 수준 (현재 Task에서 수정 가능)
+
+즉시 수정 가능한 코드/테스트 수준의 이슈.
+
+| 트리거 | 예시 |
+|--------|------|
+| 버그 발견 | "로그인 시 토큰 만료 체크 누락" |
+| 테스트 누락 | "에러 케이스 단위 테스트 없음" |
+| 코드 품질 | "중복 로직이 3곳에 산재" |
+| 타입 에러 | "반환 타입이 Promise인데 await 누락" |
+| 린트/포맷 | "ESLint 규칙 위반" |
+
+**조치**: 현재 Task 내에서 Developer가 바로 수정. Controller에 별도 보고 불필요.
+
+## L2 — 설계 수준 (Sequence/Phase 조정 필요)
+
+현재 Task 범위를 넘어서는 구조적 변경이 필요한 이슈.
+
+| 트리거 | 예시 |
+|--------|------|
+| API 인터페이스 변경 | "REST → GraphQL 전환 필요" |
+| DB 스키마 수정 | "정규화 깨짐, 마이그레이션 필요" |
+| 아키텍처 변경 | "모놀리스 → 마이크로서비스 분리" |
+| 의존성 충돌 | "라이브러리 A와 B 버전 비호환" |
+| 성능 병목 | "N+1 쿼리 패턴, 구조적 수정 필요" |
+
+**조치**: 현재 Sequence 완료 후 Architect 검토 권고. Phase Memory에 carry-over 기록.
+
+## L3 — 기획 수준 (SSOT 수정 필요)
+
+요구사항/스펙 자체의 변경이 필요한 이슈.
+
+| 트리거 | 예시 |
+|--------|------|
+| 요구사항 모순 | "PRD에서 '실시간'이라 했는데 폴링으로 구현" |
+| 스펙 누락 | "인증 방식이 정의되지 않음" |
+| 우선순위 변경 | "MVP에서 결제 기능 제외해야 할 듯" |
+| 외부 제약 | "API 제공업체 정책 변경으로 재설계 필요" |
+| 비즈니스 로직 변경 | "수수료 계산 공식이 바뀜" |
+
+**조치**: Phase 완료 시 `/tsq-retro`에서 우선 다룸. SSOT 문서 갱신 필요.
+
+## 판단 기준 요약
+
+```
+코드만 고치면 해결? → L1
+설계/구조를 바꿔야 해결? → L2
+스펙/요구사항이 틀림? → L3
+```
+
+애매한 경우 낮은 레벨로 시작하고, 회고에서 레벨을 올린다.

package/templates/base/skills/tsq-retro/references/improve-protocol.md

@@ -0,0 +1,87 @@
+---
+title: Improvement Application Protocol
+category: reference
+---
+
+# 개선 적용 프로토콜
+
+`/tsq-retro improve` 실행 시 상세 절차.
+
+## 1. 제안 로드
+
+최근 retro 리포트(`.timsquad/retrospective/retro-{phase}.md`)에서 개선 항목을 추출한다.
+각 항목에는 `[승인]` / `[보류]` / `[거부]` 태그가 있어야 한다. 태그 없으면 사용자에게 승인 요청.
+
+## 2. 대상별 적용 절차
+
+### 스킬 패치 (SKILL.md 수정)
+
+대상: `.claude/skills/tsq-*/SKILL.md`
+
+1. 변경할 스킬 파일 읽기
+2. diff 형태로 변경 사항 제시
+3. 사용자 확인 후 적용
+4. 변경 이유를 커밋 메시지에 포함
+
+주의: Quick Rules나 Protocol 순서 변경은 다른 스킬과의 의존성 확인 필요.
+
+### 템플릿 수정
+
+대상: `.claude/agents/*.md`, `.timsquad/config.yaml`
+
+1. 변경 영향 범위 확인 (해당 에이전트가 참조하는 스킬 목록)
+2. diff 제시 → 사용자 확인
+3. 적용 후 관련 에이전트 동작에 영향 없는지 확인
+
+### 패턴 등록
+
+대상: `.timsquad/retrospective/patterns/`
+
+실패 패턴(FP) 또는 성공 패턴(SP)을 등록한다.
+
+```markdown
+## FP-{NNN}: {패턴명}
+
+- **빈도**: {N}회 (Phase {X}, {Y}, {Z})
+- **증상**: {무엇이 반복적으로 실패하는가}
+- **근본 원인**: {왜 반복되는가}
+- **대응**: {어떻게 방지할 것인가}
+- **적용일**: {ISO8601}
+```
+
+```markdown
+## SP-{NNN}: {패턴명}
+
+- **빈도**: {N}회 검증됨
+- **효과**: {어떤 개선 효과가 있었는가}
+- **조건**: {이 패턴이 효과적인 조건}
+- **적용일**: {ISO8601}
+```
+
+### lessons.md 기록
+
+대상: `.timsquad/retrospective/lessons.md`
+
+모든 개선 적용 결과를 기록한다. 다음 retro에서 효과 측정의 입력이 된다.
+
+```markdown
+## {ISO8601} — {개선 제목}
+
+- **출처**: retro-{phase}.md IMP-{NNN}
+- **변경**: {무엇을 바꿨는가}
+- **기대 효과**: {무엇을 기대하는가}
+- **측정 기준**: {다음 retro에서 확인할 지표}
+```
+
+## 3. 검증
+
+적용 후 반드시 확인:
+
+1. `npm test` — 테스트 통과
+2. 변경된 스킬이 있으면 frontmatter(name, description, version) 정합성 확인
+3. 패턴이 등록됐으면 patterns/ 디렉토리에 파일 존재 확인
+
+## 4. 효과 측정 (다음 retro에서)
+
+lessons.md의 "측정 기준"을 다음 `/tsq-retro` 실행 시 자동으로 체크한다.
+개선이 효과가 있었으면 SP로 승격, 없었으면 Try 항목에 재등록.

package/templates/base/skills/{security → tsq-security}/SKILL.md

@@ -1,13 +1,11 @@
 ---
-name: security
+name: tsq-security
 description: |
   보안 검토 및 취약점 탐지 가이드라인.
   OWASP Top 10, 시크릿 관리, Rate Limiting, CSRF 방지를 다룸.
   Use when: "보안 검토, 취약점, OWASP, XSS, injection, 시크릿, 인증"
 version: "1.0.0"
-tags: [security, owasp, vulnerability]
-depends_on: []
-conflicts_with: []
+tags: [tsq, security, owasp, vulnerability]
 user-invocable: false
 ---
 

package/templates/base/skills/{spec → tsq-spec}/SKILL.md

@@ -1,13 +1,11 @@
 ---
-name: spec
+name: tsq-spec
 description: |
   SSOT(Single Source of Truth) 문서 존재 여부를 확인하고, 미존재 시 구현 전 스펙 작성을 안내한다.
-  `/spec <기능명>`으로 호출하면 해당 기능의 SSOT 문서를 찾아 상태를 보고한다.
+  `/tsq-spec <기능명>`으로 호출하면 해당 기능의 SSOT 문서를 찾아 상태를 보고한다.
   스펙 없이 구현하는 것을 방지하여 문서-코드 일관성을 유지한다.
 version: "1.0.0"
-tags: [spec, ssot, gate, documentation]
-depends_on: [tsq-protocol]
-conflicts_with: []
+tags: [tsq, spec, ssot, gate, documentation]
 user-invocable: true
 argument-hint: "[기능명] — SSOT 문서 존재 여부 확인"
 ---
@@ -18,7 +16,7 @@ SSOT 문서 존재 여부를 확인하여 스펙 없는 구현을 방지한다.
 
 ## Contract
 
-- **Trigger**: `/spec` 호출 또는 구현 시작 전 자동 확인
+- **Trigger**: `/tsq-spec` 호출 또는 구현 시작 전 자동 확인
 - **Input**: `$ARGUMENTS` (기능명) 또는 미지정 시 전체 SSOT 상태
 - **Output**: SSOT 상태 리포트 (존재/stale/미존재) + 권장 액션
 - **Error**: SSOT 디렉토리 자체가 없을 경우 "NOT FOUND" 안내

package/templates/base/skills/{stability-verification → tsq-stability}/SKILL.md

@@ -1,12 +1,12 @@
 ---
-name: stability-verification
+name: tsq-stability
 description: |
   프로젝트 안정성 검증 스킬. 릴리스/스프린트 완료 전 6-Layer 자동+수동 검증 수행.
   L0(정적분석) → L1(유닛테스트) → L2(보안스캔) → L3(쉘스크립트) → L4(통합) → L5(패키지).
   각 레이어는 fail-closed(기본) 또는 fail-open 정책 적용.
   사용 시점: 릴리스 전, 스프린트 완료 시, 보안 감사 요청 시.
 version: "1.0.0"
-tags: [verification, security, quality, release]
+tags: [tsq, verification, security, quality, release]
 user-invocable: false
 ---
 
@@ -33,7 +33,7 @@ user-invocable: false
 ## Quick Rules
 
 ### 검증 실행
-- `bash .claude/skills/stability-verification/scripts/verify.sh` 로 전체 실행
+- `bash .claude/skills/tsq-stability/scripts/verify.sh` 로 전체 실행
 - `--layer L0` 으로 특정 레이어만 실행
 - `--skip L3` 으로 특정 레이어 건너뛰기
 

package/templates/base/skills/tsq-start/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: tsq-start
+description: |
+  TimSquad 파이프라인 시작. 데몬 기동, 프로토콜 활성화, 현재 상태 복원.
+  초기화 직후 프로젝트는 자동으로 온보딩 모드 진입 (SSOT 문서 작성 가이드).
+  Use when: 사용자가 /tsq-start로 TimSquad 파이프라인을 시작할 때.
+version: "2.0.0"
+tags: [tsq, pipeline, start, onboarding]
+user-invocable: true
+---
+
+# /tsq-start — TimSquad Pipeline Start
+
+## Protocol
+
+1. **데몬 기동**: `tsq daemon start 2>/dev/null || true`
+2. **현재 Phase 확인**: `.timsquad/state/current-phase.json` 읽기
+3. **프로토콜 활성화**: 이후 tsq-protocol 준수, 위임은 controller 경유
+4. **상태 복원**: 진행 중인 시퀀스/태스크 요약 출력
+5. **온보딩 감지**: SSOT 충족도 검사 → 미충족 시 온보딩 모드
+6. **안내 출력**
+
+## 온보딩 감지 (Step 5)
+
+`.timsquad/ssot/`의 `.md` 파일을 스캔하여 작성 완료도 판정:
+- **empty**: placeholder만 존재 (`[Resource Name]`, `TBD`, `example.com` 등이 50%+)
+- **partial**: 일부 섹션만 작성
+- **filled**: 주요 섹션 작성 완료
+
+**진입 조건** (하나라도 해당): prd.md가 empty / required 70%+ empty / progress=0
+
+온보딩 시 SSOT 현황(⬜/🟨/✅)을 보여주고 3가지 선택지 제시:
+1. 온보딩 시작 (권장) — PRD부터 순서대로
+2. 특정 문서만 작성
+3. 건너뛰기
+
+## 온보딩 프로세스
+
+**작성 우선순위**: prd → requirements → data-design → service-spec → 타입별 필수
+
+타입별 추가 우선 문서는 `references/onboarding-questions.md` 참조.
+
+**각 문서 작성 흐름**:
+1. **인터뷰**: 핵심 질문 3-5개 (`references/onboarding-questions.md`의 ★ 필수 질문)
+2. **초안 생성**: 답변으로 SSOT 템플릿 placeholder 채움
+3. **확인**: 초안 보여주고 수정 수렴
+4. **저장**: `.timsquad/ssot/{name}.md`
+5. **다음 문서**: 계속 여부 확인
+
+### PRD → Grill 자동 연결
+
+PRD 초안 완성 후 기능 인덱스에 기능이 2개 이상이면 자동으로 `/tsq-grill` 반복 진입:
+
+1. PRD 기능 인덱스 테이블에서 Sub-PRD 미작성 기능 목록 추출
+2. 사용자에게 목록 보여주고 순서 확인 ("이 순서로 하나씩 상세화합니다")
+3. 각 기능마다 `/tsq-grill` 프로세스 실행 (Why → What → How 인터뷰 → Sub-PRD 생성)
+4. 하나 완료 후 자동으로 다음 기능 진행 (사용자가 "중단", "나중에"라고 하면 정지)
+5. 중단 시 진행 상태를 `onboarding-progress.json`에 기록 → 다음 `/tsq-start`에서 이어서 진행
+6. 모든 기능의 Sub-PRD 완성 시 → 나머지 SSOT 문서(requirements, data-design 등) 온보딩 계속
+
+이렇게 하면 PRD가 기능 목록만 있는 껍데기가 아니라, 각 기능의 Why/What/How까지 잡힌 상태에서 설계 단계로 넘어간다.
+
+**세션 관리**: `.timsquad/state/onboarding-progress.json`에 진행 상태 저장:
+```json
+{
+  "documents": { "prd": "filled", "requirements": "empty", ... },
+  "grill": {
+    "pending": ["feature-b", "feature-c"],
+    "completed": ["feature-a"],
+    "current": null
+  },
+  "last_updated": "ISO8601"
+}
+```
+세션 끊겨도 다음 `/tsq-start`에서 `grill.pending`부터 이어서 진행. 모든 문서 filled + grill.pending 비어있으면 자동 완료.
+
+## 온보딩 완료 후 자동 전환
+
+모든 SSOT 문서 filled + grill.pending 비어있으면 온보딩 완료. 이후:
+
+1. **`/tsq-decompose` 자동 안내**: "온보딩 완료. `/tsq-decompose`로 Phase-Sequence-Task 실행 계획을 생성하시겠습니까?"
+2. 사용자 승인 시 `/tsq-decompose` 실행 (Sub-PRD → DAG → planning.md)
+3. planning.md 확정 후 → 정상 파이프라인 진행 (Controller 경유 위임)
+
+## 파이프라인 분기
+
+온보딩 완료 + planning.md 확정 후 사용자가 작업을 지시하면:
+- **파이프라인 적합** (새 기능, API, DB, 아키텍처) → controller 경유 위임
+- **단순 작업** (오타, 스타일, 1-2줄) → 직접 수행 + 최소 로그
+- **모호한 경우** → 사용자에게 선택지 제시