@kodevibe/harness 0.8.3 → 0.9.0

package/harness/skills/{impact-analysis.md → check-impact.md}

@@ -7,7 +7,7 @@ The most common cause of regressions in growing projects is changing one module
 
 ## Invoked By
 
-- **planner** agent — Step 10: for each existing module being modified
+- **pm** agent — Step 10: for each existing module being modified
 - **reviewer** agent — Step 7: when interface changes affect 2+ dependent modules
 - **architect** agent — when structural validation requires blast radius analysis
 
@@ -72,22 +72,22 @@ Plan: 4 files to update, all within S3-2 scope
 
 After completing the analysis, update these files:
 
-- [ ] **docs/dependency-map.md**: Update the Interface Change Log table with: Date, Module, Change description, Affected Modules, Status ("In Progress" until all dependents updated, then "Updated"). **This is mandatory for ALL interface changes** — do not skip even if the change seems minor. **Status transition**: impact-analysis sets the initial status to "In Progress". After all dependent modules are verified updated (by reviewer Step 7 or test-integrity), update Status to "Updated".
+- [ ] **docs/dependency-map.md**: Update the Interface Change Log table with: Date, Module, Change description, Affected Modules, Status ("In Progress" until all dependents updated, then "Updated"). **This is mandatory for ALL interface changes** — do not skip even if the change seems minor. **Status transition**: check-impact sets the initial status to "In Progress". After all dependent modules are verified updated (by reviewer Step 7 or sync-tests), update Status to "Updated".
 - [ ] **docs/features.md**: If the interface change affects a feature's Key Files, update the Key Files column. If test files change, update the Test Files column.
 - [ ] **docs/project-state.md**: If scope exceeds current Story, add a note to Recent Changes.
 
 ### 🧭 Navigation — After Impact Analysis
 
-Impact-analysis is invoked BY `planner` (Step 9) or `reviewer` (Step 7). After completion, control returns to the caller's flow.
+Impact-analysis is invoked BY `pm` (Step 9) or `reviewer` (Step 7). After completion, control returns to the caller's flow.
 If invoked directly by the user, append:
 
 ```
 ---
 🧭 Next Step
-→ Next: `planner` or `reviewer`
+→ Next: `pm` or `reviewer`
 → Prompt: "영향도 분석 결과를 반영해줘"
 → Why: Blast radius mapped — incorporate into plan or review
-→ Pipeline: N/A (utility skill — invoked by planner Step 9 or reviewer Step 7)
+→ Pipeline: N/A (utility skill — invoked by pm Step 9 or reviewer Step 7)
 ---
 ```
 

package/harness/skills/{investigate.md → debug.md}

@@ -3,13 +3,13 @@
 ## Purpose
 
 Debug bugs systematically. Prevent "symptom patching" — fixing without understanding root cause.
-4-phase debugging process inspired by gstack's /investigate.
+4-phase debugging process inspired by gstack's /debug.
 
 ## Invoked By
 
 - **User** (direct) — "이 버그 조사해줘", "왜 실패하는지 찾아줘"
-- **sprint-manager** — bug blocking progress 시 권장
-- **core-rules** (3-Failure Stop) → investigate Recalculating Mode
+- **lead** — bug blocking progress 시 권장
+- **core-rules** (3-Failure Stop) → debug Recalculating Mode
 
 ## When to Apply
 
@@ -38,7 +38,7 @@ If the user reports "weird behavior" but there is no error message or stack trac
 
 ### Phase 1: Evidence Collection (NO FIXES)
 
-> **failure-patterns.md responsibility**: investigate READS patterns (Phase 1) to see if this is a known bug, and WRITES updates (Phase 4) to record new patterns. The `reviewer` agent only READS patterns (Step 5) as a warning check. The `learn` skill WRITES patterns only for failures NOT already recorded by investigate in the same session.
+> **failure-patterns.md responsibility**: debug READS patterns (Phase 1) to see if this is a known bug, and WRITES updates (Phase 4) to record new patterns. The `reviewer` agent only READS patterns (Step 5) as a warning check. The `wrap-up` skill WRITES patterns only for failures NOT already recorded by debug in the same session.
 
 1. Record the full error message (first 500 chars) and top 5-10 stack frames
 2. Trace the code path backwards from the error
@@ -101,12 +101,12 @@ Phase 4: Tests pass, null case test added
 
 After the fix is verified (Phase 4):
 
-- [ ] **docs/failure-patterns.md**: If the root cause is a repeatable pattern, add a new FP-NNN entry or increment the Frequency of an existing one. Increment Frequency if the ROOT CAUSE is the same (e.g., all SQL injection bugs = same FP-NNN regardless of which module). Different root causes = different patterns. This is NOT optional. **Note**: When investigate updates failure-patterns.md here, the `learn` skill (Step 3) will skip re-incrementing this same pattern for this session to avoid double-counting.
+- [ ] **docs/failure-patterns.md**: If the root cause is a repeatable pattern, add a new FP-NNN entry or increment the Frequency of an existing one. Increment Frequency if the ROOT CAUSE is the same (e.g., all SQL injection bugs = same FP-NNN regardless of which module). Different root causes = different patterns. This is NOT optional. **Note**: When debug updates failure-patterns.md here, the `wrap-up` skill (Step 3) will skip re-incrementing this same pattern for this session to avoid double-counting.
 - [ ] **docs/project-state.md**: Add the fix to Recent Changes with the root cause hypothesis.
 
 ## Recalculating Mode (invoked by 3-Failure Stop)
 
-When investigate is triggered by another skill/agent's 3-Failure Stop (not by a user-reported bug):
+When debug is triggered by another skill/agent's 3-Failure Stop (not by a user-reported bug):
 
 **Required input**: The caller MUST provide a failure context summary:
 ```
@@ -122,7 +122,7 @@ This input is mandatory — if not provided, ask the caller to supply it before
 3. Complete Phase 1 (Evidence) and Phase 2 (Scope Lock) to diagnose the blocker
 4. Propose 1-2 **alternative approaches** that are fundamentally different from ALL 3 failed attempts
 5. Present to the user for decision — do not auto-execute the alternatives
-6. If investigate itself hits 3 failures in this mode → **full stop**, no further recursion
+6. If debug itself hits 3 failures in this mode → **full stop**, no further recursion
 
 ## Enforced Rules
 
@@ -168,5 +168,5 @@ Example 🧭 block:
 
 ### Personal State
 - Record new failure patterns in your personal .harness/failure-patterns.md
-- If the pattern affects the whole team, promote it (see learn skill Team Mode section)
+- If the pattern affects the whole team, promote it (see wrap-up skill Team Mode section)
 <!-- TEAM_MODE_END -->

package/harness/skills/pivot.md

@@ -8,7 +8,7 @@ Without this, direction changes create silent inconsistencies:docs/project-brief
 ## Invoked By
 
 - **User** (direct) — "방향을 바꾸자", "GraphQL로 변경해줘"
-- **planner** (direction change detected) → BLOCK → pivot required before planning proceeds
+- **pm** (direction change detected) → BLOCK → pivot required before planning proceeds
 
 ## When to Apply
 
@@ -113,15 +113,15 @@ After pivot completes, always append a 🧭 block:
 
 | Pivot Result | 🧭 Next Step |
 |---|---|
-| All state files updated | `planner` — "변경된 방향에 맞춰 재계획해줘" |
-| Crew artifacts exist for new direction | `bootstrap` (🟣) — "crew 산출물을 기반으로 state를 다시 세팅해줘" |
+| All state files updated | `pm` — "변경된 방향에 맞춰 재계획해줘" |
+| Crew artifacts exist for new direction | `setup` (🟣) — "crew 산출물을 기반으로 state를 다시 세팅해줘" |
 | User cancelled | 🏁 No action — "기존 방향을 유지합니다" |
 
 Example 🧭 block:
 ```
 ---
 🧭 Next Step
-→ Next: `planner`
+→ Next: `pm`
 → Prompt: "변경된 방향에 맞춰 재계획해줘"
 → Why: Direction changed — re-plan features for new goals
 → Pipeline: 🟡 Step 2/2

package/harness/skills/{code-review-pr.md → pr-review.md}

@@ -3,7 +3,7 @@
 ## Purpose
 
 Review an external Pull Request (PR) for quality, security, and direction alignment before merging.
-Unlike the `reviewer` agent (which reviews your own changes pre-commit with full project context), this skill is for reviewing incoming PRs from teammates or external contributors. code-review-pr is a cold review — stricter on state file compliance because the reviewer has less context about the PR author's intent.
+Unlike the `reviewer` agent (which reviews your own changes pre-commit with full project context), this skill is for reviewing incoming PRs from teammates or external contributors. pr-review is a cold review — stricter on state file compliance because the reviewer has less context about the PR author's intent.
 
 ## Invoked By
 
@@ -104,15 +104,15 @@ After PR review completes, always append a 🧭 block:
 
 | PR Review Result | 🧭 Next Step |
 |---|---|
-| APPROVE | Merge & `deployment` — "리리즈 준비를 확인해줘" |
-| REQUEST_CHANGES | [Fix] — "PR 지적사항을 수정하세요. 완료 후 다시 `code-review-pr` 호출" |
+| APPROVE | Merge & `release` — "리리즈 준비를 확인해줘" |
+| REQUEST_CHANGES | [Fix] — "PR 지적사항을 수정하세요. 완료 후 다시 `pr-review` 호출" |
 | Direction misaligned | `pivot` — "방향을 전환하고 state 파일을 업데이트해줘" |
 
 Example 🧭 block for APPROVE:
 ```
 ---
 🧭 Next Step
-→ Next: `deployment`
+→ Next: `release`
 → Prompt: "리리즈 준비를 확인해줘"
 → Why: PR approved — validate deployment readiness
 → Pipeline: 🟢/🔵 Step 5/6

package/harness/skills/{deployment.md → release.md}

@@ -48,7 +48,7 @@ Verify all state files are up to date:
 
 ### Step 4: Security Scan
 
-1. Run the `security-checklist` skill
+1. Run the `secure` skill
 2. Verify no credentials, API keys, or `.env` files are staged
 3. Check for known vulnerable dependencies (if applicable)
 
@@ -96,9 +96,9 @@ After deployment validation completes, always append a 🧭 block:
 | Deployment Result | 🧭 Next Step |
 |---|---|
 | READY | [Deploy] — "배포 명령을 실행하세요" |
-| NOT_READY (test failure) | [Fix] — "테스트 실패를 수정해줘. 완료 후 다시 `deployment` 호출" |
-| NOT_READY (state files) | `learn` — "state 파일을 정리해줘" |
-| NOT_READY (security) | `security-checklist` — "보안 이슈를 해결해줘" |
+| NOT_READY (test failure) | [Fix] — "테스트 실패를 수정해줘. 완료 후 다시 `release` 호출" |
+| NOT_READY (state files) | `wrap-up` — "state 파일을 정리해줘" |
+| NOT_READY (security) | `secure` — "보안 이슈를 해결해줘" |
 
 Example 🧭 block for READY:
 ```
@@ -120,15 +120,15 @@ If a deployment fails or a critical issue is found post-deploy:
    - Docker: `docker tag <image>:<previous-tag> <image>:latest && docker push`
    - GitHub: `gh release delete vX.Y.Z` + `git tag -d vX.Y.Z && git push --delete origin vX.Y.Z`
 2. **Record**: Add entry to `docs/failure-patterns.md` with deployment failure details
-3. **Re-validate**: Run `deployment` skill again on the rollback commit to confirm stability
-4. **Post-mortem**: Run `learn` skill to capture the incident for future sessions
+3. **Re-validate**: Run `release` skill again on the rollback commit to confirm stability
+4. **Post-mortem**: Run `wrap-up` skill to capture the incident for future sessions
 
 ## Rules
 
 - Never deploy with failing tests — no exceptions
 - Never deploy with unstaged changes in the working directory
-- Always verify version bump before deployment
-- This skill is read-only — it validates but does not execute the deployment
+- Always verify version bump before release
+- This skill is read-only — it validates but does not execute the release
 
 <!-- TEAM_MODE_START -->
 ## Team Mode: Pre-Deploy Coordination

package/harness/skills/{bootstrap.md → setup.md}

@@ -104,7 +104,7 @@ Check if external planning artifacts exist:
 
 **Original crew documents are NEVER modified. Only the index and tracker are created.**
 
-**Crew Artifact Path Detection** (bootstrap detects all patterns, priority order):
+**Crew Artifact Path Detection** (setup detects all patterns, priority order):
 1. Pattern C: User-provided paths (explicit in prompt) — highest priority, always authoritative
 2. Pattern B: `docs/crew/` (consolidated directory)
 3. Pattern A: `docs/PM/`, `docs/Analyst/`, `docs/ARB/` (kode:crew role-based directories)
@@ -153,7 +153,7 @@ Using data from Phase 1 + Phase 2, fill the following files:
 
 **docs/project-state.md**:
 - Quick Summary: filled with current project state
-- Sprint 1 stories: based on what bootstrap discovered
+- Sprint 1 stories: based on what setup discovered
 - Module Registry: summary from docs/dependency-map.md
 
 **docs/failure-patterns.md**:
@@ -198,7 +198,7 @@ In Team mode, state files are split between shared and personal directories:
 - `.harness/agent-memory/` — agent memory files
 
 When filling state files in Phase 3, write to the correct directories based on this split.
-After bootstrap completes, remind the user that shared files require `git pull` before editing (Pre-Pull Protocol).
+After setup completes, remind the user that shared files require `git pull` before editing (Pre-Pull Protocol).
 <!-- TEAM_MODE_END -->
 
 ## Output Format
@@ -225,13 +225,13 @@ STATUS: DONE
 
 ### 🧭 Navigation — After Bootstrap
 
-Bootstrap always leads to `planner`. Append this block after STATUS: DONE:
+Bootstrap always leads to `pm`. Append this block after STATUS: DONE:
 
 **If NO crew artifacts** (🟢 pipeline):
 ```
 ---
 🧭 Next Step
-→ Next: `planner` (슬래시 메뉴에서 선택하거나, 채팅에 아래 프롬프트 입력)
+→ Next: `pm` (슬래시 메뉴에서 선택하거나, 채팅에 아래 프롬프트 입력)
 → Prompt: "[project]에 [첫 번째 기능]을 추가해줘"
 → Why: State files are filled — now plan the first feature
 → Pipeline: 🟢 Step 2/6
@@ -243,9 +243,9 @@ Bootstrap always leads to `planner`. Append this block after STATUS: DONE:
 ```
 ---
 🧭 Next Step
-→ Next: `planner` (슬래시 메뉴에서 선택하거나, 채팅에 아래 프롬프트 입력)
+→ Next: `pm` (슬래시 메뉴에서 선택하거나, 채팅에 아래 프롬프트 입력)
 → Prompt: "crew 산출물을 기반으로 첫 번째 기능을 계획해줘"
-→ Why: Artifact Index + Validation Tracker created — planner will map FR→Stories
+→ Why: Artifact Index + Validation Tracker created — pm will map FR→Stories
 → Pipeline: 🟣 Step 2/6
 ---
 ```
@@ -264,22 +264,22 @@ Bootstrap always leads to `planner`. Append this block after STATUS: DONE:
 
 For projects with fewer than 3 modules (e.g., single-file scripts, small CLI tools):
 - `docs/dependency-map.md` may have only 1-2 rows — this is normal, not a gap
-- `feature-breakdown` Waves may collapse into a single Wave — skip Wave-level pacing
-- Consider a simplified workflow: `bootstrap → planner → [code] → reviewer → learn` (skip sprint-manager for single-story projects)
+- `breakdown` Waves may collapse into a single Wave — skip Wave-level pacing
+- Consider a simplified workflow: `setup → pm → [code] → reviewer → wrap-up` (skip lead for single-story projects)
 
 ## Embedded Knowledge
 
 ### Session Bootstrap Protocol
-When starting a NEW session (not during bootstrap), read these files in order:
+When starting a NEW session (not during setup), read these files in order:
 1. `docs/project-state.md` — Quick Summary tells you where we left off
 2. `docs/features.md` — What features exist
 3. `docs/failure-patterns.md` — What mistakes to avoid
 4. `docs/project-brief.md` — Project vision and non-goals
 
 ### Workflow Pipeline
-- New feature: `planner → [code] → reviewer → sprint-manager → learn`
-- Bug fix: `investigate → [fix] → test-integrity → reviewer → learn`
-- Session lifecycle: `sprint-manager ("where are we?") → [work] → learn`
+- New feature: `pm → [code] → reviewer → lead → wrap-up`
+- Bug fix: `debug → [fix] → sync-tests → reviewer → wrap-up`
+- Session lifecycle: `lead ("where are we?") → [work] → wrap-up`
 
 ### State File Size Limits
 - docs/project-brief.md: Max 200 lines
@@ -304,18 +304,18 @@ When starting a NEW session (not during bootstrap), read these files in order:
 <!-- TEAM_MODE_START -->
 ## Team Mode: Onboarding
 
-When running bootstrap in Team mode:
+When running setup in Team mode:
 
 ### New Project (first developer)
 1. Run `musher init --team` to create shared + personal state files
-2. Fill all state files via normal bootstrap procedure
+2. Fill all state files via normal setup procedure
 3. Commit shared files (docs/) to git
 4. Push to remote — teammates will clone this
 
 ### Joining Developer (existing project)
 1. Clone the repository (shared docs/ already exist)
 2. Run `musher init --team` — only personal files (.harness/) are created; shared files are skipped
-3. **DO NOT re-run bootstrap interviews** — shared state is already filled by the first developer
+3. **DO NOT re-run setup interviews** — shared state is already filled by the first developer
 4. Review docs/project-brief.md to understand project goals
 5. Create your personal .harness/project-state.md with your current Story assignment
 

package/harness/skills/{learn.md → wrap-up.md}

@@ -9,8 +9,8 @@ This is Musher's memory mechanism — without it, the same mistakes repeat acros
 ## Invoked By
 
 - **User** (direct) — "세션 마무리해줘", "오늘 배운 것 기록해줘"
-- **reviewer** (pass, all done) → learn — 모든 Story 완료 시
-- **reviewer** (STATE-AUDIT) → learn — state 파일 정리 후 세션 종료
+- **reviewer** (pass, all done) → wrap-up — 모든 Story 완료 시
+- **reviewer** (STATE-AUDIT) → wrap-up — state 파일 정리 후 세션 종료
 - Final step in ALL pipelines (🟢/🔵/🔴/🟡)
 
 ## When to Apply
@@ -49,8 +49,8 @@ Before recording failures, verify that the session's work stayed aligned with pr
    - Did the user explicitly change direction during this session? → Note for pivot recommendation
 3. **If drift detected**:
    - Add a warning to the Step 7 Report: `⚠️ Direction drift: [description of misalignment]`
-   - Recommend: "Consider running `pivot` skill to formally update project direction. You can run it AFTER this learn session completes."
-   - Do NOT block — the learn skill always completes
+   - Recommend: "Consider running `pivot` skill to formally update project direction. You can run it AFTER this wrap-up session completes."
+   - Do NOT block — the wrap-up skill always completes
 4. **If no drift**: Proceed silently (no output for this step)
 
 <!-- CREW_MODE_START -->
@@ -83,7 +83,7 @@ For each issue/error that occurred in this session:
 
 1. Read `docs/failure-patterns.md`
 2. Check if this matches an existing pattern (FP-NNN):
-   - **If match found AND already incremented by `investigate` in this session**: Skip — do not double-count. Check `docs/project-state.md` Recent Changes for investigate entries from this session to determine if a pattern was already recorded.
+   - **If match found AND already incremented by `debug` in this session**: Skip — do not double-count. Check `docs/project-state.md` Recent Changes for debug entries from this session to determine if a pattern was already recorded.
    - **If match found AND NOT already incremented this session**: Increment the Frequency counter, add the Sprint/Story to "Occurred"
    - **If new pattern**: Assign next FP-NNN number, create a new entry using this format:
 
@@ -146,7 +146,7 @@ If the `reviewer` agent was run in this session and produced `[STATE-AUDIT]` fla
 State file 변경사항을 커밋합니다. Learn 실행 결과가 커밋되지 않으면 다음 세션에서 유실됩니다.
 
 1. Stage state files: `git add docs/project-state.md docs/failure-patterns.md docs/features.md docs/dependency-map.md docs/agent-memory/`
-2. Commit: `git commit -m "learn: session lessons captured"`
+2. Commit: `git commit -m "wrap-up: session lessons captured"`
 3. If commit fails (nothing to commit), skip — state files were already committed
 
 > **Self-check**: `git status`에 docs/ 아래 unstaged 파일이 없어야 합니다.
@@ -169,14 +169,14 @@ Before ending the session, check for unpushed commits:
 
 ### Step 6: Update Agent Memory (if applicable)
 
-If an agent (reviewer, planner, sprint-manager, architect) was used in this session, update its memory file in `docs/agent-memory/`:
+If an agent (reviewer, pm, lead, architect) was used in this session, update its memory file in `docs/agent-memory/`:
 
 1. Read `docs/agent-memory/{agent-name}.md`
 2. **Auto-initialize if needed**: If the file only contains `<!-- Example entries` placeholder comments and no real data:
    - Replace the placeholder block with actual entries from this session
    - Initialize statistics counters with real values
    - If real entries already exist alongside placeholders, APPEND new entries and remove only the placeholder comments. Do not overwrite existing real data.
-   - **When does initialization happen?**: On the FIRST session where the agent is used AND learn is invoked. If an agent is never used, its memory stays as a placeholder indefinitely — this is expected.
+   - **When does initialization happen?**: On the FIRST session where the agent is used AND wrap-up is invoked. If an agent is never used, its memory stays as a placeholder indefinitely — this is expected.
    - Example transformation:
      ```
      Before: <!-- Example entries (replace with real findings after first review):
@@ -184,8 +184,8 @@ If an agent (reviewer, planner, sprint-manager, architect) was used in this sess
      ```
 3. **Append session learnings** to the appropriate section:
    - **reviewer.md**: Add review patterns found, update statistics (total reviews +1, auto-fixes, escalations)
-   - **planner.md**: Record estimation accuracy (planned vs actual), note architecture discoveries
-   - **sprint-manager.md**: Update velocity (stories done/planned), record any scope drift incidents
+   - **pm.md**: Record estimation accuracy (planned vs actual), note architecture discoveries
+   - **lead.md**: Update velocity (stories done/planned), record any scope drift incidents
    - **architect.md**: Record design decisions made, module boundary insights, anti-patterns observed
 4. Keep entries concise — one line per learning, prefixed with `[S{sprint}-{story}]`
 5. Prune entries older than 5 sprints to stay within the 100-line limit
@@ -229,7 +229,7 @@ Learn is the final skill in every pipeline. Append the appropriate 🧭 block:
 ---
 🧭 Next Step
 → 🏁 Session End
-→ Prompt: "다음 세션 시작 시 `sprint-manager`를 호출하세요"
+→ Prompt: "다음 세션 시작 시 `lead`를 호출하세요"
 → Why: Session lessons captured — state files are up to date
 → Pipeline:
     🟢/🔵: Step 6/6 (complete)
@@ -240,7 +240,7 @@ Learn is the final skill in every pipeline. Append the appropriate 🧭 block:
 <!-- CREW_MODE_START -->
 If crew artifacts were used this session (🟣 pipeline), also append:
 ```
-→ Note: 다음 세션에서 crew 산출물이 업데이트되었다면, `bootstrap`부터 다시 시작하세요
+→ Note: 다음 세션에서 crew 산출물이 업데이트되었다면, `setup`부터 다시 시작하세요
 ```
 <!-- CREW_MODE_END -->
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kodevibe/harness",
-  "version": "0.8.3",
+  "version": "0.9.0",
   "description": "kode:harness — harness engineering for keeping every developer's AI aligned on one project direction.",
   "keywords": [
     "llm",

package/src/init.js

@@ -28,22 +28,22 @@ function writeFile(targetDir, relPath, content, overwrite) {
 // ─── Shared definitions ──────────────────────────────────────
 
 const SKILLS = [
-  { id: 'test-integrity', desc: 'Ensure test mocks stay synchronized when interfaces change. Use when modifying repository or service interfaces.' },
-  { id: 'security-checklist', desc: 'Security risk inspection before commits. Use when reviewing code for security issues.' },
-  { id: 'investigate', desc: 'Investigate and diagnose issues. Use when debugging or analyzing unexpected behavior.' },
-  { id: 'impact-analysis', desc: 'Assess change blast radius. Use when modifying shared modules or interfaces.' },
-  { id: 'feature-breakdown', desc: 'Break down features into implementable stories. Use when planning new features.' },
-  { id: 'bootstrap', desc: 'Onboard project into kode:harness. Scans codebase and fills state files. Use after harness init or when state files are empty.' },
-  { id: 'learn', desc: 'Capture session lessons and update state files. Use at the end of every session.' },
+  { id: 'sync-tests', desc: 'Ensure test mocks stay synchronized when interfaces change. Use when modifying repository or service interfaces.' },
+  { id: 'secure', desc: 'Security risk inspection before commits. Use when reviewing code for security issues.' },
+  { id: 'debug', desc: 'Investigate and diagnose issues. Use when debugging or analyzing unexpected behavior.' },
+  { id: 'check-impact', desc: 'Assess change blast radius. Use when modifying shared modules or interfaces.' },
+  { id: 'breakdown', desc: 'Break down features into implementable stories. Use when planning new features.' },
+  { id: 'setup', desc: 'Onboard project into kode:harness. Scans codebase and fills state files. Use after harness init or when state files are empty.' },
+  { id: 'wrap-up', desc: 'Capture session lessons and update state files. Use at the end of every session.' },
   { id: 'pivot', desc: 'Propagate direction changes across all state files. Use when project goals, technology, scope, or architecture changes.' },
-  { id: 'code-review-pr', desc: 'Review external Pull Requests for quality, security, and direction alignment. Use when reviewing incoming PRs.' },
-  { id: 'deployment', desc: 'Pre-deployment validation checklist. Use before deploying, publishing, or creating release tags.' },
+  { id: 'pr-review', desc: 'Review external Pull Requests for quality, security, and direction alignment. Use when reviewing incoming PRs.' },
+  { id: 'release', desc: 'Pre-deployment validation checklist. Use before deploying, publishing, or creating release tags.' },
 ];
 
 const AGENTS = [
   { id: 'reviewer', file: 'agents/reviewer.md', desc: 'Code review + auto-fix. Validates quality, security, and test integrity before commits.' },
-  { id: 'sprint-manager', file: 'agents/sprint-manager.md', desc: 'Sprint/Story state tracking, next task guidance, scope drift prevention.' },
-  { id: 'planner', file: 'agents/planner.md', desc: 'Feature planning and dependency management. Analyze architecture, break down features.' },
+  { id: 'lead', file: 'agents/lead.md', desc: 'Sprint/Story state tracking, next task guidance, scope drift prevention.' },
+  { id: 'pm', file: 'agents/pm.md', desc: 'Feature planning and dependency management. Analyze architecture, break down features.' },
   { id: 'architect', file: 'agents/architect.md', desc: 'Design review gate. Validates structural changes against project direction and module boundaries.' },
 ];
 
@@ -57,8 +57,8 @@ const STATE_FILES = [
 
 const AGENT_MEMORY_FILES = [
   'agent-memory/reviewer.md',
-  'agent-memory/planner.md',
-  'agent-memory/sprint-manager.md',
+  'agent-memory/pm.md',
+  'agent-memory/lead.md',
   'agent-memory/architect.md',
 ];
 
@@ -78,12 +78,12 @@ function hasFrameworkMarker(content) {
 
 function hasIdeLayout(targetDir, ide) {
   const requiredByIde = {
-    vscode: '.github/skills/bootstrap/SKILL.md',
-    claude: '.claude/skills/bootstrap/SKILL.md',
-    cursor: '.cursor/skills/bootstrap/SKILL.md',
-    codex: '.agents/skills/bootstrap/SKILL.md',
-    windsurf: '.windsurf/skills/bootstrap/SKILL.md',
-    antigravity: '.gemini/skills/bootstrap/SKILL.md',
+    vscode: '.github/skills/setup/SKILL.md',
+    claude: '.claude/skills/setup/SKILL.md',
+    cursor: '.cursor/skills/setup/SKILL.md',
+    codex: '.agents/skills/setup/SKILL.md',
+    windsurf: '.windsurf/skills/setup/SKILL.md',
+    antigravity: '.gemini/skills/setup/SKILL.md',
   };
 
   const requiredPath = requiredByIde[ide];
@@ -466,7 +466,7 @@ function showPostInstallGuide(ideName, mode) {
   lines.push(
     '',
     '  🚀 Next steps:',
-    '     1. Ask your AI: "Run bootstrap to onboard this project"',
+    '     1. Ask your AI: "Run setup to onboard this project"',
     '     2. AI scans your codebase and fills state files automatically',
     '     3. Start coding: ask your AI to plan a new feature',
     '',
@@ -573,7 +573,7 @@ function runValidate(targetDir) {
 
   // Each state file has a known sentinel that only exists in unfilled templates.
   // failure-patterns.md is excluded: it intentionally keeps FP-001~004 as templates
-  // after bootstrap (Frequency: 0 is the normal initial state, not a placeholder).
+  // after setup (Frequency: 0 is the normal initial state, not a placeholder).
   const templateSentinels = {
     'project-state.md': 'S1-1 | Project scaffolding',
     'dependency-map.md': 'Add new modules above this line',
@@ -599,7 +599,7 @@ function runValidate(targetDir) {
       // failure-patterns.md: no sentinel check — template state is normal
       results.push(`  ✅  ${file} — ok (no failures logged yet is normal)`);
     } else if (content.includes(sentinel)) {
-      results.push(`  ⚠️   ${file} — placeholder only. Run \`bootstrap\` to fill.`);
+      results.push(`  ⚠️   ${file} — placeholder only. Run \`setup\` to fill.`);
       warnings++;
     } else {
       results.push(`  ✅  ${file} — has content`);