@kodevibe/harness 0.8.4 → 0.9.0

package/harness/agents/{planner.md → pm.md}

@@ -9,14 +9,14 @@ The Planner is the entry point for new features — use it BEFORE writing code.
 ## Invoked By
 
 - **User** (direct) — "[기능]을 추가해줘", "계획 세워줘"
-- **bootstrap** → planner (🟢/🟣 pipeline Step 2)
-- **pivot** → planner — "변경된 방향에 맞춰 재계획해줘"
-- **architect** → planner — "승인된 설계로 기능을 계획해줘"
+- **setup** → pm (🟢/🟣 pipeline Step 2)
+- **pivot** → pm — "변경된 방향에 맞춰 재계획해줘"
+- **architect** → pm — "승인된 설계로 기능을 계획해줘"
 
 ## Referenced Skills
 
-- feature-breakdown
-- impact-analysis
+- breakdown
+- check-impact
 
 ## Referenced Files
 
@@ -24,7 +24,7 @@ The Planner is the entry point for new features — use it BEFORE writing code.
 - docs/project-brief.md — 프로젝트 방향, Goals, Non-Goals, Decision Log (Step 1에서 사용)
 - docs/features.md — 기존 기능 등록부 (중복 방지)
 - docs/dependency-map.md — 모듈 구조 (impact 분석)
-- docs/agent-memory/planner.md — 과거 계획 인사이트
+- docs/agent-memory/pm.md — 과거 계획 인사이트
 
 ### Optional — 해당 Step에서만 읽기
 - docs/project-state.md — Sprint 컨텍스트 필요 시에만 읽기
@@ -47,14 +47,14 @@ Before proceeding, verify that required state files have content (not just TODO
 - `docs/features.md` — Must have at least one feature row
 - `docs/dependency-map.md` — Must have at least one module row (for existing projects)
 
-If ALL files are empty/placeholder-only → **Stop and run the `bootstrap` skill first.** Report: "State files are empty. Running bootstrap to onboard this project."
-If `docs/project-brief.md` alone is empty → **Stop.** Without Vision/Goals, planner cannot check Non-Goals or provide direction guard. Run `bootstrap` first.
+If ALL files are empty/placeholder-only → **Stop and run the `setup` skill first.** Report: "State files are empty. Running setup to onboard this project."
+If `docs/project-brief.md` alone is empty → **Stop.** Without Vision/Goals, pm cannot check Non-Goals or provide direction guard. Run `setup` first.
 
 > Step 0 runs BEFORE Step 1. If Step 0 stops (empty brief), Step 1 never executes. When Step 0 passes, Step 1 reads the now-confirmed non-empty project-brief.md for detailed content.
 
 ### Step 0.5: Load Agent Memory
 
-Read `docs/agent-memory/planner.md` for past learnings:
+Read `docs/agent-memory/pm.md` for past learnings:
 - Estimation accuracy from previous sprints (did Wave estimates match reality?)
 - Architecture patterns that worked or failed in this project
 - Repeated planning mistakes to avoid
@@ -104,7 +104,7 @@ Apply these insights when creating the implementation plan. If the memory file i
 <!-- CREW_MODE_END -->
 
 3. **Direction Alignment**: Verify the requested feature against three checkpoints.
-   > This check intentionally duplicates architect’s direction validation (Step 2). The redundancy is by design: architect validates STRUCTURAL proposals (module boundaries, layer rules), while planner validates FEATURE-level alignment (goals, non-goals, decisions). When both are used in the same session, this provides defense-in-depth.
+   > This check intentionally duplicates architect’s direction validation (Step 2). The redundancy is by design: architect validates STRUCTURAL proposals (module boundaries, layer rules), while pm validates FEATURE-level alignment (goals, non-goals, decisions). When both are used in the same session, this provides defense-in-depth.
    - **Goal Alignment**: Does it serve a listed Goal? If no clear link → **warn but proceed**. Include the warning in the plan output under a `### Direction Alignment` section: `⚠️ Goal Alignment: [feature] does not directly map to listed goals`.
    - **Non-Goal Violation**: Does it fall into Non-Goals? If yes → **stop and ask the user**. Do not proceed until the user confirms this is intentional (may need `pivot` skill).
    - **Decision Consistency**: Does it contradict any Decision Log entry? If yes → **stop and warn**. Recommend running the `pivot` skill before proceeding.
@@ -114,9 +114,9 @@ Apply these insights when creating the implementation plan. If the memory file i
 5. Read `docs/project-state.md` for current Sprint context
 6. Identify which existing modules are affected
 7. Identify new modules that need to be created
-8. Run **feature-breakdown** skill to create ordered task list
-9. Register NEW modules from feature-breakdown output in `docs/dependency-map.md` (so impact-analysis reads the updated map)
-10. Run **impact-analysis** skill for each existing module being modified (planner calls both skills independently — feature-breakdown does NOT invoke impact-analysis internally. Ordering: feature-breakdown first → register modules → impact-analysis second.)
+8. Run **breakdown** skill to create ordered task list
+9. Register NEW modules from breakdown output in `docs/dependency-map.md` (so check-impact reads the updated map)
+10. Run **check-impact** skill for each existing module being modified (pm calls both skills independently — breakdown does NOT invoke check-impact internally. Ordering: breakdown first → register modules → check-impact second.)
 11. Check `docs/failure-patterns.md` for relevant past mistakes
 12. Produce implementation plan (see Output Format)
 12. **Wait for Plan Confirmation** (see Plan Confirmation Gate below) — do NOT write state files yet
@@ -143,7 +143,7 @@ Apply these insights when creating the implementation plan. If the memory file i
    - Update Validation Tracker in `docs/project-brief.md` with mapped Stories
    If no Crew Artifact Index → proceed with normal refactoring flow below.
 <!-- CREW_MODE_END -->
-3. Run **impact-analysis** skill on each module being refactored
+3. Run **check-impact** skill on each module being refactored
 4. Identify safe refactoring order (leaf modules first, core modules last)
 5. Produce refactoring plan with rollback checkpoints
 
@@ -154,10 +154,10 @@ After producing ANY plan (New Feature, Refactor, or Crew-Driven), **do NOT proce
 1. Present the complete plan to the user
 2. Ask: **"이 경로(Plan)대로 구현을 시작할까요?"** (or equivalent confirmation request)
 3. Wait for explicit user approval (`Yes`, `Go`, `진행해줘`, etc.)
-4. **Only after approval** → execute **MANDATORY State File Write** (below), then output 🧭 Next Step pointing to `sprint-manager`
+4. **Only after approval** → execute **MANDATORY State File Write** (below), then output 🧭 Next Step pointing to `lead`
 5. If the user requests changes → revise the plan and re-confirm. **No state files are written until approval.**
 
-> **Why**: The planner is planning a route, not driving. The user must confirm the route before the engine starts. This prevents irreversible code changes based on a misunderstood plan.
+> **Why**: The pm is planning a route, not driving. The user must confirm the route before the engine starts. This prevents irreversible code changes based on a misunderstood plan.
 
 ### ⚠️ MANDATORY: Post-Approval State File Write
 
@@ -211,7 +211,7 @@ If any write fails, report the failure and retry. Do NOT proceed to 🧭 with in
 - Unchanged dependents that need testing: [list]
 
 ### Implementation Plan
-[Output from feature-breakdown skill]
+[Output from breakdown skill]
 
 ### Risk Notes
 - [Any failure patterns that apply]
@@ -240,7 +240,7 @@ Use this format when Crew Artifact Index exists in project-brief.md. If no Artif
 - Modified modules: [list]
 
 ### Implementation Plan
-[Output from feature-breakdown skill]
+[Output from breakdown skill]
 
 ### Validation Tracker Updates
 - KPI Coverage: [which KPIs this story addresses]
@@ -264,20 +264,20 @@ After producing a plan, always append a 🧭 block:
 
 | Planner Result | 🧭 Next Step |
 |---|---|
-| Plan created (solo) | User confirmation — "이 경로(Plan)대로 구현을 시작할까요?" → approved → `sprint-manager` |
+| Plan created (solo) | User confirmation — "이 경로(Plan)대로 구현을 시작할까요?" → approved → `lead` |
 <!-- CREW_MODE_START -->
-| Plan created (crew artifacts used) | User confirmation — "crew 기반 Plan을 확인해 주세요. 진행할까요?" → approved → `sprint-manager` |
+| Plan created (crew artifacts used) | User confirmation — "crew 기반 Plan을 확인해 주세요. 진행할까요?" → approved → `lead` |
 <!-- CREW_MODE_END -->
 | Non-Goal violation → stopped | User decision needed — "이 기능은 Non-Goal에 해당합니다. 계속하시겠습니까? → `pivot` 또는 취소" |
 | Direction change detected | `pivot` — "방향을 전환하고 state 파일을 업데이트해줘" |
-| State files empty | `bootstrap` — "프로젝트를 온보딩해줘" |
+| State files empty | `setup` — "프로젝트를 온보딩해줘" |
 
 Example 🧭 block for normal completion:
 ```
 ---
 🧭 Next Step
 → Confirm: "이 경로(Plan)대로 구현을 시작할까요?"
-→ After approval → Next: `sprint-manager` (슬래시 메뉴에서 선택하거나, 채팅에 아래 프롬프트 입력)
+→ After approval → Next: `lead` (슬래시 메뉴에서 선택하거나, 채팅에 아래 프롬프트 입력)
 → Prompt: "S{N}-{M} Story를 시작해줘"
 → Why: Plan is ready — user must confirm route before engine starts
 → Pipeline: 🟢 Step 3/6
@@ -287,7 +287,7 @@ Example 🧭 block for normal completion:
 ## Enforced Rules
 
 - **Direction Guard**: Before planning, read `docs/project-brief.md` and check:
-  - If Vision/Goals are empty → stop and run `bootstrap`
+  - If Vision/Goals are empty → stop and run `setup`
   - If it conflicts with **Non-Goals** → stop and ask the user
   - If it contradicts a **Decision Log** entry → warn and recommend `pivot` skill
   - If it represents a direction change → recommend `pivot` skill
@@ -315,6 +315,6 @@ Before reading or updating shared state files, run `git pull` on the default bra
 - Set Owner on new rows you create in docs/features.md and docs/dependency-map.md
 
 ### Agent Memory
-- Your personal docs/agent-memory/planner.md contains your individual estimation accuracy
+- Your personal docs/agent-memory/pm.md contains your individual estimation accuracy
 - Team velocity estimates should be coordinated through sprint planning meetings, not derived from personal metrics alone
 <!-- TEAM_MODE_END -->

package/harness/agents/reviewer.md

@@ -9,13 +9,13 @@ Finds issues and auto-fixes where safe, escalates where not.
 
 - **User** (direct) — "코드를 리뷰해줘", "커밋 전 검토해줘"
 - **[Coding done]** → reviewer (🟢/🔵/🔴 pipeline — after implementation)
-- **investigate** → reviewer — "수정한 코드를 리뷰해줘"
+- **debug** → reviewer — "수정한 코드를 리뷰해줘"
 
 ## Referenced Skills
 
-- test-integrity — Mock synchronization verification
-- security-checklist — Security risk inspection
-- impact-analysis — Change blast radius assessment
+- sync-tests — Mock synchronization verification
+- secure — Security risk inspection
+- check-impact — Change blast radius assessment
 
 ## Referenced Files
 
@@ -37,7 +37,7 @@ Before reviewing, verify that required state files exist and are not empty:
 - `docs/failure-patterns.md` — Must exist (needed for Step 5 cross-check)
 - `docs/project-state.md` — Must have current Sprint info (needed for scope check)
 
-If state files are empty/placeholder-only → Warn: "State files are not filled. Review will proceed but scope check and failure pattern cross-check will be limited. Consider running `bootstrap` skill."
+If state files are empty/placeholder-only → Warn: "State files are not filled. Review will proceed but scope check and failure pattern cross-check will be limited. Consider running `setup` skill."
 If `docs/failure-patterns.md` is empty, FP-cross-check (Step 5) will be skipped. This increases risk of recurring bugs.
 
 ### Step 0.5: Load Agent Memory
@@ -65,12 +65,12 @@ Changed file list (user-provided or from `git diff --name-only`)
 - [ ] Constructor parameters match actual source (FP-002)
 - [ ] **Common First (Iron Law #9)**: No crew-specific logic outside crew marker blocks. All features must work without crew artifacts.
 
-**Step 3: Test Integrity (test-integrity skill)**
+**Step 3: Test Integrity (sync-tests skill)**
 - [ ] Interface changes have synchronized mocks (FP-001)
 - [ ] New features have tests
 - [ ] Existing tests pass
 
-**Step 4: Security Check (security-checklist skill)**
+**Step 4: Security Check (secure skill)**
 - [ ] No credentials, .env, or temp files in staging (FP-004)
 - [ ] No hardcoded API keys or passwords
 - [ ] No injection vulnerabilities (SQL, XSS)
@@ -121,7 +121,7 @@ If no Crew Artifact Index → skip this step entirely.
 - [ ] If new modules were added, verify they are registered in docs/dependency-map.md (Iron Law #6)
 - [ ] If module interfaces changed, verify "Depends On" / "Depended By" columns are updated
 - [ ] If module was deleted/renamed, verify docs/dependency-map.md is cleaned up
-- [ ] Run impact-analysis skill if interface changes affect 2+ dependent modules
+- [ ] Run check-impact skill if interface changes affect 2+ dependent modules
 
 **Step 8: State File Audit**
 
@@ -136,13 +136,13 @@ Verify that state file updates actually happened. Check each:
 - [ ] **docs/dependency-map.md**: If new modules were created, are they registered? If dependencies changed, are relationships updated?
 - [ ] **docs/failure-patterns.md**: If a bug was fixed that matched a pattern, was frequency incremented?
 - [ ] **docs/project-brief.md**: If a technology or architectural decision was made, is it in Decision Log?
-- [ ] **docs/agent-memory/*.md**: If an agent (reviewer/planner/sprint-manager) was used this session, was its memory updated by the learn skill?
+- [ ] **docs/agent-memory/*.md**: If an agent (reviewer/pm/lead) was used this session, was its memory updated by the wrap-up skill?
 
 For each missing update: flag as `[STATE-AUDIT]` in the output and provide the exact update that should be made.
 **Severity**:
 - Missing dependency-map or features.md entries for new modules/features are **blockers** — fix before commit.
-- `[STATE-AUDIT: FR-COVERAGE]` flags (features.md status ↔ Story 완료 불일치) are **blockers** — features.md 상태 갱신 후 commit. 30초면 해결되며 learn까지 미루면 FR 추적이 실제와 불일치합니다.
-- Missing project-state Quick Summary or agent-memory updates are **warnings** — can be deferred to learn skill.
+- `[STATE-AUDIT: FR-COVERAGE]` flags (features.md status ↔ Story 완료 불일치) are **blockers** — features.md 상태 갱신 후 commit. 30초면 해결되며 wrap-up까지 미루면 FR 추적이 실제와 불일치합니다.
+- Missing project-state Quick Summary or agent-memory updates are **warnings** — can be deferred to wrap-up skill.
 
 **Step 9: Commit Guidance**
 
@@ -158,7 +158,7 @@ When review result is DONE or DONE_WITH_CONCERNS (no blockers):
    git commit -m "S{N}-{M}: {description}"
    ```
 4. **Push recommendation**:
-   - Solo mode: Push at least once per session end (learn skill will remind)
+   - Solo mode: Push at least once per session end (wrap-up skill will remind)
    - Team mode: Push after each Story completion to share progress
    - If remote is configured: `git push origin {branch}`
 
@@ -230,9 +230,9 @@ After review completes, always append a 🧭 block based on the outcome:
 
 | Review Result | 🧭 Next Step |
 |---|---|
-| All checks pass, more stories remain | Commit → `sprint-manager` — "커밋 후 다음 Story는?" |
-| All checks pass, all stories done | Commit → `learn` — "커밋 후 세션을 마무리해줘" |
-| STATE-AUDIT flags found | Two valid paths: (1) `learn` now → "지금 state 파일을 정리해줘" or (2) `sprint-manager` → continue coding, resolve at session end |
+| All checks pass, more stories remain | Commit → `lead` — "커밋 후 다음 Story는?" |
+| All checks pass, all stories done | Commit → `wrap-up` — "커밋 후 세션을 마무리해줘" |
+| STATE-AUDIT flags found | Two valid paths: (1) `wrap-up` now → "지금 state 파일을 정리해줘" or (2) `lead` → continue coding, resolve at session end |
 | Security/architecture issues blocking | [Fix] — "리뷰 지적사항을 수정하세요. 완료 후 **새 프롬프트**에서 다시 `@reviewer` 호출" |
 
 Example 🧭 block for passing review:
@@ -241,11 +241,11 @@ Example 🧭 block for passing review:
 🧭 Next Step
 → Action: 아래 커밋 명령을 실행하세요
 → Command: git add <files> && git commit -m "S{N}-{M}: {description}"
-→ Next: `sprint-manager` (**새 채팅**에서 아래 입력)
+→ Next: `lead` (**새 채팅**에서 아래 입력)
 → Prompt: "다음 Story는?"
 → Why: Review passed — commit changes, then move to the next Story
 → Pipeline: 🔵 Step 5/6
-→ Alternative: 세션 종료 시 `learn` 호출 (push 포함)
+→ Alternative: 세션 종료 시 `wrap-up` 호출 (push 포함)
 ---
 ```
 
@@ -253,8 +253,8 @@ Example 🧭 block for passing review:
 
 When Step 8 (State File Audit) produces `[STATE-AUDIT]` flags:
 1. List all flagged items in the review output
-2. The `learn` skill (run at session end) will verify and resolve these flags
-3. If a flag is critical (missing module in dependency-map, unregistered feature), recommend fixing immediately rather than deferring to learn
+2. The `wrap-up` skill (run at session end) will verify and resolve these flags
+3. If a flag is critical (missing module in dependency-map, unregistered feature), recommend fixing immediately rather than deferring to wrap-up
 
 <!-- TEAM_MODE_START -->
 ## Team Mode: Review

package/harness/core-rules.md

@@ -6,7 +6,7 @@ Skills and agents work together through shared state files.
 
 ## Session Start
 
-Read `docs/project-state.md` first. If all state files are empty, run `bootstrap` skill.
+Read `docs/project-state.md` first. If all state files are empty, run `setup` skill.
 If `.harness/my-context.md` exists, read it for personal environment and preferences.
 > This file is user-created, not generated by any skill or agent. Create it manually to store personal environment notes (IDE settings, local paths, preferences). See `.harness/` in docs/ for the expected location.
 
@@ -15,45 +15,45 @@ If `.harness/my-context.md` exists, read it for personal environment and prefere
 Follow the pipeline that matches the current situation. After each step, output a 🧭 Next Step.
 
 ### 🟢 New Development (no design docs — start from scratch)
-1. `bootstrap` → scan project & fill state files
-2. `planner` → plan first feature based on user requirements
-3. `sprint-manager` → start Story ("S{N}-{M} Story를 시작해줘")
-4. [Coding] → implement Stories in order from planner
+1. `setup` → scan project & fill state files
+2. `pm` → plan first feature based on user requirements
+3. `lead` → start Story ("S{N}-{M} Story를 시작해줘")
+4. [Coding] → implement Stories in order from pm
 5. `reviewer` → code review → commit (`git commit -m "S{N}-{M}: ..."`) → push
-6. `learn` → capture session lessons + verify push before ending
+6. `wrap-up` → capture session lessons + verify push before ending
 
-### 🔵 Continue Development (bootstrap already done)
-1. `sprint-manager` → check current status ("where are we?")
-2. `planner` → plan new feature (if needed)
-3. `sprint-manager` → start Story
+### 🔵 Continue Development (setup already done)
+1. `lead` → check current status ("where are we?")
+2. `pm` → plan new feature (if needed)
+3. `lead` → start Story
 4. [Coding] → implement Stories in order
 5. `reviewer` → code review → commit (`git commit -m "S{N}-{M}: ..."`) → push
-6. `learn` → capture session lessons + verify push before ending
+6. `wrap-up` → capture session lessons + verify push before ending
 
 ### 🔴 Bug Fix
-1. `investigate` → diagnose the issue
-2. [Fix] → apply fix within investigate's recommended scope
+1. `debug` → diagnose the issue
+2. [Fix] → apply fix within debug's recommended scope
 3. `reviewer` → review the fix → commit → push
-4. `learn` → record lessons + verify push
+4. `wrap-up` → record lessons + verify push
 
 ### 🟡 Direction Change
 1. `pivot` → update all state files for new direction
-2. `planner` → re-plan features for new direction
+2. `pm` → re-plan features for new direction
 
 <!-- CREW_MODE_START -->
 ### 🟣 Crew-Driven Development (kode:crew artifacts provided)
 
 When external planning artifacts exist (requirements, analysis, design documents from kode:crew or similar):
 
-1. `bootstrap` → scan project & fill state files, **create Artifact Index + Validation Tracker** in project-brief.md (originals are never modified)
-2. `planner` → plan features **from crew artifacts**: map FR→Stories (`[FR-NNN]` prefix), ARB Fail→P0 Stories (`[ARB-FAIL]` prefix), update Validation Tracker
-3. `sprint-manager` → start Story (includes Validation Dashboard showing KPI/FR/ARB coverage)
-4. [Coding] → implement Stories in order from planner
+1. `setup` → scan project & fill state files, **create Artifact Index + Validation Tracker** in project-brief.md (originals are never modified)
+2. `pm` → plan features **from crew artifacts**: map FR→Stories (`[FR-NNN]` prefix), ARB Fail→P0 Stories (`[ARB-FAIL]` prefix), update Validation Tracker
+3. `lead` → start Story (includes Validation Dashboard showing KPI/FR/ARB coverage)
+4. [Coding] → implement Stories in order from pm
 5. `reviewer` → code review + crew artifact compliance check → commit → push
-6. `learn` → capture session lessons + update Validation Tracker + verify push
+6. `wrap-up` → capture session lessons + update Validation Tracker + verify push
 
 > Crew artifacts are detected by: `docs/crew/` directory, `docs/PM/`+`docs/Analyst/`+`docs/ARB/` directories, or user explicitly provides requirements/design documents (e.g., mentions "PRD", "산출물", "설계서", or provides file paths to planning artifacts).
-> **Reference, don't summarize**: bootstrap creates a Crew Artifact Index (path table) in project-brief.md — each skill reads the original artifact directly via the indexed path.
+> **Reference, don't summarize**: setup creates a Crew Artifact Index (path table) in project-brief.md — each skill reads the original artifact directly via the indexed path.
 > This pipeline produces the same state files as 🟢 — the difference is the INPUT source and the addition of Validation Tracker for traceability.
 <!-- CREW_MODE_END -->
 
@@ -63,15 +63,15 @@ When the user provides a feature request or development goal in their prompt:
 
 1. Read `docs/project-state.md` to determine current project state
 2. Route to the appropriate pipeline:
-   - State files empty → Start 🟢 Pipeline from Step 1 (`bootstrap`)
-   - State files exist + new feature request → Start 🟢 or 🔵 Pipeline from `planner`
-   - Bug report or error → Start 🔴 Pipeline from `investigate`
-   - Structural/design change → Run `architect` first, then `planner`
+   - State files empty → Start 🟢 Pipeline from Step 1 (`setup`)
+   - State files exist + new feature request → Start 🟢 or 🔵 Pipeline from `pm`
+   - Bug report or error → Start 🔴 Pipeline from `debug`
+   - Structural/design change → Run `architect` first, then `pm`
    - Direction change → Start 🟡 Pipeline from `pivot`
 <!-- CREW_MODE_START -->
-   - Crew artifacts detected (`docs/crew/` exists, `docs/PM/`+`docs/Analyst/`+`docs/ARB/` exist, or user provided design docs) → Start 🟣 Pipeline from `bootstrap`
+   - Crew artifacts detected (`docs/crew/` exists, `docs/PM/`+`docs/Analyst/`+`docs/ARB/` exist, or user provided design docs) → Start 🟣 Pipeline from `setup`
 <!-- CREW_MODE_END -->
-   - Any other request (info, explanation, status) → `sprint-manager` — route with context
+   - Any other request (info, explanation, status) → `lead` — route with context
 3. Announce which pipeline and step you are starting, then execute
 
 ## 🧭 Next Step — Response Rule
@@ -94,18 +94,18 @@ When a skill or agent reports STATUS: DONE, output the next step in this format:
 
 | Completed | Next | Prompt Example |
 |-----------|------|---------------|
-| `bootstrap` | `planner` | "[project]에 [첫 기능]을 추가해줘" || `planner` (Step 0 → empty) | `bootstrap` [internal] | "State files empty — auto-invoking bootstrap" || `planner` | User confirmation → `sprint-manager` | "이 경로(Plan)대로 구현을 시작할까요?" → "S{N}-{M} Story를 시작해줘" |
-| `sprint-manager` (story started) | [Coding] | "S{N}-{M} 구현을 시작해줘" → 완료 후 **새 채팅**에서 `@reviewer` 호출 |
+| `setup` | `pm` | "[project]에 [첫 기능]을 추가해줘" || `pm` (Step 0 → empty) | `setup` [internal] | "State files empty — auto-invoking setup" || `pm` | User confirmation → `lead` | "이 경로(Plan)대로 구현을 시작할까요?" → "S{N}-{M} Story를 시작해줘" |
+| `lead` (story started) | [Coding] | "S{N}-{M} 구현을 시작해줘" → 완료 후 **새 채팅**에서 `@reviewer` 호출 |
 | [Coding done] | `reviewer` | "S{N}-{M} 코드를 리뷰해줘" |
-| `reviewer` (pass, more stories) | Commit → `sprint-manager` | \"커밋 후 다음 Story는?\" |
-| `reviewer` (pass, all done) | Commit → `learn` | \"커밋 후 세션 마무리해줘\" |
-| `reviewer` (STATE-AUDIT) | `learn` | "state 파일을 정리하고 세션 마무리해줘" |
-| `investigate` | `reviewer` | "수정한 코드를 리뷰해줘" |
-| `pivot` | `planner` | "변경된 방향에 맞춰 재계획해줘" |
-| `architect` | `planner` | "승인된 설계로 기능을 계획해줘" |
-| `learn` | 🏁 Session End | "다음 세션 시작 시 `sprint-manager` 호출" |
+| `reviewer` (pass, more stories) | Commit → `lead` | \"커밋 후 다음 Story는?\" |
+| `reviewer` (pass, all done) | Commit → `wrap-up` | \"커밋 후 세션 마무리해줘\" |
+| `reviewer` (STATE-AUDIT) | `wrap-up` | "state 파일을 정리하고 세션 마무리해줘" |
+| `debug` | `reviewer` | "수정한 코드를 리뷰해줘" |
+| `pivot` | `pm` | "변경된 방향에 맞춰 재계획해줘" |
+| `architect` | `pm` | "승인된 설계로 기능을 계획해줘" |
+| `wrap-up` | 🏁 Session End | "다음 세션 시작 시 `lead` 호출" |
 <!-- CREW_MODE_START -->
-| Crew artifacts provided | `bootstrap` (🟣) | "crew 산출물을 기반으로 프로젝트를 세팅해줘" |
+| Crew artifacts provided | `setup` (🟣) | "crew 산출물을 기반으로 프로젝트를 세팅해줘" |
 <!-- CREW_MODE_END -->
 
 ## State Files
@@ -125,10 +125,10 @@ These laws are enforced across all skills and agents. Violations should be flagg
 3. **Scope Compliance**: Do not modify files outside the current Story scope without reporting first.
 4. **Security**: Never include credentials, passwords, or API keys in code or commits.
 5. **3-Failure Stop + Recalculating**: If the same approach fails 3 times, stop the current approach. Then:
-   - Automatically invoke `investigate` skill in **Recalculating Mode** (one attempt)
-   - **Inject failure context**: Pass to investigate a summary of the 3 failed attempts: (a) what approach was tried, (b) the error message for each attempt. This prevents investigate from repeating the same failed approaches.
+   - Automatically invoke `debug` skill in **Recalculating Mode** (one attempt)
+   - **Inject failure context**: Pass to debug a summary of the 3 failed attempts: (a) what approach was tried, (b) the error message for each attempt. This prevents debug from repeating the same failed approaches.
    - Present the user with: (a) the blocker diagnosis, (b) 1-2 alternative approaches that differ from all 3 failed attempts
-   - If investigate itself fails or the alternatives are rejected → **full stop**, escalate to the user
+   - If debug itself fails or the alternatives are rejected → **full stop**, escalate to the user
    - Never retry the original failed approach after the 3-Failure Stop triggers
 6. **Dependency Map**: When adding or modifying a module, update dependency-map.md in the same commit.
 7. **Feature Registry**: When adding a feature, register it in features.md in the same commit.

package/harness/dependency-map.md

@@ -40,11 +40,11 @@ When modifying a module:
 ## Interface Change Log
 
 <!-- Record interface changes as they happen. This is MANDATORY for all interface changes (Iron Law #1).
-   **Who fills this**: The `impact-analysis` skill adds rows during planning/review. The `reviewer` agent verifies rows exist (Step 7).
+   **Who fills this**: The `check-impact` skill adds rows during planning/review. The `reviewer` agent verifies rows exist (Step 7).
    After modifying any public interface (method signature, return type, parameters):
    1. Add a row here immediately
    2. Check "Affected Modules" by reading the Depended By column in Module Registry
-   3. Update mocks for all affected modules (run test-integrity skill)
+   3. Update mocks for all affected modules (run sync-tests skill)
    4. Set Status to "In Progress" until all dependents are updated, then "Updated"
 
    | Date | Module | Change | Affected Modules | Status |

package/harness/failure-patterns.md

@@ -18,7 +18,7 @@ Keep resolved patterns for regression prevention.
 - **Frequency**: 0
 - **Cause**: LLM treated interface change and mock update as separate tasks. Added method to interface but forgot to update the mock, causing test failures.
 - **Prevention**: Update mock in the same commit as the interface change.
-- **Applied in**: testing rules, test-integrity skill, reviewer agent
+- **Applied in**: testing rules, sync-tests skill, reviewer agent
 - **Status**: Template — activate when first occurrence is logged
 
 <!-- Activation example: When this pattern first occurs, update like this:
@@ -48,7 +48,7 @@ On subsequent occurrences, increment Frequency and append to Occurred (e.g., S1-
 - **Cause**: LLM lost track of current scope in large workflows. Skipped "report and wait for approval" steps.
 - **Concrete scenario**: Working on S1-002 (user auth), LLM noticed a bug in S1-001 (scaffolding) and fixed it without asking — breaking the unchanged module's tests.
 - **Prevention**: Track current Story in docs/project-state.md. Sprint manager agent detects scope violations. If root cause is in another module, STOP and ask user.
-- **Applied in**: sprint-manager agent, global instructions
+- **Applied in**: lead agent, global instructions
 - **Status**: Template — activate when first occurrence is logged
 
 ---
@@ -58,6 +58,6 @@ On subsequent occurrences, increment Frequency and append to Occurred (e.g., S1-
 - **Occurred**: <!-- Sprint/Story where this happened -->
 - **Frequency**: 0
 - **Cause**: LLM created temp files during work, then ran `git add .` which staged credentials or debug artifacts.
-- **Prevention**: Ban `git add .`. Run security-checklist skill before commits. Reviewer agent inspects staging area.
-- **Applied in**: security-checklist skill, reviewer agent, backend rules
+- **Prevention**: Ban `git add .`. Run secure skill before commits. Reviewer agent inspects staging area.
+- **Applied in**: secure skill, reviewer agent, backend rules
 - **Status**: Template — activate when first occurrence is logged

package/harness/features.md

@@ -35,10 +35,10 @@ When you add or modify a feature:
 **Iron Law #7**: When adding a new feature, register it here in the same commit.
 
 **Write Precedence** (multiple skills update this file):
-1. **planner** — registers new features (⬜ planned) when creating implementation plans
-2. **sprint-manager** — updates Status to 🔧 active when a Story begins
+1. **pm** — registers new features (⬜ planned) when creating implementation plans
+2. **lead** — updates Status to 🔧 active when a Story begins
 3. **reviewer** — updates Status to ✅ done when Story passes review, or ⚠️ broken if tests fail
-4. **learn** — finalizes Status at session end (conflict resolution: learn takes precedence)
+4. **wrap-up** — finalizes Status at session end (conflict resolution: wrap-up takes precedence)
 
 ## Orphan Detection
 

package/harness/project-brief.md

@@ -45,15 +45,15 @@
 <!-- CREW_MODE_START -->
 ## Crew Artifact Index
 
-<!-- 🟣 Pipeline only — auto-generated by bootstrap when crew artifacts are detected.
+<!-- 🟣 Pipeline only — auto-generated by setup when crew artifacts are detected.
    Maps original artifact documents so skills/agents can read them directly.
    DO NOT summarize artifacts here — just index their locations.
 
-   **Detection**: bootstrap Phase 1.5 scans for artifact files in:
+   **Detection**: setup Phase 1.5 scans for artifact files in:
    - docs/crew/
    - docs/PM/
    - User-provided custom paths
-   If ANY files are found, bootstrap populates this table and activates the 🟣 pipeline.
+   If ANY files are found, setup populates this table and activates the 🟣 pipeline.
    If NO crew artifacts are found, this section stays empty (🟢/🔵/🔴 pipelines).
 
    | Artifact | Path | Role | Contains |
@@ -63,7 +63,7 @@
    | Architecture | docs/crew/architecture.md | ARB | 인프라, 앱스택, 보안 |
    | ARB Checklist | docs/crew/arb-checklist.md | ARB | 감사 결과 (Pass/Fail) |
 
-   How bootstrap populates this:
+   How setup populates this:
    1. Detects artifact files in docs/crew/, docs/PM/, or user-provided paths
    2. Creates one row per artifact with exact path
    3. "Contains" column lists key sections (KPIs, FRs, NFRs, etc.)
@@ -72,9 +72,9 @@
 
 ## Validation Tracker
 
-<!-- 🟣 Pipeline only — auto-generated by bootstrap, updated by learn/sprint-manager.
+<!-- 🟣 Pipeline only — auto-generated by setup, updated by wrap-up/lead.
    Tracks KPI coverage, FR coverage, and ARB Fail item resolution.
-   Initial state: All rows start with ⬜ (Not started). Story column empty until planner maps them.
+   Initial state: All rows start with ⬜ (Not started). Story column empty until pm maps them.
 
    **Status emojis for Validation Tracker** (simplified set — NOT the same as Story/Feature status):
    - ⬜ Not started
@@ -83,10 +83,10 @@
    Note: Story status uses ⬜/🔧/✅/🚫/❌ (see project-state.md). Feature status uses ⬜/🔧/✅/⚠️/❌ (see features.md). Validation Tracker uses a reduced set because it only tracks coverage, not development workflow.
 
    **Write Precedence**: Multiple skills update the Validation Tracker:
-   1. `bootstrap` — creates initial structure (all ⬜)
-   2. `planner` — fills Story column (maps FR/KPI to Stories)
-   3. `learn` — updates Status (⬜→🟡 or 🟡→✅) based on session outcomes
-   If planner and learn both modify Status in the same session, learn’s update takes precedence (it captures the final session state).
+   1. `setup` — creates initial structure (all ⬜)
+   2. `pm` — fills Story column (maps FR/KPI to Stories)
+   3. `wrap-up` — updates Status (⬜→🟡 or 🟡→✅) based on session outcomes
+   If pm and wrap-up both modify Status in the same session, wrap-up.s update takes precedence (it captures the final session state).
 
    ### KPI Coverage
    | ID | KPI | Source | Story | Status |
@@ -104,7 +104,7 @@
    (Example: | FR-001 | 사용자 로그인 | P0 | S1-001, S1-003 | ✅ |)
 
    Status legend: ⬜ Not started, 🟡 In progress, ✅ Done
-   Update flow: bootstrap creates → planner fills Story column → learn updates Status
+   Update flow: setup creates → pm fills Story column → wrap-up updates Status
 -->
 <!-- CREW_MODE_END -->
 

package/harness/project-state.md

@@ -20,11 +20,11 @@
    ➡️ Next: Continue (no specific action)
 
    **Write Precedence**: Multiple skills update this file. Priority order:
-   1. `learn` (session end) — highest priority, overwrites Quick Summary
-   2. `sprint-manager` (story status changes) — updates Story Status table
-   3. `planner` (new stories) — adds rows to Story Status table
-   4. `investigate` (bug fixes) — adds to Recent Changes only
-   If conflicts: learn’s Quick Summary always wins (it captures final session state).
+   1. `wrap-up` (session end) — highest priority, overwrites Quick Summary
+   2. `lead` (story status changes) — updates Story Status table
+   3. `pm` (new stories) — adds rows to Story Status table
+   4. `debug` (bug fixes) — adds to Recent Changes only
+   If conflicts: wrap-up’s Quick Summary always wins (it captures final session state).
 -->
 
 ## Current Sprint

package/harness/skills/{feature-breakdown.md → breakdown.md}

@@ -7,10 +7,10 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 
 ## Invoked By
 
-- **planner** agent — Step 8: Create ordered task list for new features
+- **pm** agent — Step 8: Create ordered task list for new features
 - **architect** agent — when structural validation requires task decomposition review
 
-> **Note**: feature-breakdown is responsible for task decomposition only. It does NOT invoke `impact-analysis`. The planner calls both skills independently: feature-breakdown (Step 8) for task ordering, then impact-analysis (Step 9) for blast radius analysis.
+> **Note**: breakdown is responsible for task decomposition only. It does NOT invoke `check-impact`. The pm calls both skills independently: breakdown (Step 8) for task ordering, then check-impact (Step 9) for blast radius analysis.
 
 ## When to Apply
 
@@ -22,7 +22,7 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 ## Procedure
 
 1. **Describe the feature** in one sentence
-2. **Read docs/project-brief.md** — verify the feature aligns with Goals and does not violate Non-Goals. If project-brief.md is empty (bootstrap hasn't run), skip this check but warn the user. If it conflicts with Non-Goals, **stop and warn the user** before proceeding. (Direction Guard — prevents breakdown of out-of-scope features even when invoked directly without planner)
+2. **Read docs/project-brief.md** — verify the feature aligns with Goals and does not violate Non-Goals. If project-brief.md is empty (setup hasn't run), skip this check but warn the user. If it conflicts with Non-Goals, **stop and warn the user** before proceeding. (Direction Guard — prevents breakdown of out-of-scope features even when invoked directly without pm)
 3. **Read docs/dependency-map.md** to understand current module relationships
 4. **Identify affected modules**: List every module that needs changes
 5. **Classify changes per module**:
@@ -77,7 +77,7 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 - Never implement a module before its dependencies exist
 - Each task should be completable in one session
 - Every task must include its test files
-- New modules MUST be registered in docs/dependency-map.md (Iron Law #6) — the breakdown OUTPUT section lists these registrations, and planner (or the user, if invoked directly) is responsible for executing the actual state file writes
+- New modules MUST be registered in docs/dependency-map.md (Iron Law #6) — the breakdown OUTPUT section lists these registrations, and pm (or the user, if invoked directly) is responsible for executing the actual state file writes
 - If a task exceeds Story scope, stop and report to user
 
 ## State File Updates (mandatory — Step 9)
@@ -90,16 +90,16 @@ After completing the breakdown, update these files in the same session:
 
 ### 🧭 Navigation — After Feature Breakdown
 
-Feature-breakdown is invoked BY planner (Step 8), so the 🧭 returns control to planner's flow.
+Feature-breakdown is invoked BY pm (Step 8), so the 🧭 returns control to pm's flow.
 If invoked directly by the user, append:
 
 ```
 ---
 🧭 Next Step
-→ Next: `planner`
+→ Next: `pm`
 → Prompt: "breakdown을 기반으로 Sprint Story를 생성해줘"
-→ Why: Tasks are defined — planner will register Stories and update state files
-→ Pipeline: 🟢 Step 2/6 (returns to planner)
+→ Why: Tasks are defined — pm will register Stories and update state files
+→ Pipeline: 🟢 Step 2/6 (returns to pm)
 ---
 ```