timsquad 3.5.0 → 3.7.0

package/templates/base/skills/tsq-security/rules/input-validation.md

@@ -0,0 +1,68 @@
+---
+title: Input Validation
+impact: CRITICAL
+tags: security, validation, sanitization, injection
+---
+
+# Input Validation
+
+## Principle
+Never trust user input. Validate, sanitize, and constrain all external data before processing.
+
+## Allowlist Over Denylist
+```typescript
+// Bad: denylist — easy to bypass
+const forbidden = ['<script>', 'onclick', 'onerror'];
+if (forbidden.some(f => input.includes(f))) throw new Error('Invalid');
+
+// Good: allowlist — only permit known-safe values
+const ALLOWED_ROLES = ['admin', 'editor', 'viewer'] as const;
+if (!ALLOWED_ROLES.includes(role)) throw new Error('Invalid role');
+```
+
+## Schema Validation
+```typescript
+import { z } from 'zod';
+
+const UserInput = z.object({
+  name: z.string().min(1).max(100).trim(),
+  email: z.string().email().max(254),
+  age: z.number().int().min(0).max(150),
+});
+
+// Validate at boundary (controller/handler)
+const data = UserInput.parse(req.body);
+```
+
+## Parameterized Queries
+```typescript
+// Bad: string interpolation — SQL injection risk
+const q = `SELECT * FROM users WHERE id = '${id}'`;
+
+// Good: parameterized query
+const q = 'SELECT * FROM users WHERE id = $1';
+await db.query(q, [id]);
+
+// Good: ORM with type-safe parameters
+await userRepo.findOneBy({ id: parseInt(id, 10) });
+```
+
+## Sanitize HTML Output
+```typescript
+// Bad
+element.innerHTML = userInput;
+
+// Good: escape or use textContent
+element.textContent = userInput;
+
+// Good: DOMPurify for rich content
+import DOMPurify from 'dompurify';
+element.innerHTML = DOMPurify.sanitize(userInput);
+```
+
+## Checklist
+- Validate type, length, format, and range at the application boundary
+- Use allowlists for enumerated values (roles, statuses, types)
+- Use parameterized queries or ORM — never interpolate user input into SQL
+- Sanitize output based on context (HTML, URL, SQL, shell)
+- Reject unexpected fields; do not pass raw request bodies to business logic

package/templates/base/skills/tsq-security/rules/secrets-management.md

@@ -0,0 +1,65 @@
+---
+title: Secrets Management
+impact: HIGH
+tags: security, secrets, env, gitignore, rotation
+---
+
+# Secrets Management
+
+## Never Hardcode Secrets
+```typescript
+// Bad: hardcoded secret
+const API_KEY = 'sk-1234567890abcdef';
+const DB_URL = 'postgres://admin:password@db:5432/prod';
+
+// Good: environment variables
+const API_KEY = process.env.API_KEY;
+const DB_URL = process.env.DATABASE_URL;
+
+// Better: secret manager for production
+const API_KEY = await secretManager.getSecret('api-key');
+```
+
+## Environment Variables
+- Use `.env` files for local development only
+- Load with `dotenv` at application entry point, not in library code
+- Validate required env vars at startup
+```typescript
+const required = ['DATABASE_URL', 'JWT_SECRET', 'API_KEY'];
+for (const key of required) {
+  if (!process.env[key]) throw new Error(`Missing env var: ${key}`);
+}
+```
+
+## .gitignore Rules
+```gitignore
+# Must be in .gitignore — never commit secrets
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+```
+
+- Use `.env.example` with placeholder values for documentation
+- Run `git log --all -p -- .env` to verify secrets were never committed
+- If a secret was committed, rotate it immediately — git history persists
+
+## Secret Rotation
+- Rotate secrets on a regular schedule (90 days recommended)
+- Support dual-read during rotation (accept old + new key simultaneously)
+- Automate rotation via secret manager (AWS Secrets Manager, Vault, etc.)
+- Revoke old secrets after confirming the new ones work
+
+## Production Practices
+- Use a dedicated secret manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager)
+- Grant least-privilege access to secrets per service
+- Audit secret access logs regularly
+- Never log secret values; mask them in error output
+
+## Checklist
+- No secrets in source code, config files, or container images
+- `.env` and key files listed in `.gitignore`
+- Required env vars validated at startup with clear error messages
+- Secrets rotated on schedule; old secrets revoked
+- Production uses a secret manager, not plain env vars

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

@@ -0,0 +1,58 @@
+---
+name: tsq-spec
+description: |
+  SSOT(Single Source of Truth) 문서 존재 여부를 확인하고, 미존재 시 구현 전 스펙 작성을 안내한다.
+  `/tsq-spec <기능명>`으로 호출하면 해당 기능의 SSOT 문서를 찾아 상태를 보고한다.
+  스펙 없이 구현하는 것을 방지하여 문서-코드 일관성을 유지한다.
+version: "1.0.0"
+tags: [tsq, spec, ssot, gate, documentation]
+user-invocable: true
+argument-hint: "[기능명] — SSOT 문서 존재 여부 확인"
+---
+
+# Spec Gate
+
+SSOT 문서 존재 여부를 확인하여 스펙 없는 구현을 방지한다.
+
+## Contract
+
+- **Trigger**: `/tsq-spec` 호출 또는 구현 시작 전 자동 확인
+- **Input**: `$ARGUMENTS` (기능명) 또는 미지정 시 전체 SSOT 상태
+- **Output**: SSOT 상태 리포트 (존재/stale/미존재) + 권장 액션
+- **Error**: SSOT 디렉토리 자체가 없을 경우 "NOT FOUND" 안내
+- **Dependencies**: tsq-protocol
+
+## Protocol
+
+1. **SSOT 검색**: `$ARGUMENTS`로 전달된 기능명으로 `.timsquad/ssot/` 디렉토리 탐색
+2. **존재 확인**: 해당 기능의 스펙 문서(PRD, 설계문서, API 스펙) 존재 여부 판단
+3. **상태 판정**:
+   - **존재 + 최신**: 스펙 요약 출력 + "구현 가능" 안내
+   - **존재 + stale**: "스펙 갱신 필요" + `tsq compile` 재실행 안내
+   - **미존재**: advisory 경고 + 스펙 작성 가이드 제공
+4. **결과 리포트**: 상태 + 권장 액션을 구조화하여 출력
+
+## Verification
+
+| Check | Method | Pass Criteria |
+|-------|--------|---------------|
+| SSOT 파일 존재 | `.timsquad/ssot/` 탐색 | 관련 문서 1개 이상 |
+| stale 여부 | compile-manifest hash 비교 | hash 일치 |
+| 스펙 커버리지 | 기능 키워드 매칭 | 해당 기능 언급 존재 |
+
+## Quick Rules
+
+### Gate 동작
+- **미존재 시**: advisory 경고 (차단 아님)
+  ```
+  [SPEC GATE] 기능 "{name}"에 대한 SSOT 문서가 없습니다.
+  스펙 먼저 작성하세요: .timsquad/ssot/{name}.md
+  가이드: PRD → 설계문서 → Compiled Spec 순서
+  ```
+- **stale 시**: `tsq compile` 재실행 안내
+  ```
+  [SPEC GATE] SSOT 문서가 최신이 아닙니다. `tsq compile` 재실행 필요.
+  ```
+- **Phase gate에서만 실제 차단** (일반 사용 시 advisory)
+- `$ARGUMENTS` 미지정 시 전체 SSOT 상태 요약
+- PRD, 설계문서, API 스펙 모두 SSOT로 인정

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줄) → 직접 수행 + 최소 로그
+- **모호한 경우** → 사용자에게 선택지 제시

package/templates/base/skills/tsq-start/references/onboarding-questions.md

@@ -0,0 +1,177 @@
+---
+title: "SSOT 온보딩 인터뷰 가이드"
+category: guide
+---
+
+# SSOT 온보딩 인터뷰 가이드
+
+> 각 SSOT 문서를 작성하기 위한 핵심 질문 목록.
+> /tsq-start 온보딩 모드에서 순서대로 질문하여 초안을 생성한다.
+
+## 사용법
+
+1. 해당 문서의 질문을 순서대로 진행
+2. 답변을 수집하여 SSOT 템플릿의 placeholder를 채움
+3. 사용자가 "모르겠다" / "나중에"라고 하면 해당 섹션은 TBD로 남김
+4. 최소 필수 질문(★)만 답변해도 유효한 초안 생성 가능
+
+---
+
+## prd.md — 제품 요구사항
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 이 프로젝트가 해결하는 핵심 문제는 무엇인가요? | ★ | 1.1 배경 |
+| 2 | 주요 사용자(타겟)는 누구인가요? | ★ | 1.2 타겟 사용자 |
+| 3 | 핵심 기능 3가지를 말해주세요. | ★ | 2. 핵심 기능 |
+| 4 | MVP 범위는 어디까지인가요? (있다면) | | 3. 범위 |
+| 5 | 경쟁 제품이나 참고 서비스가 있나요? | | 1.3 경쟁 분석 |
+
+**초안 생성 규칙**: 질문 1-3 답변으로 PRD의 개요, 핵심 기능, 사용자 스토리 섹션 채움. 나머지는 TBD.
+
+---
+
+## requirements.md — 요구사항
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 반드시 있어야 하는 기능(Must)은? | ★ | FR - Must |
+| 2 | 있으면 좋은 기능(Should/Could)은? | | FR - Should/Could |
+| 3 | 성능 요구사항이 있나요? (동시 접속, 응답 시간 등) | | NFR - 성능 |
+| 4 | 보안 요구사항이 있나요? (인증, 암호화 등) | | NFR - 보안 |
+| 5 | 기술 제약이 있나요? (특정 언어, 프레임워크, 클라우드 등) | | NFR - 기술 제약 |
+
+**초안 생성 규칙**: Must 기능을 기능 요구사항 테이블로 변환. 각 항목에 ID 부여 (FR-001~).
+
+---
+
+## data-design.md — 데이터 설계
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 주요 데이터 엔티티(테이블)는 무엇인가요? (예: 사용자, 주문, 상품) | ★ | 1. ERD |
+| 2 | 엔티티 간 관계를 설명해주세요. (1:N, M:N 등) | ★ | 1. ERD |
+| 3 | 각 엔티티의 핵심 필드는? | | 2. 테이블 상세 |
+| 4 | 암호화가 필요한 민감 데이터가 있나요? | | 3. 보안 |
+| 5 | 검색이 빈번한 필드는? (인덱스 후보) | | 4. 인덱스 |
+
+**초안 생성 규칙**: 엔티티 목록으로 ERD 다이어그램 + 테이블 스키마 생성. PK는 UUID, 공통 필드(created_at, updated_at) 자동 추가.
+
+---
+
+## service-spec.md — 서비스(API) 명세
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 인증 방식은 무엇인가요? (JWT, Session, OAuth 등) | ★ | 1. 개요 |
+| 2 | 주요 API 리소스(엔드포인트 그룹)는? | ★ | 2+ 리소스별 |
+| 3 | 각 리소스의 CRUD 중 필요한 작업은? | | 2+ 리소스별 |
+| 4 | 특수 비즈니스 엔드포인트가 있나요? (결제, 알림 등) | | 추가 섹션 |
+| 5 | 페이지네이션 방식은? (offset, cursor) | | 1. 개요 |
+
+**초안 생성 규칙**: 리소스별 RESTful 엔드포인트 자동 생성. 요청/응답 스키마는 data-design 참조.
+
+---
+
+## ui-ux-spec.md — UI/UX 명세
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 주요 화면(페이지)은 몇 개이고 어떤 것들인가요? | ★ | 화면 목록 |
+| 2 | 디자인 참고 사이트나 컬러 시스템이 있나요? | | 디자인 시스템 |
+| 3 | 반응형이 필요한가요? 지원 기기는? | | 레이아웃 |
+| 4 | 다국어 지원이 필요한가요? | | i18n |
+
+---
+
+## navigation-map.md — 네비게이션 맵 (mobile-app)
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 메인 탭은 몇 개이고 각각 무엇인가요? | ★ | 1. 구조 |
+| 2 | 로그인/회원가입 흐름이 있나요? | ★ | Auth Stack |
+| 3 | 딥링크가 필요한 화면이 있나요? | | 4. 딥링크 |
+| 4 | 모달/바텀시트가 필요한 화면은? | | Modal Stack |
+
+---
+
+## compliance-matrix.md — 컴플라이언스 (fintech)
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 어떤 금융 서비스인가요? (결제, 거래소, 송금 등) | ★ | 1. 적용 규제 |
+| 2 | 카드 결제를 직접 처리하나요, PG사를 사용하나요? | ★ | 3. PCI DSS |
+| 3 | 해외 사용자 서비스 계획이 있나요? (GDPR 등) | | 1. 적용 규제 |
+| 4 | 전자금융업 등록 상태는? | | 5. 인증 일정 |
+
+---
+
+## sdk-spec.md — SDK 명세 (platform)
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | SDK 사용자는 누구인가요? (외부 개발자, 내부팀) | ★ | 1. 개요 |
+| 2 | 지원 런타임은? (Node, Browser, Python 등) | ★ | 1. 개요 |
+| 3 | 주요 리소스/메서드는? | ★ | 2. 공개 API |
+| 4 | 버전 정책은? (SemVer, CalVer) | | 5. 버전 정책 |
+
+---
+
+## state-machine.md — 상태 머신
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 상태 관리가 필요한 엔티티는? (주문, 결제, 배송 등) | ★ | 1. 개요 |
+| 2 | 각 엔티티의 가능한 상태 값은? | ★ | 2. 상태 정의 |
+| 3 | 상태 전이 시 부수 효과가 있나요? (알림, 외부 API 등) | | 2.5 부수 효과 |
+
+---
+
+## infra-topology.md — 인프라 토폴로지 (infra)
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 클라우드 프로바이더는? (AWS, GCP, Azure 등) | ★ | 1. 아키텍처 |
+| 2 | 서비스는 몇 개이고 어떤 역할인가요? | ★ | 3. 서비스 구성 |
+| 3 | DB와 캐시는 무엇을 사용하나요? | | 3. 서비스 구성 |
+| 4 | 환경은 몇 개인가요? (dev, staging, prod) | | 5. 환경별 차이 |
+
+---
+
+## monitoring-spec.md — 모니터링
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 가용성 목표는? (99.9%, 99.99% 등) | ★ | 1. SLI/SLO |
+| 2 | 알림은 어디로 보내나요? (Slack, PagerDuty 등) | ★ | 5. 알림 |
+| 3 | 추적할 비즈니스 메트릭이 있나요? | | 2.3 비즈니스 메트릭 |
+
+---
+
+## performance-budget.md — 성능 예산
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 주요 페이지의 로딩 목표는? | ★ | 1. 성능 목표 |
+| 2 | API 응답 시간 목표는? | ★ | 3. API 성능 예산 |
+| 3 | JS 번들 크기 제한이 있나요? | | 1.3 리소스 예산 |
+
+---
+
+## component-map.md — 컴포넌트 맵
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | UI 프레임워크는? (React, Vue, Flutter 등) | ★ | 1. 계층 |
+| 2 | 디자인 시스템이 있나요? (Material, 자체 등) | | 5. 디자인 토큰 |
+| 3 | 공유 컴포넌트로 만들 것은? (Button, Card, Modal 등) | | 2-3. 컴포넌트 |
+
+---
+
+## audit-trail-spec.md — 감사 추적
+
+| # | 질문 | 필수 | 채울 섹션 |
+|:-:|------|:---:|----------|
+| 1 | 감사가 필요한 이벤트 유형은? (인증, 거래, 데이터 변경) | ★ | 1. 감사 대상 |
+| 2 | 법적 보존 기간 요구사항이 있나요? | ★ | 1. 보존 기간 |
+| 3 | 로그 변조 방지가 필요한가요? | | 3. 무결성 보장 |

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

@@ -0,0 +1,32 @@
+---
+name: tsq-status
+description: |
+  프로젝트 현재 상태 확인. Phase, 시퀀스, SSOT, 에이전트 상태를 요약 보고.
+  Use when: /tsq-status, "현재 상태", "프로젝트 상태", "어디까지 했나"
+version: "1.0.0"
+tags: [tsq, status, report]
+user-invocable: true
+---
+
+# /tsq-status — Project Status Report
+
+## Protocol
+
+1. **Phase 확인**: `.timsquad/state/current-phase.json` 읽기
+2. **Phase Memory**: `.timsquad/state/phase-memory.md` 존재 시 carry-over / 주의사항 추출
+3. **SSOT 상태**: `.timsquad/ssot/` 디렉토리의 문서 존재/작성 여부 확인
+4. **워크플로우 상태**: `.timsquad/state/workflow.json` 읽기 (활성 시퀀스, 완료 Phase)
+5. **최근 로그**: `.timsquad/logs/` 에서 최근 활동 요약
+6. **세션 메트릭**: `.timsquad/.daemon/session-state.json` 읽기 → tokenInput/tokenOutput/tokenCacheRead 추출
+7. **SSOT Drift**: `.timsquad/.daemon/drift-warnings.json` 존재 시 미갱신 문서 목록 추출
+8. **요약 출력**:
+   ```
+   ## Project Status
+   - Phase: {current} ({progress}%)
+   - SSOT: {filled}/{total} documents
+   - Active sequences: {list or none}
+   - Carry-over: {items from phase-memory or "none"}
+   - Tokens (est): {input + output} (cache hit: {cacheRead / (input + cacheRead) * 100}%)
+   - SSOT Drift: {count} documents outdated ({list}) 또는 "none"
+   - Last activity: {date — summary}
+   ```

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

@@ -1,9 +1,18 @@
 ---
-name: tdd
-description: Test-Driven Development 방법론 가이드라인
+name: tsq-tdd
+description: |
+  Test-Driven Development 방법론 가이드라인. Red-Green-Refactor 사이클, 테스트 우선 설계 원칙.
+  테스트 도구·패턴·커버리지 전략은 tsq-testing 스킬 참조.
+  Use when: TDD 방식으로 개발할 때, 테스트 먼저 작성 후 구현할 때, Red-Green-Refactor 사이클 적용 시.
 version: "1.0.0"
-tags: [tdd, methodology, testing]
+tags: [tsq, tdd, methodology, testing]
 user-invocable: false
+hooks:
+  PreToolUse:
+    - matcher: "Write|Edit"
+      hooks:
+        - type: prompt
+          prompt: "TDD: 이 파일에 대한 테스트가 먼저 작성되었는지 확인하라. 테스트 없이 구현 코드를 작성하면 Red-Green-Refactor 사이클을 위반한다."
 ---
 
 # TDD (Test-Driven Development)

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

@@ -0,0 +1,69 @@
+---
+name: tsq-testing
+description: |
+  테스트 전략·도구·패턴 가이드라인. 테스트 피라미드, Given-When-Then 패턴, 커버리지 기준.
+  방법론(Red-Green-Refactor 사이클)은 tsq-tdd 스킬 참조.
+  Use when: 테스트 작성, 단위 테스트, 통합 테스트, E2E, 커버리지, 테스트 구조 설계 시.
+version: "1.0.0"
+tags: [tsq, testing, tdd, quality]
+user-invocable: false
+---
+
+# Testing
+
+품질 보장을 위한 테스트 작성 가이드라인.
+
+## Philosophy
+
+- Red-Green-Refactor (TDD 사이클) 준수
+- 테스트 피라미드: Unit(다수) > Integration(중간) > E2E(소수)
+- 행동(behavior) 테스트 — 구현 디테일이 아닌 결과 검증
+
+## Contract
+
+- **Trigger**: 테스트 작성/수정 태스크, 코드 변경 후 테스트 필요 시
+- **Input**: 테스트 대상 코드 + 요구사항
+- **Output**: Given-When-Then 패턴 테스트 + 커버리지 기준 충족
+- **Error**: 커버리지 미달 시 추가 테스트 작성
+- **Dependencies**: 없음
+
+## Protocol
+
+1. **Red**: 실패하는 테스트 작성
+2. **Green**: 테스트를 통과하는 최소 코드 작성
+3. **Refactor**: 코드 정리 (테스트는 계속 통과)
+4. **Coverage 확인**: 기준 충족 여부 점검
+
+## Verification
+
+| Check | Command | Pass Criteria |
+|-------|---------|---------------|
+| 테스트 실행 | `npm test` | exit code 0 |
+| 라인 커버리지 | coverage report | >= 80% |
+| 브랜치 커버리지 | coverage report | >= 70% |
+| 3카테고리 | 수동 검증 | Happy/Edge/Error 포함 |
+
+## Resources
+
+| Priority | Type | Resource | Description |
+|----------|------|----------|-------------|
+| HIGH | ref | [testing-patterns](references/testing-patterns.md) | Given-When-Then, Mock 가이드 |
+| HIGH | ref | [e2e-stability](references/e2e-stability.md) | E2E Viewport, Wait, Retry 가이드 |
+
+## Quick Rules
+
+### Test Naming
+- 형식: `should {expected behavior} when {condition}`
+- Bad: `test getUser`, `works correctly`
+
+### Test Categories
+- **Happy Path** — 정상 흐름
+- **Edge Cases** — 경계 조건 (빈 문자열, 0, null, 최대값)
+- **Error Cases** — 오류 상황
+
+### Coverage Standards
+| Metric | Min | Recommended |
+|--------|-----|-------------|
+| Line | 80% | 90% |
+| Branch | 70% | 80% |
+| Function | 80% | 90% |

package/templates/base/skills/tsq-testing/references/e2e-stability.md

@@ -0,0 +1,33 @@
+---
+title: E2E Stability Guide
+category: reference
+---
+
+# E2E Stability Guide
+
+## Viewport & Selectors
+- 테스트 전 `page.setViewportSize({ width: 1280, height: 720 })` 고정
+- `data-testid` 셀렉터 사용 — CSS 클래스/태그 기반 셀렉터 금지
+- `getByRole`, `getByText` 등 의미 기반 셀렉터 우선
+
+## Serial Execution
+- E2E 테스트는 `describe.serial` 또는 `--shard` 사용
+- 상태 의존 테스트는 반드시 순서 보장 (`test.describe.configure({ mode: 'serial' })`)
+
+## Wait Strategy
+- `waitForSelector` 대신 `waitForLoadState('networkidle')` + assertion
+- 하드코딩 `sleep`/`setTimeout` 절대 사용 금지
+- 동적 콘텐츠: `expect(locator).toBeVisible({ timeout: 10000 })`
+
+## Retry & Flakiness
+- Playwright `retries: 2` 설정 (CI 환경)
+- flaky 테스트 발견 시 `test.fixme()` 마킹 후 원인 분석
+- 재시도 성공도 flaky로 기록 → `.e2e-passed` 마커에 `flaky` 카운트 포함
+
+## Timeout Standards
+
+| Category | Timeout | Rationale |
+|----------|---------|-----------|
+| Unit Test | 120s | 빠른 피드백 |
+| E2E Test | 300s | 네트워크/렌더링 대기 |
+| Build | 180s | 컴파일 + 번들링 |

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

@@ -1,8 +1,10 @@
 ---
-name: typescript
-description: TypeScript 개발 가이드라인
+name: tsq-typescript
+description: |
+  TypeScript 개발 가이드라인. strict 모드, 타입 패턴, Zod 검증, Branded Types.
+  Use when: .ts/.tsx 파일 작성·수정, tsconfig 설정, 타입 안전성 이슈, any 제거, 외부 입력 검증 시.
 version: "1.0.0"
-tags: [typescript, types, strict]
+tags: [tsq, typescript, types, strict]
 user-invocable: false
 ---
 
@@ -54,14 +56,6 @@ user-invocable: false
 - `@ts-ignore`, `@ts-expect-error` 남용
 - `!` non-null assertion 남용
 
-## Checklist
-- [ ] strict 모드 활성화
-- [ ] any 타입 없음
-- [ ] 함수 반환 타입 명시
-- [ ] 외부 입력 Zod 검증
-- [ ] Discriminated Union으로 상태 표현
-- [ ] Branded Types로 ID 구분
-
 ## 참조
 - `rules/type-patterns.md` — 각 패턴의 코드 예시
 - `rules/utility-types.md` — DTO 조합, DeepPartial, 타입 안전 API 클라이언트