timsquad 3.7.0 → 3.8.0

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

@@ -1,86 +1,91 @@
 ---
 name: tsq-grill
 description: |
-  Sub-PRD 작성/보강을 위한 소크라틱 심층 인터뷰 스킬.
-  기능별 Why/What/How를 체계적으로 파고들어 모호한 요구사항을 구체화.
-  Use when: "기능 상세화", "요구사항 인터뷰", "PRD 보강", "grill", "기능 정의",
-  "Sub-PRD 작성", "기능 스펙 잡기", 또는 PRD 기능 인덱스에 빈 항목이 있을 때.
-version: "1.0.0"
+  소크라틱 심층 인터뷰로 PRD와 Sub-PRD를 작성/보강하는 스킬.
+  3모드 자동 분기: PRD 미존재 시 프로젝트 전체 인터뷰, PRD 존재 시 기능별 심층 인터뷰,
+  PRD가 있지만 빈 섹션이 있으면 보강 인터뷰.
+  프로젝트 시작, 아이디어 구체화, 요구사항 정리가 필요한 모든 순간에 사용한다.
+  Use when: "PRD 작성", "기획", "기능 상세화", "요구사항 인터뷰", "PRD 보강", "grill",
+  "기능 정의", "Sub-PRD 작성", "기능 스펙 잡기", "프로젝트 정의",
+  "뭘 만들지 정리", "아이디어 구체화", "스코프 잡기", "기획서",
+  또는 PRD가 없거나, PRD에 빈 섹션이 있거나, 기능 인덱스에 빈 항목이 있을 때.
+  새 프로젝트를 시작하거나 기존 프로젝트의 방향을 재정리할 때도 반드시 이 스킬을 사용한다.
+version: "2.1.0"
 tags: [tsq, prd, interview, grill, requirements]
 user-invocable: true
 ---
 
 # /tsq-grill — 소크라틱 심층 인터뷰
 
-PRD의 기능을 하나씩 깊이 파고들어 Sub-PRD를 작성하거나 보강하는 스킬.
-"질문을 통해 답을 끌어낸다"는 소크라틱 방법론을 따른다.
+질문을 통해 답을 끌어내는 소크라틱 방법론으로 PRD와 Sub-PRD를 작성한다.
+PRD가 부실하면 그 위에 세워지는 모든 것이 부실해진다.
 
-## When to Use
+## Mode Detection (자동)
 
-- 새 기능의 Sub-PRD를 처음 작성할 때
-- 기존 Sub-PRD의 빈 섹션을 채울 때
-- 모호한 요구사항을 구체화해야 할 때
-- PRD 기능 인덱스에 Link가 비어있을 때
+```
+.timsquad/ssot/prd.md 존재?
+├── NO  → PRD Mode (프로젝트 전체 인터뷰)
+└── YES → prd.md에 빈 섹션(TBD, TODO, 빈 테이블)이 있는가?
+    ├── YES → PRD Reinforce Mode (빈 섹션 보강 인터뷰)
+    └── NO  → Sub-PRD Mode (기능별 인터뷰)
+```
 
-## Process
+명시적 모드: `/tsq-grill prd` | `/tsq-grill sub` | `/tsq-grill` (자동)
 
-### Phase 1: 대상 선정
+## PRD Mode — 프로젝트 전체 인터뷰
 
-1. `.timsquad/ssot/prd.md`의 기능 인덱스 테이블 읽기
-2. Sub-PRD가 없거나 빈 기능 식별
-3. 사용자에게 인터뷰 대상 기능 확인 (복수 선택 가능)
+PRD가 없거나 프로젝트 초기 단계에서 사용.
 
-### Phase 2: 디자인 트리 인터뷰
+**질문 트리는 `references/interview-guide.md`를 Read하여 참조한다.**
 
-기능마다 3단계 깊이로 질문한다. 한 번에 2-3개 질문, 답변 받으면 다음 깊이로.
+### 인터뷰 원칙
+- 질문 트리는 **가이드**이지 체크리스트가 아니다
+- 이미 답변된 영역은 건너뛴다
+- 한 번에 2-3개 질문만. 사용자가 부담을 느끼면 안 된다
+- 프로젝트 특성에 맞는 질문을 추가한다
 
-```
-Why (목적)
-├── 이 기능이 없으면 사용자에게 어떤 문제가 생기나?
-├── 핵심 사용자 시나리오는?
-└── 성공을 어떻게 측정하나?
-
-What (범위)
-├── Must-Have vs Nice-to-Have 경계는?
-├── 이 기능이 다루지 않는 것은?
-├── 어떤 데이터가 필요하고 어디서 오나?
-└── 기존 시스템과 연동 포인트는?
-
-How (설계)
-├── 사용자 흐름 (Happy Path → Exception Path)?
-├── 상태 전환이 있다면?
-├── 에러 케이스와 처리 방식은?
-└── 성능/보안 고려사항은?
-```
+### 진행: Phase 1(비전) → Phase 2(스코프) → Phase 3(성공 지표) → PRD 생성 → 리뷰
+
+PRD 생성 시 `.timsquad/ssot/prd.md`에 구조화:
+비전/타겟/시장 → 기능 인덱스 테이블 → 제약사항 → KPI → Anti-scope → TBD
+
+## PRD Reinforce Mode — 기존 PRD 보강
 
-질문 방식 원칙:
-- 한 번에 질문 2-3개만 (과부하 방지)
-- 사용자 답변을 요약해서 확인받기 ("~라는 뜻이 맞나요?")
-- 모호한 답변에는 구체적 예시로 재질문
-- "모르겠다"는 답변도 유효 — 결정 보류로 기록
+1. prd.md를 읽고 빈 섹션 / TBD 항목 목록을 사용자에게 제시
+2. 사용자가 보강할 항목 선택
+3. 해당 항목에 대해 소크라틱 인터뷰 진행
+4. 결과를 prd.md에 반영
+5. 사용자 리뷰 요청 (Human Checkpoint)
 
-### Phase 3: Sub-PRD 생성
+## Sub-PRD Mode — 기능별 인터뷰
 
-인터뷰 결과를 `.timsquad/ssot/prd/[feature].md`로 구조화:
+**질문 트리는 `references/interview-guide.md`를 Read하여 참조한다.**
 
-1. `ssot/prd/_template.md` 복사
-2. 인터뷰 답변으로 각 섹션 채우기
-3. Mapped Artifacts는 빈 링크로 두되 구조 유지
-4. 설계 결정 테이블에 인터뷰 중 나온 선택지/결정 기록
+1. prd.md 기능 인덱스에서 Sub-PRD 미작성 기능 식별
+2. 사용자에게 대상 기능 확인
+3. Why → What → How 3단계 인터뷰
+4. `.timsquad/ssot/prd/[feature].md` 생성
+5. prd.md 기능 인덱스 업데이트
 
-### Phase 4: PRD 인덱스 업데이트
+## 질문 방식 원칙 (공통)
 
-`prd.md`의 기능 인덱스 테이블에 새 Sub-PRD 링크 추가.
+- **한 번에 질문 2-3개만** — 질문 폭탄은 대충 답하게 만든다
+- **답변을 요약해서 확인** — 에이전트 해석이 맞는지 검증
+- **모호하면 구체적 예시로 재질문** — "사용자 경험 개선"은 PRD에 쓸 수 없다
+- **"모르겠다"도 유효** — TBD로 기록 + 결정 시점 명시
+- **가정하지 않는다** — 선택지 제시, 사용자가 고르게 한다
 
 ## Output
 
-- `.timsquad/ssot/prd/[feature].md` — Sub-PRD 파일
-- `prd.md` 기능 인덱스 업데이트
-- 인터뷰 로그: `.timsquad/logs/grill-[feature]-[date].md`
+| Mode | 산출물 |
+|------|--------|
+| PRD | `.timsquad/ssot/prd.md` + 인터뷰 로그 |
+| Reinforce | 보강된 `prd.md` (기존 유지, 빈 섹션만) |
+| Sub-PRD | `.timsquad/ssot/prd/[feature].md` + 인덱스 업데이트 |
 
 ## Rules
 
 - 사용자 답변을 임의로 해석하지 않는다 — 확인 후 기록
-- "아직 모르겠다"는 TBD로 표시하되, 결정이 필요한 시점을 명시
+- "아직 모르겠다"는 TBD + 결정 시점 명시
 - SSOT 외 파일 수정 금지
-- Sub-PRD 생성 후 사용자에게 리뷰 요청 (Human Checkpoint)
+- PRD/Sub-PRD 생성 후 반드시 사용자 리뷰 요청 (Human Checkpoint)

package/templates/base/skills/tsq-grill/references/interview-guide.md

@@ -0,0 +1,86 @@
+---
+title: Grill Interview Guide
+category: guide
+---
+
+# Grill Interview Guide — 질문 트리 상세
+
+## PRD Mode 질문 트리
+
+### Phase 1: 비전 인터뷰
+
+프로젝트 전체의 Why를 먼저 확립한다. 여기가 흔들리면 모든 후속 결정이 흔들린다.
+
+```
+Vision (비전)
+├── 이 프로젝트를 한 문장으로 설명한다면?
+├── 이게 없으면 세상에 어떤 문제가 남는가?
+└── 6개월 후 성공했다면, 어떤 상태인가?
+
+Target User (타겟)
+├── 주요 사용자는 누구인가? (구체적 페르소나)
+├── 그 사용자가 지금 이 문제를 어떻게 해결하고 있나?
+├── 왜 기존 방법이 부족한가?
+└── 사용자가 돈을 낼 의향이 있는 부분은?
+
+Market (시장) — 경쟁 환경을 모르면 차별화도 불가능하다
+├── 직접 경쟁자는? 간접 경쟁자는?
+├── 경쟁자 대비 차별점은 무엇인가?
+└── 타이밍이 지금인 이유는?
+```
+
+### Phase 2: 스코프 인터뷰
+
+무엇을 만들고, 무엇을 만들지 않는지 경계를 확립한다.
+
+```
+Core Features (핵심 기능)
+├── 반드시 있어야 하는 기능 3-5개는?
+├── 각 기능이 왜 필수인가? (없으면 어떻게 되나?)
+├── Nice-to-Have로 미룰 수 있는 것은?
+└── 명시적으로 만들지 않는 것은? (Anti-scope)
+
+Technical Constraints (기술 제약)
+├── 기술 스택이 이미 정해져 있나?
+├── 외부 서비스/API 의존성은?
+├── 성능 요구사항은? (응답시간, 동시접속 등)
+└── 보안/규제 요구사항은? (인증, 결제, 개인정보)
+
+Business Constraints (비즈니스 제약)
+├── 예산/일정 제약은?
+├── MVP 범위는 어디까지?
+└── 런칭 후 첫 번째 마일스톤은?
+```
+
+### Phase 3: 성공 지표 인터뷰
+
+```
+Metrics (지표)
+├── 핵심 KPI는 무엇인가? (최대 3개)
+├── 각 KPI의 현재 값과 목표 값은?
+├── 측정 방법은? (어떤 도구/데이터로?)
+└── 실패로 판단하는 기준은?
+```
+
+## Sub-PRD Mode 질문 트리
+
+기능마다 3단계 깊이로 질문한다. 한 번에 2-3개 질문, 답변 받으면 다음 깊이로.
+
+```
+Why (목적)
+├── 이 기능이 없으면 사용자에게 어떤 문제가 생기나?
+├── 핵심 사용자 시나리오는?
+└── 성공을 어떻게 측정하나?
+
+What (범위)
+├── Must-Have vs Nice-to-Have 경계는?
+├── 이 기능이 다루지 않는 것은?
+├── 어떤 데이터가 필요하고 어디서 오나?
+└── 기존 시스템과 연동 포인트는?
+
+How (설계)
+├── 사용자 흐름 (Happy Path → Exception Path)?
+├── 상태 전환이 있다면?
+├── 에러 케이스와 처리 방식은?
+└── 성능/보안 고려사항은?
+```

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

@@ -0,0 +1,108 @@
+---
+name: tsq-inspect
+description: |
+  프로젝트 파이프라인 전체 건강 점검. 데드코드, 죽은 프로세스, 끊어진 Hook 체인,
+  문서 drift, 고아 스킬, 미등록 스크립트, 설정 불일치를 탐지하여 리포트 생성.
+  Use when: "점검", "헬스체크", "건강 검진", "파이프라인 검증", "전체 점검",
+  "데드코드", "죽은 프로세스", "inspect", "health check", "프레임워크 진단",
+  "뭐가 빠졌지", "뭐가 고장났지", "설정 확인", "Hook 확인", "스킬 확인",
+  또는 릴리스 전 최종 점검, 대규모 작업 후 정합성 확인, 새 세션 시작 시 현황 파악.
+  프로젝트가 "이상하게 동작한다" 싶으면 이 스킬을 먼저 실행하라.
+version: "1.0.0"
+tags: [tsq, inspect, health, audit, pipeline, dead-code]
+user-invocable: true
+---
+
+# /tsq-inspect — 파이프라인 전체 건강 점검
+
+릴리스 전, 대규모 작업 후, 또는 "뭔가 이상하다" 싶을 때 실행하는 종합 진단.
+데드코드와 죽은 프로세스는 시간이 지나면 반드시 누적된다 — 정기적으로 제거해야 파이프라인이 건강하다.
+
+## Protocol
+
+1. **데이터 수집**: 아래 7개 영역을 자동 점검 (CLI + 파일 스캔)
+2. **리포트 생성**: 영역별 PASS/WARN/FAIL + 구체적 항목
+3. **권고 제시**: 수정 방법과 우선순위
+4. **사용자 확인**: 자동 수정 가능한 항목은 동의 후 즉시 처리
+
+## 점검 7영역
+
+### 1. Hook 정합성
+settings.json에 등록된 Hook vs 실제 스크립트 파일 대조.
+
+| 점검 | 방법 |
+|------|------|
+| 유령 Hook | settings.json에 등록됐지만 스크립트 파일 없음 |
+| 고아 스크립트 | scripts/ 디렉토리에 있지만 settings.json에 미등록 |
+| Fail 전략 불일치 | `\|\| true` 유무와 의도된 fail-closed/open 비교 |
+
+### 2. 스킬 정합성
+templates/base/skills/ vs 배포된 .claude/skills/ 대조.
+
+| 점검 | 방법 |
+|------|------|
+| 고아 스킬 | 디렉토리 존재하지만 SKILL.md 없음 |
+| Frontmatter 누락 | name 또는 description 빠짐 |
+| 120줄 초과 | Progressive Disclosure 기준 위반 |
+| references/ 포인터 끊김 | SKILL.md에서 참조하지만 파일 없음 |
+| 미배포 스킬 | config의 SKILL_PRESETS에 없고 BASE_SKILLS에도 없음 |
+
+### 3. CLI 정합성
+src/index.ts 등록 vs src/commands/ 파일 대조.
+
+| 점검 | 방법 |
+|------|------|
+| 미등록 커맨드 | src/commands/*.ts 있지만 index.ts에 import 없음 |
+| 유령 import | index.ts에 import 있지만 파일 없음 |
+| 빌드 동기화 | src/ vs dist/ 타임스탬프 비교 |
+
+### 4. 문서 Drift
+보완계획/SSOT 문서의 주장 vs 실제 수치 대조.
+
+| 점검 | 방법 |
+|------|------|
+| Hook 수 불일치 | 문서 주장 vs settings.json 실제 수 |
+| 스킬 수 불일치 | 문서 주장 vs 실제 디렉토리 수 |
+| 테스트 수 불일치 | 문서 주장 vs `npm test` 실제 수 |
+| CLI 수 불일치 | 문서 주장 vs index.ts 등록 수 |
+| 로드맵 상태 | 이슈 상태(open/closed) vs 문서 "완료/미착수" |
+
+**상세 점검 항목은 `references/checklist.md`를 Read하여 참조.**
+
+### 5. 테스트 커버리지 갭
+소스 파일 대비 테스트 파일 존재 여부.
+
+| 점검 | 방법 |
+|------|------|
+| 테스트 없는 소스 | src/**/*.ts에 대응하는 *.test.ts 없음 |
+| 빈 테스트 | .test.ts 존재하지만 describe/it 블록 없음 |
+
+### 6. 설정 일관성
+config.json, package.json, tsconfig.json 간 교차 검증.
+
+| 점검 | 방법 |
+|------|------|
+| 버전 불일치 | package.json vs config.json framework_version |
+| 스택 불일치 | config.json stack vs 실제 dependencies |
+| 스크립트 누락 | test/build 스크립트 미정의 |
+
+### 7. 상태 파일 위생
+.timsquad/state/ 디렉토리의 정합성.
+
+| 점검 | 방법 |
+|------|------|
+| 좀비 토큰 | controller-active 존재하지만 Controller 미실행 |
+| Stale workflow | workflow.json의 current_phase와 current-phase.json 불일치 |
+| 깨진 JSONL | decisions.jsonl에 유효하지 않은 JSON 행 |
+| 잔여 임시 파일 | *.tmp, *.bak 등 |
+
+## 리포트
+
+`.timsquad/logs/inspect-{date}.md`에 저장. 영역별 PASS/WARN/FAIL + 상세 항목 + 권고.
+
+## Rules
+
+- 점검은 읽기 전용 — 자동 수정은 반드시 사용자 동의 후
+- 리포트는 `.timsquad/logs/inspect-{date}.md`에 저장
+- `tsq audit score`를 내부적으로 실행하여 7영역 점수도 포함
+- FAIL이 1건이라도 있으면 사용자에게 즉시 알림

package/templates/base/skills/tsq-inspect/references/checklist.md

@@ -0,0 +1,162 @@
+---
+title: Inspect Checklist
+category: guide
+---
+
+# Inspect 상세 점검 체크리스트
+
+## 1. Hook 정합성 — 실행 커맨드
+
+```bash
+# settings.json에서 등록된 스크립트 목록 추출
+REGISTERED=$(grep '"command"' .claude/settings.json 2>/dev/null | \
+  grep -oE 'scripts/[a-z-]+\.sh' | sort -u)
+
+# 실제 스크립트 파일 목록
+ACTUAL=$(ls .claude/scripts/*.sh 2>/dev/null | xargs -I{} basename {} | sort -u)
+
+# 차이 비교
+diff <(echo "$REGISTERED") <(echo "$ACTUAL")
+```
+
+**판정 기준:**
+- 유령 Hook (등록 O, 파일 X) → **FAIL**
+- 고아 스크립트 (등록 X, 파일 O) → **WARN** (유틸리티일 수 있음)
+- Fail 전략: `|| true` 없으면 fail-closed, 있으면 fail-open
+
+## 2. 스킬 정합성 — 실행 커맨드
+
+```bash
+# 전체 스킬 디렉토리
+SKILLS=$(ls -d .claude/skills/tsq-*/ 2>/dev/null)
+
+for SKILL_DIR in $SKILLS; do
+  SKILL_FILE="$SKILL_DIR/SKILL.md"
+  NAME=$(basename "$SKILL_DIR")
+
+  # SKILL.md 존재 확인
+  [ ! -f "$SKILL_FILE" ] && echo "FAIL: $NAME — SKILL.md 없음" && continue
+
+  # Frontmatter 확인
+  head -20 "$SKILL_FILE" | grep -q '^name:' || echo "WARN: $NAME — name 누락"
+  head -20 "$SKILL_FILE" | grep -q '^description:' || echo "WARN: $NAME — description 누락"
+
+  # 라인수 확인 (120줄 기준)
+  LINES=$(wc -l < "$SKILL_FILE")
+  [ "$LINES" -gt 120 ] && echo "WARN: $NAME — ${LINES}줄 (120줄 초과)"
+
+  # references/ 포인터 검증 (한 줄씩 처리)
+  grep -oE 'references/[a-zA-Z0-9_-]+\.md' "$SKILL_FILE" 2>/dev/null | sort -u | while IFS= read -r REF; do
+    [ -z "$REF" ] && continue
+    [ ! -f "$SKILL_DIR/$REF" ] && echo "FAIL: $NAME — $REF 파일 없음"
+  done
+done
+```
+
+## 3. CLI 정합성 — 실행 커맨드
+
+```bash
+# index.ts에서 import된 커맨드 파일
+IMPORTED=$(grep "from './commands/" src/index.ts | \
+  grep -oE "commands/[a-z]+\.js" | sed 's/\.js//' | sort)
+
+# 실제 커맨드 파일
+ACTUAL=$(ls src/commands/*.ts 2>/dev/null | \
+  xargs -I{} basename {} .ts | sort)
+
+# 비교
+diff <(echo "$IMPORTED" | sed 's|commands/||') <(echo "$ACTUAL")
+```
+
+## 4. 문서 Drift — 점검 대상 패턴
+
+문서에서 수치를 추출하는 정규식 패턴:
+
+```
+Hook 수:     /Hook[:\s]*(\d+)개/  또는  /(\d+)개.*Hook/
+스킬 수:     /(\d+)개.*skill/i  또는  /스킬[:\s]*(\d+)/
+테스트 수:   /(\d+)\s*테스트/  또는  /(\d+)\s*tests?/i
+CLI 수:      /(\d+)개.*커맨드/  또는  /CLI[:\s]*(\d+)/
+```
+
+비교 대상 실제 수치:
+- Hook: `grep -c '"command"' .claude/settings.json` ÷ 2 (중복 키 제거)
+- 스킬: `ls -d .claude/skills/tsq-*/ | wc -l`
+- 테스트: `npm test 2>&1 | grep -oE '\d+ passed'`
+- CLI: `grep 'registerCommand' src/index.ts | wc -l` 또는 `node dist/index.js --help`
+
+## 5. 테스트 커버리지 갭
+
+```bash
+# 소스 파일 목록 (테스트/설정 제외)
+SRC_FILES=$(find src -name '*.ts' \
+  -not -name '*.test.*' -not -name '*.spec.*' \
+  -not -name '*.d.ts' -not -path '*/types/*')
+
+for SRC in $SRC_FILES; do
+  BASE=$(basename "$SRC" .ts)
+  # 대응 테스트 파일 검색
+  FOUND=$(find tests -name "${BASE}.test.*" -o -name "${BASE}.spec.*" 2>/dev/null | head -1)
+  [ -z "$FOUND" ] && echo "GAP: $SRC — 테스트 없음"
+done
+```
+
+## 6. 설정 일관성
+
+```bash
+# package.json version vs config.json framework_version
+PKG_VER=$(jq -r '.version' package.json)
+CFG_VER=$(jq -r '.project.framework_version // "없음"' .timsquad/config.json 2>/dev/null)
+[ "$PKG_VER" != "$CFG_VER" ] && echo "WARN: 버전 불일치 pkg=$PKG_VER cfg=$CFG_VER"
+
+# config stack vs actual dependencies
+CONFIG_STACK=$(jq -r '.project.stack // [] | .[]' .timsquad/config.json 2>/dev/null)
+for TECH in $CONFIG_STACK; do
+  grep -q "\"$TECH\"" package.json 2>/dev/null || \
+    echo "WARN: stack '$TECH'가 config에 있지만 dependencies에 없음"
+done
+```
+
+## 7. 상태 파일 위생
+
+```bash
+STATE_DIR=".timsquad/state"
+
+# 좀비 토큰
+if [ -f "$STATE_DIR/controller-active" ]; then
+  # 10분 이상 된 파일이면 좀비
+  AGE=$(( $(date +%s) - $(stat -f %m "$STATE_DIR/controller-active" 2>/dev/null || echo 0) ))
+  [ "$AGE" -gt 600 ] && echo "WARN: 좀비 controller-active (${AGE}초 전)"
+fi
+
+# Phase 동기화
+if [ -f "$STATE_DIR/workflow.json" ] && [ -f "$STATE_DIR/current-phase.json" ]; then
+  WF_PHASE=$(jq -r '.current_phase.id // "null"' "$STATE_DIR/workflow.json")
+  CP_PHASE=$(jq -r '.current // "null"' "$STATE_DIR/current-phase.json")
+  [ "$WF_PHASE" != "$CP_PHASE" ] && echo "FAIL: Phase 불일치 workflow=$WF_PHASE current=$CP_PHASE"
+fi
+
+# JSONL 검증
+if [ -f "$STATE_DIR/decisions.jsonl" ]; then
+  LINE_NUM=0
+  while IFS= read -r line; do
+    LINE_NUM=$((LINE_NUM + 1))
+    echo "$line" | jq empty 2>/dev/null || echo "FAIL: decisions.jsonl 행 $LINE_NUM — 유효하지 않은 JSON"
+  done < "$STATE_DIR/decisions.jsonl"
+fi
+
+# 잔여 임시 파일
+TEMP=$(find "$STATE_DIR" -name "*.tmp" -o -name "*.bak" 2>/dev/null)
+[ -n "$TEMP" ] && echo "WARN: 잔여 임시 파일: $TEMP"
+```
+
+## 자동 수정 가능 항목
+
+사용자 동의 후 즉시 처리 가능한 항목:
+
+| 항목 | 자동 수정 방법 |
+|------|-------------|
+| 좀비 controller-active | `rm .timsquad/state/controller-active` |
+| 잔여 임시 파일 | `rm *.tmp *.bak` |
+| Phase 불일치 | workflow.json 기준으로 current-phase.json 동기화 |
+| 깨진 JSONL 행 | 해당 행 삭제 |

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

@@ -0,0 +1,58 @@
+---
+name: tsq-quick
+description: |
+  Controller 경유 단일 태스크 실행. SSOT, 메모리, 현재 파이프라인 상태를 자동 참조하여
+  컨텍스트를 잃지 않고 빠르게 작업을 완료한다. 풀 파이프라인(Phase-Sequence) 오버헤드 없이
+  단일 태스크만 실행하므로, 기능 전체 구현이 아닌 부분 작업에 적합하다.
+  Use when: "/tsq-quick", "빨리 해줘", "간단한 수정", "이것만", "버그 수정",
+  "리팩토링", "메서드 추가", "API 하나 추가", "테스트 작성", "이 파일 수정",
+  "다음 태스크", "태스크 13 실행", 또는 planning.md의 특정 태스크 하나를 실행할 때.
+  단일 파일/모듈 범위의 코딩, 수정, 추가 작업이면 이 스킬을 사용한다.
+version: "1.0.0"
+tags: [tsq, quick, controller, pipeline]
+user-invocable: true
+---
+
+# /tsq-quick — Controller 경유 단일 태스크
+
+풀 파이프라인 없이 단일 태스크를 Controller 경유로 실행한다.
+Controller를 경유하는 이유: SSOT/메모리/현재 상태를 주입받아야 이전 작업과 일관성을 유지할 수 있고,
+Capability Token으로 서브에이전트의 변경 범위를 제한할 수 있기 때문이다.
+
+## Protocol
+
+1. **현재 위치 확인**: `.timsquad/state/workflow.json` → 진행 중인 Phase/Sequence/Task 파악
+2. **태스크 결정**:
+   - 사용자가 태스크를 지정 → 해당 태스크 실행
+   - 미지정 → `workflow.json`의 다음 미완료 태스크 실행
+3. **SSOT 참조**: `.timsquad/ssot-map.yaml` → 해당 태스크 관련 spec 로드
+4. **메모리 참조**: `memory/` 디렉토리 읽기
+5. **Controller 위임** (tsq-controller Protocol, 단일 태스크 모드):
+   - Capability Token 발급
+   - 에이전트 파일 + spec + methodology 조합
+   - Task() 단일 호출
+   - Completion Report 검증
+   - Capability Token 회수
+6. **로그 기록**: 최소 로그 (L1 수준)
+7. **테스트 게이트**: 변경된 파일 관련 단위 테스트만 실행
+8. **workflow.json 갱신**: 완료된 태스크 상태 기록
+
+## vs /tsq-full
+
+| 항목 | /tsq-quick | /tsq-full |
+|------|-----------|-----------|
+| Phase-Sequence-Task | X (단일) | O (전체) |
+| Controller 경유 | O | O |
+| SSOT/메모리 참조 | O | O |
+| 게이트 | unit만 | unit → integration → e2e |
+| Librarian 호출 | X | O |
+| planning.md 필요 | X | O |
+
+## Usage
+
+```
+/tsq-quick 로그인 버튼 색상을 파란색으로 변경
+/tsq-quick UserService에 이메일 검증 메서드 추가
+/tsq-quick 태스크 13 실행
+/tsq-quick                  ← 다음 미완료 태스크 자동 실행
+```

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

@@ -4,7 +4,7 @@ description: |
   TimSquad 파이프라인 시작. 데몬 기동, 프로토콜 활성화, 현재 상태 복원.
   초기화 직후 프로젝트는 자동으로 온보딩 모드 진입 (SSOT 문서 작성 가이드).
   Use when: 사용자가 /tsq-start로 TimSquad 파이프라인을 시작할 때.
-version: "2.0.0"
+version: "2.1.0"
 tags: [tsq, pipeline, start, onboarding]
 user-invocable: true
 ---
@@ -23,68 +23,41 @@ user-invocable: true
 ## 온보딩 감지 (Step 5)
 
 `.timsquad/ssot/`의 `.md` 파일을 스캔하여 작성 완료도 판정:
-- **empty**: placeholder만 존재 (`[Resource Name]`, `TBD`, `example.com` 등이 50%+)
+- **empty**: placeholder만 존재 (50%+)
 - **partial**: 일부 섹션만 작성
 - **filled**: 주요 섹션 작성 완료
 
 **진입 조건** (하나라도 해당): prd.md가 empty / required 70%+ empty / progress=0
 
-온보딩 시 SSOT 현황(⬜/🟨/✅)을 보여주고 3가지 선택지 제시:
+온보딩 시 SSOT 현황을 보여주고 3가지 선택지 제시:
 1. 온보딩 시작 (권장) — PRD부터 순서대로
 2. 특정 문서만 작성
 3. 건너뛰기
 
 ## 온보딩 프로세스
 
-**작성 우선순위**: prd → requirements → data-design → service-spec → 타입별 필수
+**우선순위**: 개발환경(강제) → prd(grill 강제) → Sub-PRD(grill 강제) → requirements → data-design → service-spec
 
-타입별 추가 우선 문서는 `references/onboarding-questions.md` 참조.
+**각 Step의 상세 절차는 `references/onboarding-steps.md`를 Read하여 참조한다.**
 
-**각 문서 작성 흐름**:
-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 비어있으면 자동 완료.
+| Step | 내용 | 강제 여부 |
+|------|------|:---------:|
+| 0 | 테스트 프레임워크 설치 | 건너뛸 수 없음 |
+| 1 | `/tsq-grill prd` — PRD 심층 인터뷰 | 건너뛸 수 없음 |
+| 2 | `/tsq-grill` 반복 — Sub-PRD 작성 | 중단 가능 |
+| 3 | 나머지 SSOT 문서 | 선택적 |
 
-## 온보딩 완료 후 자동 전환
+타입별 추가 우선 문서는 `references/onboarding-questions.md` 참조.
 
-모든 SSOT 문서 filled + grill.pending 비어있으면 온보딩 완료. 이후:
+## 온보딩 완료 후 자동 전환
 
-1. **`/tsq-decompose` 자동 안내**: "온보딩 완료. `/tsq-decompose`로 Phase-Sequence-Task 실행 계획을 생성하시겠습니까?"
-2. 사용자 승인 시 `/tsq-decompose` 실행 (Sub-PRD → DAG → planning.md)
-3. planning.md 확정 후 → 정상 파이프라인 진행 (Controller 경유 위임)
+모든 SSOT 문서 filled + grill.pending 비어있으면:
+1. `/tsq-decompose` 자동 안내 (Phase-Sequence-Task 생성)
+2. planning.md 확정 후 정상 파이프라인 진행
 
 ## 파이프라인 분기
 
-온보딩 완료 + planning.md 확정 후 사용자가 작업을 지시하면:
+온보딩 완료 + planning.md 확정 후:
 - **파이프라인 적합** (새 기능, API, DB, 아키텍처) → controller 경유 위임
 - **단순 작업** (오타, 스타일, 1-2줄) → 직접 수행 + 최소 로그
 - **모호한 경우** → 사용자에게 선택지 제시