@kodevibe/harness 0.8.3 → 0.9.0

package/README.ko.md

@@ -13,7 +13,7 @@
 
 kode:harness는 **harness engineering** 원칙을 기반으로 합니다. 멀티 개발자와 엔터프라이즈급 환경, 그리고 solo 개발 흐름까지 고려한 AI 개발 엔지니어링 방식을 제품 형태로 제공하는 구조입니다.
 
-> **v0.8.3** — 6개 IDE 지원, Navigation Dispatcher, 5개 파이프라인 (🟢🔵🔴🟡🟣), Crew Artifact Integration, 100점 품질 감사.
+> **v0.9.0** — 네이밍 재설계 (스킬/에이전트 이름 직관화), 6개 IDE 지원, Navigation Dispatcher, 5개 파이프라인 (🟢🔵🔴🟡🟣), Crew Artifact Integration.
 
 ---
 
@@ -77,9 +77,9 @@ npx @kodevibe/harness init --team
 
 프롬프트에서 IDE를 선택하면 현재 디렉토리에 파일이 설치됩니다.
 
-설치 후, LLM에게 `bootstrap` 스킬을 실행하도록 요청하세요:
+설치 후, LLM에게 `setup` 스킬을 실행하도록 요청하세요:
 
-> "bootstrap을 실행해서 이 프로젝트를 온보딩해줘."
+> "setup을 실행해서 이 프로젝트를 온보딩해줘."
 
 코드베이스를 스캔하고 5개 State 파일을 자동으로 채웁니다.
 
@@ -143,24 +143,24 @@ npx @kodevibe/harness validate
 
 | 스킬 | 설명 |
 |------|------|
-| **bootstrap** | 프로젝트를 kode:harness에 온보딩: 코드베이스 스캔 + state 파일 자동 작성 |
-| **learn** | 세션 종료 시 마무리: 실패 패턴 캡처, 프로젝트 상태 업데이트, 방향 드리프트 감지 |
+| **setup** | 프로젝트를 kode:harness에 온보딩: 코드베이스 스캔 + state 파일 자동 작성 |
+| **wrap-up** | 세션 종료 시 마무리: 실패 패턴 캡처, 프로젝트 상태 업데이트, 방향 드리프트 감지 |
 | **pivot** | 목표·기술·범위 변경 시 모든 state 파일에 변경사항 전파 |
-| **test-integrity** | 커밋 전 mock/인터페이스 동기화 검증 |
-| **security-checklist** | 커밋 전 보안 위험 스캔 |
-| **investigate** | 4단계 체계적 디버깅 (증거 → 범위축소 → 수정 → 검증) |
-| **impact-analysis** | 공유 모듈 수정 전 영향 범위 평가 |
-| **feature-breakdown** | 기능을 의존성 순서대로 구현 태스크로 분해 |
-| **code-review-pr** | PR 코드 리뷰: 품질, 보안, 방향 정렬 확인 |
-| **deployment** | 배포 전 검증 체크리스트 (테스트, state 파일, 보안, 버전) |
+| **sync-tests** | 커밋 전 mock/인터페이스 동기화 검증 |
+| **secure** | 커밋 전 보안 위험 스캔 |
+| **debug** | 4단계 체계적 디버깅 (증거 → 범위축소 → 수정 → 검증) |
+| **check-impact** | 공유 모듈 수정 전 영향 범위 평가 |
+| **breakdown** | 기능을 의존성 순서대로 구현 태스크로 분해 |
+| **pr-review** | PR 코드 리뷰: 품질, 보안, 방향 정렬 확인 |
+| **release** | 배포 전 검증 체크리스트 (테스트, state 파일, 보안, 버전) |
 
 ### 에이전트 (역할 기반 페르소나)
 
 | 에이전트 | 역할 |
 |---------|------|
-| **planner** | 기능 기획, 의존성 분석, Direction Alignment (목표/비목표/결정사항 체크) |
+| **pm** | 기능 기획, 의존성 분석, Direction Alignment (목표/비목표/결정사항 체크) |
 | **reviewer** | 코드 리뷰 + State 파일 감사 (state 파일이 실제로 업데이트되었는지 검증) |
-| **sprint-manager** | 스프린트/스토리 상태 관리, 범위 이탈 방지, 다음 단계 추천 |
+| **lead** | 스프린트/스토리 상태 관리, 범위 이탈 방지, 다음 단계 추천 |
 | **architect** | 설계 리뷰 게이트: 구조 변경이 프로젝트 방향 및 모듈 경계에 부합하는지 검증 |
 
 ### State 파일 (프로젝트 메모리)
@@ -179,7 +179,7 @@ npx @kodevibe/harness validate
 
 ### 1단계: Bootstrap (최초 1회)
 
-`harness init` 후 `bootstrap` 스킬을 실행합니다. 코드베이스를 스캔하고, 목표/비목표에 대해 질문한 후, 5개 state 파일을 자동으로 채웁니다. **가장 중요한 단계입니다** — 이것 없이는 Direction Guard 등 다른 스킬이 컨텍스트를 가지지 못합니다.
+`harness init` 후 `setup` 스킬을 실행합니다. 코드베이스를 스캔하고, 목표/비목표에 대해 질문한 후, 5개 state 파일을 자동으로 채웁니다. **가장 중요한 단계입니다** — 이것 없이는 Direction Guard 등 다른 스킬이 컨텍스트를 가지지 못합니다.
 
 ### 2단계: Direction Guard (매 요청마다)
 
@@ -192,26 +192,26 @@ npx @kodevibe/harness validate
 ### 3단계: Workflow Pipeline
 
 ```
-bootstrap → planner → [코딩] → reviewer → sprint-manager → learn
+setup → pm → [코딩] → reviewer → lead → wrap-up
 ```
 
 kode:harness는 상황별 **5개 파이프라인**을 제공합니다:
 
 | 파이프라인 | 상황 | 흐름 |
 |---|---|---|
-| 🟢 New Dev | 첫 기능 개발 | bootstrap → planner → sprint-manager → [코딩] → reviewer → learn |
-| 🔵 Continue | 작업 재개 | sprint-manager → [코딩] → reviewer → learn |
-| 🔴 Bug Fix | 디버깅 | investigate → [수정] → reviewer → learn |
-| 🟡 Direction Change | 목표/기술 변경 | pivot → planner → sprint-manager → [코딩] → reviewer → learn |
-| 🟣 Crew-Driven | 외부 기획 산출물 | bootstrap(crew) → planner → sprint-manager → [코딩] → reviewer → learn |
+| 🟢 New Dev | 첫 기능 개발 | setup → pm → lead → [코딩] → reviewer → wrap-up |
+| 🔵 Continue | 작업 재개 | lead → [코딩] → reviewer → wrap-up |
+| 🔴 Bug Fix | 디버깅 | debug → [수정] → reviewer → wrap-up |
+| 🟡 Direction Change | 목표/기술 변경 | pivot → pm → lead → [코딩] → reviewer → wrap-up |
+| 🟣 Crew-Driven | 외부 기획 산출물 | setup(crew) → pm → lead → [코딩] → reviewer → wrap-up |
 
 각 단계 완료 시 🧭 **Navigation 블록**이 다음에 무엇을 해야 하는지 — 입력할 프롬프트까지 안내합니다.
 
-- **planner**: 방향 정렬 확인, 기능 분해. **Confirm-First 게이트** — 사용자 승인 없이 진행하지 않음.
+- **pm**: 방향 정렬 확인, 기능 분해. **Confirm-First 게이트** — 사용자 승인 없이 진행하지 않음.
 - **reviewer**: 코드 리뷰 + state 파일 업데이트 감사
-- **sprint-manager**: **Wave-Level Pacing** — 구현 Wave 사이에 자동 테스트 실행
-- **learn**: 세션 종료 전 교훈 캡처
-- **investigate**: **Recalculating Mode** — 3회 실패 후 대안 접근법 제시
+- **lead**: **Wave-Level Pacing** — 구현 Wave 사이에 자동 테스트 실행
+- **wrap-up**: 세션 종료 전 교훈 캡처
+- **debug**: **Recalculating Mode** — 3회 실패 후 대안 접근법 제시
 
 ### 4단계: 방향 전환 (Direction Changes)
 
@@ -256,14 +256,14 @@ npx @kodevibe/harness init --team
 
 | # | 규칙 | 적용 대상 |
 |---|------|----------|
-| 1 | **Mock 동기화** — 인터페이스 변경 → 같은 커밋에서 mock 업데이트 | `reviewer`, `test-integrity` |
+| 1 | **Mock 동기화** — 인터페이스 변경 → 같은 커밋에서 mock 업데이트 | `reviewer`, `sync-tests` |
 | 2 | **타입 확인** — 생성자 호출 전 소스 파일을 직접 읽기. 기억에 의존하지 않기 | `reviewer` |
-| 3 | **범위 준수** — 현재 스토리 범위 내에서만 작업. 범위 외 파일 수정 시 먼저 보고 | `sprint-manager`, `reviewer` |
-| 4 | **보안** — 코드나 커밋에 자격증명, 비밀번호, API 키 포함 금지 | `security-checklist`, `reviewer` |
+| 3 | **범위 준수** — 현재 스토리 범위 내에서만 작업. 범위 외 파일 수정 시 먼저 보고 | `lead`, `reviewer` |
+| 4 | **보안** — 코드나 커밋에 자격증명, 비밀번호, API 키 포함 금지 | `secure`, `reviewer` |
 | 5 | **3회 실패 정지** — 같은 접근이 3번 실패하면 → 중단 후 보고 | 모든 에이전트 |
-| 6 | **의존성 맵** — 모듈 추가/수정 → 같은 커밋에서 `dependency-map.md` 업데이트 | `reviewer`, `learn` |
-| 7 | **기능 레지스트리** — 새 기능 → 같은 커밋에서 `features.md`에 등록 | `reviewer`, `learn` |
-| 8 | **세션 핸드오프** — 세션 종료 → `project-state.md` Quick Summary 업데이트 | `learn` |
+| 6 | **의존성 맵** — 모듈 추가/수정 → 같은 커밋에서 `dependency-map.md` 업데이트 | `reviewer`, `wrap-up` |
+| 7 | **기능 레지스트리** — 새 기능 → 같은 커밋에서 `features.md`에 등록 | `reviewer`, `wrap-up` |
+| 8 | **세션 핸드오프** — 세션 종료 → `project-state.md` Quick Summary 업데이트 | `wrap-up` |
 
 ---
 
@@ -302,21 +302,22 @@ Bootstrap이 `docs/crew/`, `docs/PM/`, `docs/Analyst/`, `docs/ARB/`에서 crew
 | IDE 지원 | 20+ (installer) | 5 (setup --host) | 13 (runtime select) | 6 (네이티브 포맷) |
 | 방향 관리 | ❌ | ❌ | ❌ | ✅ (Direction Guard + pivot + Decision Log) |
 | Iron Laws (코드 품질 규칙) | ❌ | ❌ | ❌ | ✅ (8개 규칙이 스킬에 임베딩) |
-| Cold start | ❌ | ❌ | `/gsd-new-project` | ✅ (`bootstrap` 스킬) |
+| Cold start | ❌ | ❌ | `/gsd-new-project` | ✅ (`setup` 스킬) |
 | 태스크당 컨텍스트 | 4-6 파일 | 1 파일 | 매번 200k 플랜 | **2-3 파일 (136줄 디스패처)** |
 
 ---
 
 ## 로드맵
 
-kode:harness는 현재 **v0.8.3** — 6개 IDE 지원 완료, Navigation Dispatcher와 Crew Artifact Integration 안정화.
+kode:harness는 현재 **v0.9.0** — 네이밍 재설계 완료, 6개 IDE 지원, Navigation Dispatcher와 Crew Artifact Integration 안정화.
 
 | 단계 | 버전 | 상태 | 초점 |
 |------|------|------|------|
 | **Foundation** | v0.5.0 | ✅ 완료 | 핵심 프레임워크: 6 IDE 지원, 8 스킬, 3 에이전트, Team Mode, Direction Guard |
 | **Hardening** | v0.6.5 | ✅ 완료 | 10 스킬, 4 에이전트, Iron Laws, CLI batch/doctor/validate, 방향 드리프트 감지 |
 | **Flexibility** | v0.7.x | ✅ 완료 | 팀 컨벤션을 project-brief.md에 위임, prescriptive 규칙 제거 |
-| **Navigation** | v0.8.x | ✅ 현재 | 🧭 Navigation Dispatcher, 5개 파이프라인, Crew Artifact Integration, 100점 품질 감사, Confirm-First 게이트, Wave-Level Pacing, Recalculating Mode |
+| **Navigation** | v0.8.x | ✅ 완료 | 🧭 Navigation Dispatcher, 5개 파이프라인, Crew Artifact Integration, 100점 품질 감사, Confirm-First 게이트, Wave-Level Pacing, Recalculating Mode |
+| **Naming** | v0.9.0 | ✅ 현재 | 스킬/에이전트 네이밍 재설계 — 직관성과 발견성 강화 |
 | **Validation** | v1.0 | 🔜 다음 | 실사용 검증, 사용자 피드백 수집 |
 
 ### 다음 단계

package/README.md

@@ -13,7 +13,7 @@
 
 kode:harness is built on **harness engineering** for multi-developer, enterprise-grade AI-assisted development.
 
-> **v0.8.3** — 6 IDE support, Navigation Dispatcher, 5 Pipelines (🟢🔵🔴🟡🟣), Crew Artifact Integration, 100-point quality audit.
+> **v0.9.0** — Naming redesign (clearer skill/agent names), 6 IDE support, Navigation Dispatcher, 5 Pipelines (🟢🔵🔴🟡🟣), Crew Artifact Integration.
 
 ## From Harness to Enterprise Harness Engineering
 
@@ -45,7 +45,7 @@ kode:harness manages your **project's direction** — goals, decisions, scope
 - **Crew Artifact Integration** — Reads external planning output (PRD, Architecture, ARB Checklist) directly — no manual copy needed
 - **State Files** — 5 markdown files that persist project knowledge across LLM sessions
 - **Skills** — Step-by-step procedures for planning, review, debugging, and direction changes
-- **Agents** — Role-based personas that enforce the workflow (planner, reviewer, sprint-manager)
+- **Agents** — Role-based personas that enforce the workflow (pm, reviewer, lead)
 - **Failure Patterns** — Project-specific failure log that prevents repeat mistakes
 - **Decision Log** — Records why decisions were made so LLMs don't re-debate settled choices
 
@@ -61,9 +61,9 @@ npx @kodevibe/harness init --team
 
 Select your IDE when prompted. Files are installed into the current directory.
 
-After installation, ask your LLM to run the `bootstrap` skill:
+After installation, ask your LLM to run the `setup` skill:
 
-> "Run bootstrap to onboard this project."
+> "Run setup to onboard this project."
 
 This scans your codebase and fills all 5 state files automatically.
 
@@ -111,7 +111,7 @@ Large projects with crew artifacts may require increased turn limits:
 | Windsurf | Auto-managed | Default OK |
 | Claude Code | Terminal-based | Default OK |
 
-> This is only needed when running `bootstrap` with crew artifacts on projects that have many existing frameworks. Normal coding/review operations work within default limits.
+> This is only needed when running `setup` with crew artifacts on projects that have many existing frameworks. Normal coding/review operations work within default limits.
 
 ## Supported IDEs
 
@@ -132,21 +132,21 @@ All IDEs also get state files (`project-state.md`, `project-brief.md`, `features
 - **Core Rules** — 136-line dispatcher: session start guidance, workflow references, state file list, and Iron Laws. Detailed rules are embedded in each skill/agent that enforces them.
 
 ### Skills (on-demand procedures)
-- **bootstrap** — Onboard project into kode:harness: scans codebase + fills state files automatically
-- **learn** — End-of-session wrap-up: captures failure patterns, updates project state, detects direction drift
+- **setup** — Onboard project into kode:harness: scans codebase + fills state files automatically
+- **wrap-up** — End-of-session wrap-up: captures failure patterns, updates project state, detects direction drift
 - **pivot** — Propagate direction changes across all state files when goals/tech/scope changes
-- **test-integrity** — Verify mock/interface synchronization before committing
-- **security-checklist** — Pre-commit security risk scan
-- **investigate** — 4-phase systematic debugging (evidence → scope → fix → verify)
-- **impact-analysis** — Assess change blast radius before modifying shared modules
-- **feature-breakdown** — Decompose features into dependency-ordered implementation tasks
-- **code-review-pr** — Review incoming Pull Requests for quality, security, and direction alignment
-- **deployment** — Pre-deployment validation checklist (tests, state files, security, versioning)
+- **sync-tests** — Verify mock/interface synchronization before committing
+- **secure** — Pre-commit security risk scan
+- **debug** — 4-phase systematic debugging (evidence → scope → fix → verify)
+- **check-impact** — Assess change blast radius before modifying shared modules
+- **breakdown** — Decompose features into dependency-ordered implementation tasks
+- **pr-review** — Review incoming Pull Requests for quality, security, and direction alignment
+- **release** — Pre-release validation checklist (tests, state files, security, versioning)
 
 ### Agents (role-based personas)
-- **planner** — Feature planning, dependency analysis, Direction Alignment (goal/non-goal/decision check)
+- **pm** — Feature planning, dependency analysis, Direction Alignment (goal/non-goal/decision check)
 - **reviewer** — Code review + State File Audit (verifies state files were actually updated)
-- **sprint-manager** — Sprint/Story state management, scope drift prevention, Next Step Recommendation
+- **lead** — Sprint/Story state management, scope drift prevention, Next Step Recommendation
 - **architect** — Design review gate: validates structural changes against project direction and module boundaries
 
 ### State Files (project memory)
@@ -159,7 +159,7 @@ All IDEs also get state files (`project-state.md`, `project-brief.md`, `features
 ## How It Works
 
 ### 1. Bootstrap (once)
-After `harness init`, run the `bootstrap` skill. It scans your codebase, interviews you about goals/non-goals, and fills all 5 state files automatically. **This is the most important step** — without it, Direction Guard and other skills have no context.
+After `harness init`, run the `setup` skill. It scans your codebase, interviews you about goals/non-goals, and fills all 5 state files automatically. **This is the most important step** — without it, Direction Guard and other skills have no context.
 
 ### 2. Direction Guard (every request)
 Before ANY coding task, the LLM reads `project-brief.md` and checks:
@@ -169,26 +169,26 @@ Before ANY coding task, the LLM reads `project-brief.md` and checks:
 
 ### 3. Workflow Pipeline
 ```
-bootstrap → planner → [code] → reviewer → sprint-manager → learn
+setup → pm → [code] → reviewer → lead → wrap-up
 ```
 
 kode:harness provides **5 pipelines** for different scenarios:
 
 | Pipeline | When | Flow |
 |---|---|---|
-| 🟢 New Dev | First feature | bootstrap → planner → sprint-manager → [code] → reviewer → learn |
-| 🔵 Continue | Resuming work | sprint-manager → [code] → reviewer → learn |
-| 🔴 Bug Fix | Debugging | investigate → [fix] → reviewer → learn |
-| 🟡 Direction Change | Goals/tech shift | pivot → planner → sprint-manager → [code] → reviewer → learn |
-| 🟣 Crew-Driven | With external planning artifacts | bootstrap(crew) → planner → sprint-manager → [code] → reviewer → learn |
+| 🟢 New Dev | First feature | setup → pm → lead → [code] → reviewer → wrap-up |
+| 🔵 Continue | Resuming work | lead → [code] → reviewer → wrap-up |
+| 🔴 Bug Fix | Debugging | debug → [fix] → reviewer → wrap-up |
+| 🟡 Direction Change | Goals/tech shift | pivot → pm → lead → [code] → reviewer → wrap-up |
+| 🟣 Crew-Driven | With external planning artifacts | setup(crew) → pm → lead → [code] → reviewer → wrap-up |
 
 Each step ends with a 🧭 **Navigation block** telling you exactly what to do next — including the prompt to type.
 
-- **planner**: Checks direction alignment, breaks down features. **Confirm-First gate** — won't proceed without your approval.
+- **pm**: Checks direction alignment, breaks down features. **Confirm-First gate** — won't proceed without your approval.
 - **reviewer**: Reviews code + audits state file updates
-- **sprint-manager**: Tracks progress via **Wave-Level Pacing** — runs tests between implementation waves
-- **learn**: Captures lessons before session ends
-- **investigate**: **Recalculating Mode** — after 3 failed attempts, proposes alternative approaches
+- **lead**: Tracks progress via **Wave-Level Pacing** — runs tests between implementation waves
+- **wrap-up**: Captures lessons before session ends
+- **debug**: **Recalculating Mode** — after 3 failed attempts, proposes alternative approaches
 
 ### 4. Direction Changes
 When goals, technology, or scope changes, run the `pivot` skill:
@@ -227,14 +227,14 @@ These 8 rules are enforced across all skills and agents. They form the quality b
 
 | # | Law | Enforced By |
 |---|-----|-------------|
-| 1 | **Mock Sync** — Interface change → update mocks in the same commit | `reviewer`, `test-integrity` |
+| 1 | **Mock Sync** — Interface change → update mocks in the same commit | `reviewer`, `sync-tests` |
 | 2 | **Type Check** — Read the source before calling constructors. Never trust memory. | `reviewer` |
-| 3 | **Scope Compliance** — Stay within current Story scope. Report before modifying out-of-scope files. | `sprint-manager`, `reviewer` |
-| 4 | **Security** — No credentials, passwords, or API keys in code or commits. | `security-checklist`, `reviewer` |
+| 3 | **Scope Compliance** — Stay within current Story scope. Report before modifying out-of-scope files. | `lead`, `reviewer` |
+| 4 | **Security** — No credentials, passwords, or API keys in code or commits. | `secure`, `reviewer` |
 | 5 | **3-Failure Stop** — Same approach fails 3 times → stop and report. | All agents |
-| 6 | **Dependency Map** — New/modified module → update `dependency-map.md` in the same commit. | `reviewer`, `learn` |
-| 7 | **Feature Registry** — New feature → register in `features.md` in the same commit. | `reviewer`, `learn` |
-| 8 | **Session Handoff** — Session end → update `project-state.md` Quick Summary. | `learn` |
+| 6 | **Dependency Map** — New/modified module → update `dependency-map.md` in the same commit. | `reviewer`, `wrap-up` |
+| 7 | **Feature Registry** — New feature → register in `features.md` in the same commit. | `reviewer`, `wrap-up` |
+| 8 | **Session Handoff** — Session end → update `project-state.md` Quick Summary. | `wrap-up` |
 
 ## Documentation
 
@@ -272,19 +272,20 @@ Original crew documents are **never modified**. Only the index and tracker are c
 | IDE support | 20+ (installer) | 5 (setup --host) | 13 (runtime select) | 6 (native format) |
 | Direction management | ❌ | ❌ | ❌ | ✅ (Direction Guard + pivot + Decision Log) |
 | Iron Laws (code quality rules) | ❌ | ❌ | ❌ | ✅ (8 laws embedded in skills) |
-| Cold start | ❌ | ❌ | `/gsd-new-project` | ✅ (`bootstrap` skill) |
+| Cold start | ❌ | ❌ | `/gsd-new-project` | ✅ (`setup` skill) |
 | Context per task | 4-6 files | 1 file | Fresh 200k per plan | 2-3 files (136-line dispatcher) |
 
 ## Roadmap
 
-kode:harness is at **v0.8.3** — 6 IDE support complete, Navigation Dispatcher and Crew Artifact Integration stable.
+kode:harness is at **v0.9.0** — naming redesign complete, 6 IDE support, Navigation Dispatcher and Crew Artifact Integration stable.
 
 | Phase | Version | Status | Focus |
 |---|---|---|---|
 | **Foundation** | v0.5.0 | ✅ Done | Core framework: 6 IDE support, 8 skills, 3 agents, Team Mode, Direction Guard |
 | **Hardening** | v0.6.5 | ✅ Done | 10 skills, 4 agents, Iron Laws, CLI batch/doctor/validate, merge conflict SOP, direction drift detection |
 | **Flexibility** | v0.7.x | ✅ Done | Delegate team conventions to project-brief.md, remove prescriptive rules |
-| **Navigation** | v0.8.x | ✅ Current | 🧭 Navigation Dispatcher, 5 Pipelines, Crew Artifact Integration, 100-point quality audit, Confirm-First gate, Wave-Level Pacing, Recalculating Mode |
+| **Navigation** | v0.8.x | ✅ Done | 🧭 Navigation Dispatcher, 5 Pipelines, Crew Artifact Integration, 100-point quality audit, Confirm-First gate, Wave-Level Pacing, Recalculating Mode |
+| **Naming** | v0.9.0 | ✅ Current | Skill/agent naming redesign for clarity and discoverability |
 | **Validation** | v1.0 | 🔜 Next | Real-world project adoption, user feedback collection |
 
 ### What's Next

package/harness/agent-memory/architect.md

@@ -1,6 +1,6 @@
 # Architect Memory
 
-> Auto-updated by the `learn` skill at session end. Do not edit manually.
+> Auto-updated by the `wrap-up` skill at session end. Do not edit manually.
 > **Initialization**: After the first architecture review, replace placeholder comments below with real data.
 > **Update trigger**: Only updated when the `architect` agent runs. If architect was not invoked this session, this file stays unchanged.
 
@@ -27,7 +27,7 @@
 <!-- Record anti-patterns with severity, detection method, and prevention.
    Format: Pattern — Severity (HIGH/MED/LOW) — Detection — Resolution — Prevention
    Examples:
-   - Circular dep auth↔user — HIGH — dependency-map bidirectional check — extracted shared types — run impact-analysis before interface changes
+   - Circular dep auth↔user — HIGH — dependency-map bidirectional check — extracted shared types — run check-impact before interface changes
    - God module in utils/ (800+ lines) — MED — file size check — decompose into auth-utils, date-utils, string-utils — enforce max 200 lines per module
 -->
 

package/harness/agent-memory/{sprint-manager.md → lead.md}

@@ -1,8 +1,8 @@
 # Sprint Manager Memory
 
-> Auto-updated by the `learn` skill at session end. Do not edit manually.
+> Auto-updated by the `wrap-up` skill at session end. Do not edit manually.
 > **Initialization**: After the first sprint completes, replace placeholder comments below with real data.
-> **Update trigger**: Updated when `learn` skill runs after sprint management actions.
+> **Update trigger**: Updated when `wrap-up` skill runs after sprint management actions.
 
 ## Velocity Tracking
 
@@ -12,13 +12,13 @@
    - [Sprint 1] 3/5 (60%) — ramp-up phase, scope adjusted mid-sprint
    - [Sprint 2] 4/4 (100%) — right-sized after Sprint 1 calibration
    - [Sprint 3] 5/5 (100%) — team rhythm established
-   Benchmark: Set after 3+ sprints. If rate < 50% for 2 consecutive sprints → flag in sprint-manager recommendations.
+   Benchmark: Set after 3+ sprints. If rate < 50% for 2 consecutive sprints → flag in lead recommendations.
    Average velocity: recalculate after each sprint (e.g., "Average: 4.0 stories/sprint after 3 sprints")
 -->
 
 ## Scope Drift History
 
-<!-- Record scope violations caught by sprint-manager or reviewer.
+<!-- Record scope violations caught by lead or reviewer.
    Format: [Story ID] Drift type — Files affected — Resolution
    Examples:
    - [S1-003] Out-of-scope modification — 3 files in auth/ (not in story scope) — reverted, created new story S1-005

package/harness/agent-memory/{planner.md → pm.md}

@@ -1,8 +1,8 @@
 # Planner Memory
 
-> Auto-updated by the `learn` skill at session end. Do not edit manually.
+> Auto-updated by the `wrap-up` skill at session end. Do not edit manually.
 > **Initialization**: After the first sprint completes, replace placeholder comments below with real data.
-> **Update trigger**: Updated when `learn` skill runs after a planner session.
+> **Update trigger**: Updated when `wrap-up` skill runs after a pm session.
 
 ## Estimation Accuracy
 
@@ -43,5 +43,5 @@
    - [Sprint 1] Planned: 5, Done: 3, Rate: 60% — ramp-up phase, team unfamiliar with codebase
    - [Sprint 2] Planned: 4, Done: 4, Rate: 100% — right-sized after Sprint 1 data
    - [Sprint 3] Planned: 4, Done: 5, Rate: 125% — acceleration, consider planning 5 next sprint
-   Benchmark: After 3+ sprints, calculate average rate. If < 60% for 2 consecutive sprints → investigate causes
+   Benchmark: After 3+ sprints, calculate average rate. If < 60% for 2 consecutive sprints → debug causes
 -->

package/harness/agent-memory/reviewer.md

@@ -1,8 +1,8 @@
 # Reviewer Memory
 
-> Auto-updated by the `learn` skill at session end. Do not edit manually.
+> Auto-updated by the `wrap-up` skill at session end. Do not edit manually.
 > **Initialization**: After the first code review, replace placeholder comments below with real data.
-> **Update trigger**: Updated when `learn` skill runs after a reviewer session.
+> **Update trigger**: Updated when `wrap-up` skill runs after a reviewer session.
 
 ## Project-Specific Review Patterns
 
@@ -10,7 +10,7 @@
    Format: Pattern — Location — Severity — Prevention
    Examples:
    - SQL injection risk in src/api/routes/ — req.params used directly — HIGH — add parameterized query wrapper
-   - Mock sync miss rate 50% — interface changes in src/domain/ — HIGH — run test-integrity skill pre-commit
+   - Mock sync miss rate 50% — interface changes in src/domain/ — HIGH — run sync-tests skill pre-commit
    - Hardcoded timeout 5000ms in tests — tests/integration/ — LOW — extract to test config
 -->
 
@@ -32,7 +32,7 @@
 - Escalations: 0
 <!-- Track ratios after 5+ reviews:
    - Auto-fix rate: auto-fixes / total issues (if > 30% → consider automating those checks)
-   - Escalation rate: escalations / total reviews (if > 20% → investigate root cause)
+   - Escalation rate: escalations / total reviews (if > 20% → debug root cause)
 -->
 
 ## Test Failure Patterns
@@ -40,7 +40,7 @@
 <!-- Track which test patterns commonly fail during reviews.
    Format: Pattern — Frequency — Root Cause — Mitigation
    Examples:
-   - Mock method missing after interface change — 4/10 reviews — FP-001 — run test-integrity pre-commit
+   - Mock method missing after interface change — 4/10 reviews — FP-001 — run sync-tests pre-commit
    - Async test timeout — 2/10 reviews — missing await — enforce eslint no-floating-promises
    - Snapshot mismatch after UI change — 3/10 reviews — stale snapshots — update snapshots in same commit
 -->

package/harness/agents/architect.md

@@ -9,12 +9,12 @@ The Architect is invoked when changes affect multiple modules, introduce new lay
 ## Invoked By
 
 - **User** (direct) — "아키텍처 리뷰해줘", "설계 검토해줘"
-- **planner** (optional) — when proposed changes affect 3+ modules or introduce new layers
+- **pm** (optional) — when proposed changes affect 3+ modules or introduce new layers
 
 ## Referenced Skills
 
-- impact-analysis — Change blast radius assessment
-- feature-breakdown — Task decomposition for structural changes
+- check-impact — Change blast radius assessment
+- breakdown — Task decomposition for structural changes
 
 ## Referenced Files
 
@@ -45,7 +45,7 @@ Before proceeding, verify that required state files have content:
 - `docs/dependency-map.md` — Must have at least one module row (for existing projects)
 - `docs/project-brief.md` — Must have Vision and Goals filled
 
-If `docs/project-brief.md` has no Vision/Goals filled OR `docs/dependency-map.md` has zero module rows → **Stop and run the `bootstrap` skill first.** Report: "State files are empty. Running bootstrap to onboard this project."
+If `docs/project-brief.md` has no Vision/Goals filled OR `docs/dependency-map.md` has zero module rows → **Stop and run the `setup` skill first.** Report: "State files are empty. Running setup to onboard this project."
 
 **Step 0.1: Circular Dependency Check**
 
@@ -85,7 +85,7 @@ Apply these insights when evaluating the current proposal. If the memory file is
 4. If misaligned → **warn and recommend `pivot` before proceeding**
 
 **Step 3: Impact Analysis**
-1. Run `impact-analysis` skill on all affected modules
+1. Run `check-impact` skill on all affected modules
 2. Identify:
    - Modules that will be modified
    - Modules that depend on modified modules (ripple effect)
@@ -140,7 +140,7 @@ After architecture review completes, always append a 🧭 block:
 
 | Architect Result | 🧭 Next Step |
 |---|---|
-| APPROVE | `planner` — "승인된 설계로 기능을 계획해줘" |
+| APPROVE | `pm` — "승인된 설계로 기능을 계획해줘" |
 | REVISE | [Redesign] — "설계를 수정하고 다시 `architect` 호출" |
 | REJECT | User decision — "설계가 반려되었습니다. 대안을 논의합시다" |
 | Direction misaligned | `pivot` — "방향을 전환하고 state 파일을 업데이트해줘" |
@@ -149,10 +149,10 @@ Example 🧭 block for APPROVE:
 ```
 ---
 🧭 Next Step
-→ Next: `planner`
+→ Next: `pm`
 → Prompt: "승인된 설계로 기능을 계획해줘"
 → Why: Architecture approved — proceed to feature planning
-→ Pipeline: 🟢 Pre-pipeline (leads to planner Step 2/6)
+→ Pipeline: 🟢 Pre-pipeline (leads to pm Step 2/6)
 ---
 ```
 
@@ -161,7 +161,7 @@ Example 🧭 block for APPROVE:
 - This agent reviews design, it does NOT implement changes
 - Always defer to `docs/project-brief.md` Decision Log for settled architectural decisions
 - If unsure about direction, recommend involving the designated authority (per project-brief.md; default: team lead)
-- For implementation after approval, hand off to the `planner` agent
+- For implementation after approval, hand off to the `pm` agent
 
 <!-- TEAM_MODE_START -->
 ## Team Mode: Cross-Team Architecture

package/harness/agents/{sprint-manager.md → lead.md}

@@ -8,22 +8,22 @@ Keeps the LLM focused on the current work item.
 ## Invoked By
 
 - **User** (direct) — "다음 Story는?", "현재 상태 보여줘"
-- **planner** → User confirmation → sprint-manager (🟢 pipeline Step 3)
-- **reviewer** (pass, more stories) → sprint-manager — "다음 Story는?"
+- **pm** → User confirmation → lead (🟢 pipeline Step 3)
+- **reviewer** (pass, more stories) → lead — "다음 Story는?"
 
 ## Referenced Skills
 
-- bootstrap — Recommended when state files are empty
-- learn — Recommended at session end or when all stories are done
+- setup — Recommended when state files are empty
+- wrap-up — Recommended at session end or when all stories are done
 - pivot — Recommended when direction change is detected
-- investigate — Recommended when bug is blocking progress
+- debug — Recommended when bug is blocking progress
 
 ## Referenced Files
 
 ### Required — 반드시 읽기
 - docs/project-state.md — 핵심 파일: 현재 Sprint/Story 상태 (Step 0, 모든 Handler에서 사용)
 - docs/features.md — 진행률 개요 (Next Step Recommendation에서 사용)
-- docs/agent-memory/sprint-manager.md — 과거 velocity 및 scope drift 데이터
+- docs/agent-memory/lead.md — 과거 velocity 및 scope drift 데이터
 
 ### Optional — 해당 Step에서만 읽기
 - docs/project-brief.md — 방향 확인 필요 시에만 읽기
@@ -38,11 +38,11 @@ Before handling any request, verify `docs/project-state.md` has content:
 - Quick Summary must not be all TODO placeholders
 - Story Status table must have at least one row
 
-If `docs/project-state.md` is empty/placeholder-only → **Recommend running `bootstrap` skill first.** Report: "docs/project-state.md is empty. Run bootstrap to initialize project state before tracking sprints."
+If `docs/project-state.md` is empty/placeholder-only → **Recommend running `setup` skill first.** Report: "docs/project-state.md is empty. Run setup to initialize project state before tracking sprints."
 
 ### Step 0.5: Load Agent Memory
 
-Read `docs/agent-memory/sprint-manager.md` for past learnings:
+Read `docs/agent-memory/lead.md` for past learnings:
 - Team velocity data (stories per sprint)
 - Scope drift history (how often did scope expand?)
 - Story sizing accuracy (were estimates correct?)
@@ -71,15 +71,15 @@ After every status check, recommend the next action based on current context:
 
 | Situation | Recommendation |
 |-----------|---------------|
-| State files are empty | → "Run `bootstrap` to onboard this project" |
+| State files are empty | → "Run `setup` to onboard this project" |
 |docs/project-brief.md has no Vision/Goals | → "Fill out docs/project-brief.md — this is critical for direction" |
-| No stories exist | → "Run `planner` to break down your first feature" |
+| No stories exist | → "Run `pm` to break down your first feature" |
 | A story is in-progress | → "Continue S{N}-{M}: [title]. Scope: [files]" |
-| All stories in sprint are done | → "Run `learn` to capture session lessons, then start a new sprint" |
+| All stories in sprint are done | → "Run `wrap-up` to capture session lessons, then start a new sprint" |
 | A direction change was discussed | → "Run `pivot` to update all state files before continuing" |
 | Recent failure patterns apply | → "Watch out for FP-{NNN}: [description]" |
 <!-- CREW_MODE_START -->
-| Unplanned KPI/FR in Validation Tracker | → "Run `planner` — add Stories for unplanned KPI/FR items" |
+| Unplanned KPI/FR in Validation Tracker | → "Run `pm` — add Stories for unplanned KPI/FR items" |
 | All ARB Fail items resolved | → "ARB Fail items all resolved — deployment readiness can be checked" |
 <!-- CREW_MODE_END -->
 
@@ -109,20 +109,20 @@ After every status check, recommend the next action based on current context:
 3. Read `docs/dependency-map.md` to identify modules involved in this Story
 4. Specify Story scope (related files/directories from dependency-map)
 5. Alert relevant docs/failure-patterns.md items
-6. Recommend relevant skill: "Consider running `planner` if this story needs detailed breakdown"
+6. Recommend relevant skill: "Consider running `pm` if this story needs detailed breakdown"
 
-**Request: "plan approved" / "플랜 반영해줘" (planner → sprint-manager handoff)**
+**Request: "plan approved" / "플랜 반영해줘" (pm → lead handoff)**
 
-When invoked after planner approval, verify that planner wrote state files correctly:
+When invoked after pm approval, verify that pm wrote state files correctly:
 
 1. Read `docs/project-state.md` — check if Stories from the approved plan exist
 2. **If Stories exist** → proceed to "new story" handler (set first `todo` Story to `in-progress`)
-3. **If Stories are missing** (planner failed to write):
+3. **If Stories are missing** (pm failed to write):
    a. Read the approved plan from the conversation context
    b. Create Sprint entry in `docs/project-state.md` (Sprint N, theme from plan)
    c. Add all Story rows to the Story Status table (status = `⬜ todo`)
    d. Update Quick Summary section
-   e. Report: "Planner가 state files에 반영하지 않아 sprint-manager가 보완했습니다."
+   e. Report: "Planner가 state files에 반영하지 않아 lead가 보완했습니다."
    f. Proceed to set the first Story to `in-progress`
 <!-- CREW_MODE_START -->
 4. If 🟣 pipeline: verify `docs/project-brief.md` Validation Tracker has Story mappings. If missing, fill them from the plan.
@@ -134,7 +134,7 @@ When invoked after planner approval, verify that planner wrote state files corre
 
 **Wave-Level Pacing (Turn-by-Turn Guidance)**
 
-When a Story contains multiple Tasks/Waves (from feature-breakdown):
+When a Story contains multiple Tasks/Waves (from breakdown):
 - Guide implementation **one Wave at a time** (not one file at a time, not all at once)
 - After each Wave is implemented, **run tests (or invoke `reviewer` for a quick check)** to verify the Wave is clean before proceeding
 - Only after verification passes, prompt: "Wave {N} 완료 (tests pass). Wave {N+1}로 넘어갈까요?"
@@ -178,7 +178,7 @@ STATUS: DONE
 #### Validation Dashboard (🟣 Pipeline only)
 
 When `docs/project-brief.md` contains a `## Validation Tracker` section with data, display the Validation Tracker as a dashboard in every status output.
-If the Validation Tracker exists but has zero rows (no KPIs/FRs indexed yet), display: `KPI Coverage: 0/0 (N/A) — consider running bootstrap to populate Artifact Index`.
+If the Validation Tracker exists but has zero rows (no KPIs/FRs indexed yet), display: `KPI Coverage: 0/0 (N/A) — consider running setup to populate Artifact Index`.
 
 ```
 ### 📊 Validation Dashboard
@@ -190,19 +190,19 @@ If the Validation Tracker exists but has zero rows (no KPIs/FRs indexed yet), di
 - [KPI/FR ID]: [description] — 관련 Story 없음
 ```
 
-**Sprint Manager reads and reports the Validation Tracker numbers.** It does NOT auto-create Stories for missing coverage — that is the planner's role. If unplanned items exist, recommend running `planner`.
+**Sprint Manager reads and reports the Validation Tracker numbers.** It does NOT auto-create Stories for missing coverage — that is the pm's role. If unplanned items exist, recommend running `pm`.
 <!-- CREW_MODE_END -->
 
 ### 🧭 Navigation — What Comes After Sprint Manager
 
-After sprint-manager completes, always append a 🧭 block based on the outcome:
+After lead completes, always append a 🧭 block based on the outcome:
 
 | Sprint Manager Result | 🧭 Next Step |
 |---|---|
-| State files empty | `bootstrap` — "프로젝트를 온보딩해줘" |
-| No stories exist | `planner` — "[기능]을 계획해줘" |
+| State files empty | `setup` — "프로젝트를 온보딩해줘" |
+| No stories exist | `pm` — "[기능]을 계획해줘" |
 | Story set to in-progress | [Coding] — "S{N}-{M} 구현을 시작해줘". 완료 후 **새 채팅**에서 reviewer 호출 |
-| All stories done | `learn` — "세션을 마무리해줘" |
+| All stories done | `wrap-up` — "세션을 마무리해줘" |
 | Direction change detected | `pivot` — "방향을 전환해줘" |
 
 Example 🧭 block for starting a story: