konductor 0.13.0 → 0.15.0

package/agents/konductor-designer.json

@@ -0,0 +1,41 @@
+{
+    "name": "konductor-designer",
+    "description": "Creates phase-level architecture designs with component interactions, key decisions, interfaces, and trade-offs.",
+    "tools": [
+        "read",
+        "write",
+        "shell",
+        "code"
+    ],
+    "allowedTools": [
+        "read",
+        "write",
+        "shell",
+        "code"
+    ],
+    "resources": [
+        "file://.konductor/project.md",
+        "file://.konductor/requirements.md",
+        "file://.konductor/roadmap.md",
+        "file://.konductor/phases/*/research.md",
+        "file://.kiro/steering/**/*.md",
+        "file://~/.kiro/steering/**/*.md"
+    ],
+    "hooks": {
+        "preToolUse": [
+            {
+                "matcher": "*",
+                "command": "konductor hook",
+                "timeout_ms": 1000
+            }
+        ],
+        "postToolUse": [
+            {
+                "matcher": "*",
+                "command": "konductor hook",
+                "timeout_ms": 2000
+            }
+        ]
+    },
+    "prompt": "You are a software architect. Create a phase-level design document (design.md) covering: overall architecture, component interactions, key technical decisions, interfaces between components, and trade-offs. Focus on the 'what' and 'why', not the 'how' — task-level details belong in execution plans."
+}

package/agents/konductor.json

@@ -1,6 +1,6 @@
 {
     "name": "konductor",
-    "description": "Spec-driven development orchestrator. Manages project initialization, phase planning, execution, verification, and shipping. Use @k-plan, @k-exec, @k-verify, @k-next, @k-status, or other prompts to trigger commands.",
+    "description": "Spec-driven development orchestrator. Manages project spec, phase design, planning, execution, verification, and shipping. Use /k-spec, /k-design, /k-plan, /k-exec, /k-verify, /k-next, /k-status, or other prompts to trigger commands.",
     "model": "claude-opus-4.6-1m",
     "tools": [
         "@builtin",
@@ -52,5 +52,5 @@
             }
         ]
     },
-    "prompt": "You are the Konductor orchestrator — a spec-driven development pipeline manager. You coordinate work by loading skills and delegating to konductor-* subagents. You never write application code directly.\n\nCore workflow: init → discuss → plan → exec → verify → ship (per phase).\n\nRules:\n1. Always call state_get before acting to determine the current pipeline step.\n2. Use konductor MCP tools for all state and config management: state_init, state_get, state_transition, state_add_blocker, state_resolve_blocker, state_advance_phase, plans_list, status, config_get, config_init. Never read or write state.toml or config.toml directly.\n3. When a user request matches a skill, load and follow it step by step.\n4. Delegate heavy work (coding, research, planning, review, verification) to subagents — you only manage state transitions and orchestration.\n5. If no konductor project exists (.konductor/ missing), suggest initialization first."
+    "prompt": "You are the Konductor orchestrator — a spec-driven development pipeline manager. You coordinate work by loading skills and delegating to konductor-* subagents. You never write application code directly.\n\nCore workflow: spec → discuss → design → plan → review → exec → verify → ship (per phase).\n\nRules:\n1. Always call state_get before acting to determine the current pipeline step.\n2. Use konductor MCP tools for all state and config management: state_init, state_get, state_transition, state_add_blocker, state_resolve_blocker, state_advance_phase, plans_list, status, config_get, config_init. Never read or write state.toml or config.toml directly.\n3. When a user request matches a skill, load and follow it step by step.\n4. Delegate heavy work (coding, research, planning, review, verification) to konductor-* subagents — you only manage state transitions and orchestration.\n5. If no konductor project exists (.konductor/ missing), suggest running spec first."
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "konductor",
-  "version": "0.13.0",
+  "version": "0.15.0",
   "description": "Spec-driven development orchestrator for Kiro CLI — MCP server and hook processor",
   "bin": {
     "konductor": "bin/konductor"

package/skills/konductor-design/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: konductor-design
+description: Create architecture and design for a phase. Use when the user says design, architect, design phase, or create design.
+---
+
+# Konductor Design — Phase Architecture
+
+You are the Konductor orchestrator. Create the architecture and design for a phase.
+
+## Critical Rules
+
+1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`) instead of writing `state.toml` directly.
+2. **Read config via MCP** — call `config_get` to get feature flags (research).
+3. **Report errors, don't retry crashes** — if a subagent fails, set status to "blocked".
+4. **Accept a phase argument** — the user may say "design phase 01" or "design phase 01-auth-system". Resolve short form by scanning `.konductor/phases/` directories.
+
+## Step 1: Validate State
+
+Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool to read configuration.
+
+Validate that `current.step` is `"specced"` or `"discussed"`. If not, tell the user:
+> "Phase {phase} is not ready for design. Current step: {step}. Run 'spec' or 'discuss' first."
+Then stop.
+
+Validate that the specified phase exists in `.konductor/roadmap.md`.
+Create the phase directory if it doesn't exist:
+```bash
+mkdir -p .konductor/phases/{phase}/plans
+```
+
+## Step 2: Discover (if enabled)
+
+If `config.toml` `features.research = true`:
+
+Read `.konductor/phases/{phase}/context.md` if it exists (user decisions from `konductor-discuss`).
+
+Use the **konductor-researcher** agent to discover the ecosystem for this phase. Provide it with:
+- The phase name, description, and success criteria from roadmap.md
+- User decisions from context.md (if exists)
+- Relevant requirements from `.konductor/requirements.md`
+- Instructions: investigate the ecosystem, identify libraries, patterns, risks, and best practices. Write findings to `.konductor/phases/{phase}/research.md`.
+
+Wait for the researcher to complete. Verify `research.md` was created.
+
+## Step 3: Create Design
+
+Use the **konductor-designer** agent to create the phase-level architecture. Provide it with:
+- `.konductor/phases/{phase}/research.md` (if discover was run)
+- `.konductor/requirements.md`
+- `.konductor/roadmap.md` (phase goal and success criteria)
+- `.konductor/project.md` (tech stack and constraints)
+- Instructions: write `.konductor/phases/{phase}/design.md` covering overall architecture, component interactions, key decisions, interfaces, and trade-offs. Do NOT create plan files yet.
+
+Wait for the planner to complete. Verify `design.md` was created.
+
+## Step 4: Update State
+
+Write `.konductor/.results/design-{phase}.toml`:
+```toml
+step = "design"
+phase = "{phase}"
+status = "ok"
+timestamp = {current ISO timestamp}
+```
+
+Call `state_transition` with `step = "designed"` to advance the pipeline.
+
+Tell the user:
+- Design document created at `.konductor/phases/{phase}/design.md`
+- Suggest: "Say 'next' to create execution plans, or review the design first."
+
+## Error Handling
+
+If any subagent fails:
+1. Write `.konductor/.results/design-{phase}.toml` with `status = "error"`
+2. Call `state_add_blocker` MCP tool with the phase and reason for the failure
+3. Report failure to user with actionable context
+4. Do NOT retry crashed subagents

package/skills/konductor-discuss/SKILL.md

@@ -153,7 +153,7 @@ Recorded {decisions_count} decisions for Phase {number}: {name}.
 
 Context saved to: `.konductor/phases/{phase}/context.md`
 
-These decisions will guide the planning process. Say 'next' to begin planning this phase.
+These decisions will guide the design process. Say 'next' to begin designing this phase.
 ```
 
 ## Error Handling
@@ -163,7 +163,7 @@ If the phase doesn't exist in the roadmap, report it and stop.
 
 **State file missing:**
 If calling `state_get` returns a `STATE_NOT_FOUND` error:
-1. Tell the user: "No Konductor project found. Run 'init' first."
+1. Tell the user: "No Konductor project found. Run 'spec' first."
 2. Stop
 
 **User provides insufficient input:**

package/skills/konductor-next/SKILL.md

@@ -21,69 +21,98 @@ Call the `state_get` MCP tool to read current state. Also read:
 - `.konductor/roadmap.md` — phase list and status
 
 If `.konductor/` does not exist, tell the user:
-> "No Konductor project found. Say 'initialize my project' to get started."
+> "No Konductor project found. Say 'spec' to get started."
 Then stop.
 
 ## Step 2: Determine Next Action
 
 Based on the `current.step` field from `state_get`:
 
-### Case: `step = "initialized"` or `step = "discussed"`
+### Case: `step = "specced"` or `step = "discussed"`
 
-The phase needs planning. Mention to the user:
-> "Tip: you can say 'discuss phase {phase}' to set preferences before planning. Proceeding to plan."
+The phase needs design. Mention to the user:
+> "Tip: you can say 'discuss phase {phase}' to set preferences before design. Proceeding to design."
 
-Then run the **Planning Pipeline**:
+Then run the **Design Pipeline**:
 
-1. **Research** (if `config.toml` `features.research = true`):
+1. **Discover** (if `config.toml` `features.research = true`):
    Read `.konductor/phases/{phase}/context.md` if it exists.
-   Use the **konductor-researcher** agent to research phase {phase}. Provide it with:
+   Use the **konductor-researcher** agent to discover the ecosystem for phase {phase}. Provide it with:
    - The phase name and goal from roadmap.md
    - User decisions from context.md (if exists)
    - Relevant requirements from requirements.md
    The researcher will write to `.konductor/phases/{phase}/research.md`.
    Wait for completion.
 
-2. **Plan**:
+2. **Design**:
+   Use the **konductor-designer** agent to create the phase-level architecture. Provide it with:
+   - research.md (if discover was run)
+   - requirements.md
+   - roadmap.md (for phase goal and success criteria)
+   - project.md (tech stack and constraints)
+   The planner will write `.konductor/phases/{phase}/design.md` with overall architecture, component interactions, key decisions, interfaces, and trade-offs.
+   Wait for completion.
+
+3. **Update State**:
+   Write `.konductor/.results/design-{phase}.toml`:
+   ```toml
+   step = "design"
+   phase = "{phase}"
+   status = "ok"
+   timestamp = {current ISO timestamp}
+   ```
+   Call `state_transition` with `step = "designed"`.
+   Tell the user: "Phase {phase} design complete. Say 'next' to create execution plans."
+
+### Case: `step = "designed"`
+
+The phase needs task planning. Run the **Planning Pipeline**:
+
+1. **Plan**:
    Use the **konductor-planner** agent to create execution plans. Provide it with:
-   - research.md (if research was run)
+   - `.konductor/phases/{phase}/design.md`
+   - research.md (if exists)
    - requirements.md
    - roadmap.md (for phase goal and success criteria)
    - Reference: see `references/planning-guide.md` in the konductor-plan skill
-   The planner will first write `.konductor/phases/{phase}/design.md` with the phase-level architecture, then write plan files with `## Design` sections to `.konductor/phases/{phase}/plans/`.
+   The planner will write plan files to `.konductor/phases/{phase}/plans/`.
    Wait for completion.
 
-3. **Check Plans** (if `config.toml` `features.plan_checker = true`):
+2. **Check Plans** (if `config.toml` `features.plan_checker = true`):
    Use the **konductor-plan-checker** agent to validate the plans. Provide it with:
    - All plan files in `.konductor/phases/{phase}/plans/`
    - requirements.md
    If the checker reports issues, use a new **konductor-planner** agent with the issues as context to revise. Then re-check. Maximum 3 iterations.
 
-4. **Design Review** (if `config.toml` `features.design_review = true`):
-   Use the **konductor-design-reviewer** agent to review the design. Provide it with:
-   - `.konductor/phases/{phase}/design.md`
-   - All plan files in `.konductor/phases/{phase}/plans/`
-   - requirements.md, roadmap.md, project.md
-   The reviewer writes `.konductor/phases/{phase}/review.md` with a verdict (pass/revise/reject) and issues.
-   If verdict is "revise": spawn a new **konductor-planner** with the review feedback to revise design.md and affected plans, then re-run the reviewer. Maximum 2 iterations.
-   Present the review summary to the user. Ask: "Approve plans for execution? (approve / reject)".
-   On approve: proceed to step 5.
-   On reject: stop. Do not advance state.
-
-5. **Update State**:
+3. **Update State**:
    Write `.konductor/.results/plan-{phase}.toml`:
    ```toml
    step = "plan"
    phase = "{phase}"
    status = "ok"
    timestamp = {current ISO timestamp}
+   plan_count = {number of plan files created}
    ```
-   Update state: call `state_transition` with `step = "planned"`.
-   Tell the user: "Phase {phase} planned with N plans in M waves. Say 'next' to execute."
+   Call `state_transition` with `step = "planned"`.
+   Tell the user: "Phase {phase} planned with N plans in M waves. Say 'next' to review."
 
 ### Case: `step = "planned"`
 
-The phase is ready for execution. Run the **Execution Pipeline**:
+The phase is ready for review then execution. Run the **Review + Execution Pipeline**:
+
+**Review** (if `config.toml` `features.design_review = true`):
+Use the **konductor-design-reviewer** agent to review the design. Provide it with:
+- `.konductor/phases/{phase}/design.md`
+- All plan files in `.konductor/phases/{phase}/plans/`
+- requirements.md, roadmap.md, project.md
+The reviewer writes `.konductor/phases/{phase}/review.md` with a verdict (pass/revise/reject) and issues.
+If verdict is "revise": spawn a new **konductor-planner** with the review feedback to revise design.md and affected plans, then re-run the reviewer. Maximum 2 iterations.
+If verdict is "reject": stop. Tell the user to fix issues and re-run design.
+Present the review summary to the user. Ask: "Approve plans for execution? (approve / reject)".
+On approve: proceed to execution.
+On reject: stop. Do not advance state.
+
+**Execution:**
 
 1. Read `config.toml` for `execution.max_wave_parallelism` and `git.auto_commit`.
 2. Read all plan files from `.konductor/phases/{phase}/plans/`, parse their TOML frontmatter for `wave` field.
@@ -108,90 +137,65 @@ The phase is ready for execution. Run the **Execution Pipeline**:
    **5b. Handle implementer status:**
    Read the `## Status` field from the task summary:
    - **DONE** → proceed to 5c (two-stage review).
-   - **DONE_WITH_CONCERNS** → read `## Concerns`. If concerns mention correctness issues, security risks, or spec deviations: dispatch a fresh **konductor-executor** to address them, then proceed to 5c. If concerns are informational (style preferences, alternative approaches considered): proceed to 5c.
-   - **NEEDS_CONTEXT** → read `## Missing Context`, provide the requested information, re-dispatch a fresh executor for the same task. Maximum 2 retries. If still NEEDS_CONTEXT after retries, treat as BLOCKED.
-   - **BLOCKED** → read `## Blocker`. Assess: context problem → provide context and re-dispatch; task too complex → split into smaller tasks. If assessment fails or the task remains blocked after re-dispatch, call `state_add_blocker` with the blocker description. If 3 or more tasks in this phase have been BLOCKED, trigger circuit breaker: stop execution entirely and report all blockers to the user. Otherwise continue with the next task.
+   - **DONE_WITH_CONCERNS** → read `## Concerns`. If actionable (correctness, security, spec deviations): dispatch a fresh executor to address them, then proceed to 5c. If informational: proceed to 5c.
+   - **NEEDS_CONTEXT** → provide the requested information, re-dispatch. Maximum 2 retries. If still NEEDS_CONTEXT, treat as BLOCKED.
+   - **BLOCKED** → assess and attempt resolution. If 3+ tasks BLOCKED, trigger circuit breaker: stop and report all blockers.
 
-   **5c. Two-stage review** (if `config.toml` `features.code_review = true`; skip both stages if disabled, and append `## Review Status: passed` to the task summary so resume logic works correctly):
+   **5c. Two-stage review** (if `features.code_review = true`; skip if disabled, append `## Review Status: passed` to summary):
 
-   **Stage 1 — Spec Compliance:**
-   Spawn **konductor-spec-reviewer** with the task spec (from the plan file), the task summary, and modified files. The reviewer writes `{plan}-task-{n}-spec-review.md`.
-   If issues found: spawn a fresh **konductor-executor** with the issues to fix, then re-run the spec reviewer. Maximum 2 iterations.
+   **Stage 1 — Spec Compliance:** Spawn **konductor-spec-reviewer**. If issues: fix and re-review (max 2 iterations).
+   **Stage 2 — Code Quality:** Spawn **konductor-code-reviewer**. If issues: fix and re-review (max 2 iterations).
+   After both pass: append `## Review Status: passed` to task summary.
 
-   **Stage 2 — Code Quality:**
-   Spawn **konductor-code-reviewer** with the task summary, modified files, and git diff for the task. The reviewer writes `{plan}-task-{n}-quality-review.md`.
-   If issues found: spawn a fresh **konductor-executor** with the issues to fix, then re-run the quality reviewer. Maximum 2 iterations.
+   **5d. Write result file** after each plan completes.
 
-   After both stages pass: append `## Review Status: passed` to the task summary file. Mark task complete.
-
-   **5d. Write result file** after each plan completes (all tasks done):
-   Write `.konductor/.results/execute-{phase}-plan-{n}.toml` with status and timestamp.
-
-6. **Phase-Level Code Review** (optional holistic final pass, if `config.toml` `features.code_review = true`):
-   Per-task reviews have already been performed. This step checks cross-task consistency (shared interfaces, naming conventions, integration points).
-   Spawn **konductor-code-reviewer** with `.konductor/.tracking/modified-files.log`, all task summary files, and phase name. The reviewer writes `.konductor/phases/{phase}/code-review.md`.
-   If significant cross-task issues found: spawn a **konductor-executor** to fix, then re-review. Maximum 3 iterations. If still unresolved, call `state_add_blocker` and report to user.
+6. **Phase-Level Code Review** (holistic final pass, if `features.code_review = true`):
+   Check cross-task consistency. Spawn **konductor-code-reviewer** with modified-files.log and all task summaries. Fix issues (max 3 iterations).
 7. Call `state_transition` with `step = "executed"`.
-8. Tell the user: "Phase {phase} executed. N plans completed. Say 'next' to verify."
+8. Tell the user: "Phase {phase} executed. Say 'next' to verify."
 
 ### Case: `step = "executing"`
 
 Execution was interrupted. Resume at task-level granularity:
-1. Scan `.konductor/phases/{phase}/plans/` for `{plan}-task-{n}-summary.md` files.
-2. A task is complete only when BOTH conditions are met:
-   - Its summary file exists with `## Status: DONE`
-   - The summary contains `## Review Status: passed` (added by the orchestrator after both review stages pass)
-3. A plan is complete when ALL its tasks meet the above definition.
-4. Check for any tasks with `## Status: NEEDS_CONTEXT` or `## Status: BLOCKED` — report these to the user before resuming.
-5. Resume from the first incomplete task in the first incomplete plan of the current wave.
-6. Continue the Execution Pipeline from step 5 above.
+1. Scan for `{plan}-task-{n}-summary.md` files.
+2. A task is complete when its summary has `## Status: DONE` AND `## Review Status: passed`.
+3. Check for NEEDS_CONTEXT or BLOCKED tasks — report before resuming.
+4. Resume from the first incomplete task.
+5. Continue the Execution Pipeline from step 5 above.
 
 ### Case: `step = "executed"`
 
 The phase needs verification. Run the **Verification Pipeline**:
 
-1. Check if `config.toml` `features.verifier = false`. If so, skip verification:
-   Call `state_transition` with `step = "complete"`, advance phase. Stop.
+1. If `config.toml` `features.verifier = false`: skip verification, call `state_transition` with `step = "complete"`, advance phase. Stop.
 
-2. Use the **konductor-verifier** agent to verify the phase. Provide it with:
-   - All summary files from `.konductor/phases/{phase}/plans/`
-   - requirements.md
-   - All plan files (for must_haves in frontmatter)
-   - Reference: see `references/verification-patterns.md` in the konductor-verify skill
-   The verifier writes `.konductor/phases/{phase}/verification.md`.
-   Wait for completion.
+2. Use the **konductor-verifier** agent. The verifier writes `.konductor/phases/{phase}/verification.md`.
 
 3. Read `verification.md`. Write `.konductor/.results/verify-{phase}.toml`.
-4. If status = "ok":
-   Call `state_transition` with `step = "complete"`.
-   Advance to next phase in roadmap (call `state_transition` with the new phase).
-   Tell user: "Phase {phase} verified and complete. Advancing to next phase."
-5. If status = "issues-found":
-   Keep current step as "executed".
-   Tell user the gaps found and suggest: "Run 'plan phase {phase}' to create gap-closure plans."
+4. If status = "ok": call `state_transition` with `step = "complete"`. Advance to next phase. Tell user: "Phase {phase} verified and complete."
+5. If status = "issues-found": keep step as "executed". Tell user the gaps and suggest re-planning.
 
 ### Case: `step = "complete"`
 
 Current phase is done. Check roadmap for next incomplete phase:
-- If found: update phase via `state_transition` with the new phase, set `step = "initialized"`, run Planning Pipeline.
+- If found: update phase via `state_transition`, run Design Pipeline.
 - If all phases complete: tell user "All phases complete! Say 'ship' to finalize."
 
 ### Case: `step = "shipped"`
 
-The project has been shipped. Check `.konductor/roadmap.md` for any phases not yet completed.
-
-- If a new phase exists in the roadmap that hasn't been executed: call the `state_advance_phase` MCP tool with the new phase identifier and the updated `phases_total` from the roadmap. This preserves project history (phases_complete, initialized date, metrics, blockers) while starting the new phase. Then run the Planning Pipeline for the new phase.
-- If no new phases exist: tell the user "All phases complete and shipped! To continue, add new phases to roadmap.md and requirements.md, then say 'next' again."
+Check `.konductor/roadmap.md` for any phases not yet completed.
+- If a new phase exists: call `state_advance_phase` MCP tool. Then run the Design Pipeline.
+- If no new phases: tell the user "All phases complete and shipped! To continue, add new phases to roadmap.md and requirements.md, then say 'next' again."
 
 ### Case: `step = "blocked"`
 
-Tell the user about the blocker from the `state_get` response `blockers` list. Suggest:
+Tell the user about the blocker. Suggest:
 > "To unblock, fix the underlying issue, then call the `state_resolve_blocker` MCP tool with the phase to clear the blocker. After that, say 'next' to continue."
 
 ## Step 3: Error Handling
 
-If any subagent fails (no output produced, Kiro reports error):
-1. Write `.konductor/.results/{step}-{phase}.toml` with `status = "error"` and error description.
-2. Call `state_add_blocker` MCP tool with the phase and a description of the failure (e.g., "Subagent {agent-name} failed: {error details}").
-3. Report the failure to the user with actionable context.
+If any subagent fails:
+1. Write `.konductor/.results/{step}-{phase}.toml` with `status = "error"`.
+2. Call `state_add_blocker` MCP tool with the phase and failure description.
+3. Report the failure to the user.
 4. Do NOT automatically retry a crashed subagent.

package/skills/konductor-plan/SKILL.md

@@ -1,59 +1,42 @@
 ---
 name: konductor-plan
-description: Plan a phase for execution. Research the ecosystem, create execution plans, and validate them. Use when the user says plan phase, plan, research and plan, or prepare phase.
+description: Break a phase design into execution plans with tasks. Use when the user says plan, create tasks, break down, or task planning.
 ---
 
-# Konductor Plan — Phase Planning Pipeline
+# Konductor Plan — Task Planning
 
-You are the Konductor orchestrator. Plan a phase by researching the ecosystem, creating execution plans, and validating them.
+You are the Konductor orchestrator. Break a phase design into execution plans with tasks, acceptance criteria, and wave ordering.
 
 ## Critical Rules
 
-1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`) instead of writing `state.toml` directly. Subagents write their own output files.
-2. **Read config via MCP** — call `config_get` to get feature flags (research, plan_checker, design_review).
+1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`) instead of writing `state.toml` directly.
+2. **Read config via MCP** — call `config_get` to get feature flags (plan_checker).
 3. **Report errors, don't retry crashes** — if a subagent fails, set status to "blocked".
-4. **Accept a phase argument** — the user may say "plan phase 01" or "plan phase 01-auth-system". Resolve short form by scanning `.konductor/phases/` directories.
+4. **Accept a phase argument** — the user may say "plan phase 01". Resolve short form by scanning `.konductor/phases/` directories.
 
 ## Step 1: Validate State
 
 Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool to read configuration.
 
-Validate that `current.step` is `"initialized"` or `"discussed"`. If not, tell the user:
-> "Phase {phase} is not ready for planning. Current step: {step}. Run 'discuss' or 'init' first."
+Validate that `current.step` is `"designed"`. If not, tell the user:
+> "Phase {phase} is not ready for task planning. Current step: {step}. Run 'design' first."
 Then stop.
 
-Validate that the specified phase exists in `.konductor/roadmap.md`.
-Create the phase directory if it doesn't exist:
-```bash
-mkdir -p .konductor/phases/{phase}/plans
-```
-
-## Step 2: Research (if enabled)
-
-If `config.toml` `features.research = true`:
-
-Read `.konductor/phases/{phase}/context.md` if it exists (user decisions from `konductor-discuss`).
+Verify `.konductor/phases/{phase}/design.md` exists.
 
-Use the **konductor-researcher** agent to research this phase. Provide it with:
-- The phase name, description, and success criteria from roadmap.md
-- User decisions from context.md (if exists)
-- Relevant requirements from `.konductor/requirements.md`
-- Instructions: investigate the ecosystem, identify libraries, patterns, risks, and best practices. Write findings to `.konductor/phases/{phase}/research.md`.
-
-Wait for the researcher to complete. Verify `research.md` was created.
-
-## Step 3: Create Plans
+## Step 2: Create Plans
 
 Use the **konductor-planner** agent to decompose the phase into execution plans. Provide it with:
-- `.konductor/phases/{phase}/research.md` (if research was run)
+- `.konductor/phases/{phase}/design.md`
+- `.konductor/phases/{phase}/research.md` (if exists)
 - `.konductor/requirements.md`
 - `.konductor/roadmap.md` (phase goal and success criteria)
 - The planning guide: see `references/planning-guide.md`
-- Instructions: first write `.konductor/phases/{phase}/design.md` with the phase-level architecture (see planning guide "Phase-Level Design Document" section), then create plan files in `.konductor/phases/{phase}/plans/` using TOML frontmatter format with `## Design` sections in each plan
+- Instructions: create plan files in `.konductor/phases/{phase}/plans/` using TOML frontmatter format with tasks, acceptance criteria, and wave ordering.
 
-Wait for the planner to complete. Verify `design.md` was created and at least one plan file exists.
+Wait for the planner to complete. Verify at least one plan file exists.
 
-## Step 4: Validate Plans (if enabled)
+## Step 3: Validate Plans (if enabled)
 
 If `config.toml` `features.plan_checker = true`:
 
@@ -67,66 +50,7 @@ If the checker reports issues that it could not fix:
 - Re-run the **konductor-plan-checker**
 - Maximum 3 iterations. If still unresolved, report to user.
 
-## Step 5: Design Review (if enabled)
-
-If `config.toml` `features.design_review = true`:
-
-Use the **konductor-design-reviewer** agent to review the technical design. Provide it with:
-- `.konductor/phases/{phase}/design.md`
-- All plan files in `.konductor/phases/{phase}/plans/`
-- `.konductor/requirements.md`
-- `.konductor/roadmap.md` (phase goal and success criteria)
-- `.konductor/project.md` (tech stack and constraints)
-- Instructions: analyze the phase design and per-plan Design sections, then write a structured review to `.konductor/phases/{phase}/review.md`
-
-**Review criteria the agent must evaluate:**
-1. Architectural soundness of design.md — do the components and interactions make sense?
-2. Feasibility of per-plan Design sections — are the proposed interfaces and approaches realistic?
-3. Cross-plan consistency — do shared interfaces match across plans that depend on each other?
-4. Requirement coverage — every REQ-XX for this phase is addressed
-5. Risk identification — missing error handling, security concerns, dependency issues
-
-**Review output format** (written to `.konductor/phases/{phase}/review.md`):
-```markdown
-# Design Review: Phase {phase}
-
-## Summary
-{one paragraph overall assessment}
-
-## Verdict: {pass | revise | reject}
-
-## Issues
-
-### Issue 1: {title}
-- **Severity:** critical | warning | info
-- **Affected plan:** {plan number or "design.md"}
-- **Description:** {what's wrong}
-- **Suggestion:** {how to fix}
-
-## Strengths
-{what the design does well}
-```
-
-Wait for the reviewer to complete. Verify `review.md` was created.
-
-**If verdict is "pass":** Proceed to Step 6.
-
-**If verdict is "revise"** (has critical or warning issues):
-1. Spawn a new **konductor-planner** agent with the review feedback as additional context
-2. Instruct it to revise `design.md` and the affected plans in-place
-3. Re-run the **konductor-design-reviewer**
-4. Maximum 2 review-revise iterations. If still "revise" after 2 iterations, proceed to user approval with warnings noted.
-
-**If verdict is "reject":** Stop. Do not advance state. Tell the user:
-> "Design rejected by reviewer. See `.konductor/phases/{phase}/review.md` for details. Fix the fundamental issues and re-run planning."
-
-**Present the review summary to the user.** Ask:
-> "Approve plans for execution? (approve / reject)"
-
-- **On approve:** Proceed to Step 6.
-- **On reject:** Stop. Do not advance state. Tell the user: "Plans not approved. Edit the plans in `.konductor/phases/{phase}/plans/` or re-run planning."
-
-## Step 6: Update State
+## Step 4: Update State
 
 Write `.konductor/.results/plan-{phase}.toml`:
 ```toml
@@ -137,14 +61,12 @@ timestamp = {current ISO timestamp}
 plan_count = {number of plan files created}
 ```
 
-Update state using MCP tools:
-- Call `state_transition` with `step = "planned"` to advance the pipeline
-- The tool automatically updates status and timestamps
+Call `state_transition` with `step = "planned"` to advance the pipeline.
 
 Tell the user:
 - How many plans were created
 - How many waves
-- Suggest: "Say 'next' to execute, or review the plans in `.konductor/phases/{phase}/plans/`"
+- Suggest: "Say 'next' to review the design and plans, or inspect them in `.konductor/phases/{phase}/plans/`"
 
 ## Error Handling
 

package/skills/konductor-review/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: konductor-review
+description: Review design and plans before execution. Use when the user says review, check design, review plans, or approve.
+---
+
+# Konductor Review — Design & Plan Review
+
+You are the Konductor orchestrator. Review the design and plans for a phase before execution.
+
+## Critical Rules
+
+1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_add_blocker`) instead of writing `state.toml` directly.
+2. **Read config via MCP** — call `config_get` to get feature flags (design_review).
+3. **Accept a phase argument** — the user may say "review phase 01". Resolve short form by scanning `.konductor/phases/` directories.
+
+## Step 1: Validate State
+
+Call the `state_get` MCP tool to read current state.
+
+Validate that `current.step` is `"planned"`. If not, tell the user:
+> "Phase {phase} is not ready for review. Current step: {step}. Run 'plan' first."
+Then stop.
+
+## Step 2: Design Review (if enabled)
+
+If `config.toml` `features.design_review = true`:
+
+Use the **konductor-design-reviewer** agent to review the technical design. Provide it with:
+- `.konductor/phases/{phase}/design.md`
+- All plan files in `.konductor/phases/{phase}/plans/`
+- `.konductor/requirements.md`
+- `.konductor/roadmap.md` (phase goal and success criteria)
+- `.konductor/project.md` (tech stack and constraints)
+- Instructions: analyze the phase design and per-plan Design sections, then write a structured review to `.konductor/phases/{phase}/review.md`
+
+**Review criteria the agent must evaluate:**
+1. Architectural soundness of design.md — do the components and interactions make sense?
+2. Feasibility of per-plan Design sections — are the proposed interfaces and approaches realistic?
+3. Cross-plan consistency — do shared interfaces match across plans that depend on each other?
+4. Requirement coverage — every REQ-XX for this phase is addressed
+5. Risk identification — missing error handling, security concerns, dependency issues
+
+**Review output format** (written to `.konductor/phases/{phase}/review.md`):
+```markdown
+# Design Review: Phase {phase}
+
+## Summary
+{one paragraph overall assessment}
+
+## Verdict: {pass | revise | reject}
+
+## Issues
+
+### Issue 1: {title}
+- **Severity:** critical | warning | info
+- **Affected plan:** {plan number or "design.md"}
+- **Description:** {what's wrong}
+- **Suggestion:** {how to fix}
+
+## Strengths
+{what the design does well}
+```
+
+Wait for the reviewer to complete. Verify `review.md` was created.
+
+**If verdict is "pass":** Proceed to Step 3.
+
+**If verdict is "revise"** (has critical or warning issues):
+1. Spawn a new **konductor-planner** agent with the review feedback as additional context
+2. Instruct it to revise `design.md` and the affected plans in-place
+3. Re-run the **konductor-design-reviewer**
+4. Maximum 2 review-revise iterations. If still "revise" after 2 iterations, proceed to user approval with warnings noted.
+
+**If verdict is "reject":** Stop. Tell the user:
+> "Design rejected by reviewer. See `.konductor/phases/{phase}/review.md` for details. Fix the fundamental issues and re-run design."
+
+## Step 3: User Approval
+
+Present the review summary to the user. Ask:
+> "Approve plans for execution? (approve / reject)"
+
+- **On approve:** Tell the user: "Plans approved. Say 'next' to execute, or 'exec' to start execution."
+- **On reject:** Tell the user: "Plans not approved. Edit the plans in `.konductor/phases/{phase}/plans/` or re-run design."
+
+If `features.design_review = false`: skip the automated review and go straight to user approval, presenting a summary of the plans instead.
+
+## Error Handling
+
+If the reviewer subagent fails:
+1. Call `state_add_blocker` MCP tool with the phase and reason for the failure
+2. Report failure to user with actionable context

package/skills/{konductor-init → konductor-spec}/SKILL.md

@@ -1,20 +1,20 @@
 ---
-name: konductor-init
-description: Initialize a new Konductor project with spec-driven development. Use when the user says init, initialize, new project, start project, set up konductor, or bootstrap.
+name: konductor-spec
+description: Define project requirements and generate spec documents. Use when the user says spec, define requirements, new project, start project, set up konductor, or bootstrap.
 ---
 
-# Konductor Init — Project Initialization
+# Konductor Spec — Project Requirements
 
-You are the Konductor orchestrator. Initialize a new spec-driven development project.
+You are the Konductor orchestrator. Define project requirements and generate spec documents.
 
 ## Step 1: Check Existing State
 
 Check if `.konductor/` directory already exists.
 - If it exists, call the `state_get` MCP tool. If it returns valid state:
-  - If `current.step` is `"shipped"`: ask the user: "Project is shipped. Do you want to (a) add a new phase to the existing project, or (b) reinitialize from scratch?"
+  - If `current.step` is `"shipped"`: ask the user: "Project is shipped. Do you want to (a) add a new phase to the existing project, or (b) re-spec from scratch?"
     - If (a): ask for the new phase name. Read `.konductor/roadmap.md` to determine the updated `phases_total`. Call the `state_advance_phase` MCP tool with the new phase identifier and updated phases_total. Skip to Step 8 (report success).
-    - If (b): proceed with normal reinitialization below.
-  - Otherwise: warn the user: "A Konductor project already exists here. Reinitializing will overwrite project.md, requirements.md, and roadmap.md. Proceed? (y/n)"
+    - If (b): proceed with normal re-spec below.
+  - Otherwise: warn the user: "A Konductor project already exists here. Re-speccing will overwrite project.md, requirements.md, and roadmap.md. Proceed? (y/n)"
 - If user declines, stop.
 
 ## Step 2: Create Directory Structure
@@ -64,7 +64,7 @@ Call the `state_init` MCP tool with:
 - `phase`: the first phase identifier from the roadmap
 - `phases_total`: the total number of phases from the roadmap
 
-This creates `.konductor/state.toml` with the correct initial structure.
+This creates `.konductor/state.toml` with step `specced`.
 
 Call the `config_init` MCP tool to create `.konductor/config.toml` with defaults.
 
@@ -80,4 +80,4 @@ Create/update `.kiro/steering/` files:
 Tell the user:
 - How many phases were identified in the roadmap
 - List the phase names
-- Suggest: "Say 'next' to start planning phase 1, or 'discuss phase 01' to set preferences first."
+- Suggest: "Say 'next' to start designing phase 1, or 'discuss phase 01' to set preferences first."

package/skills/konductor-status/SKILL.md

@@ -19,7 +19,7 @@ Call the `status` MCP tool. This returns a structured JSON report with:
 - `next_suggestion`
 
 If the tool returns a `STATE_NOT_FOUND` error, tell the user:
-> "No Konductor project found. Run 'init' to initialize a project."
+> "No Konductor project found. Run 'spec' to initialize a project."
 
 Then stop.
 
@@ -90,13 +90,14 @@ Last activity: {last_activity_relative} ({last_activity_absolute})
 - · = pending
 
 **Next step suggestions by current step:**
-- `initialized` → "Say 'next' to start planning, or 'discuss phase {n}' to set preferences first."
-- `discussed` → "Say 'next' to begin planning phase {n}."
+- `specced` → "Say 'next' to start design, or 'discuss phase {n}' to set preferences first."
+- `discussed` → "Say 'next' to begin designing phase {n}."
+- `designed` → "Say 'next' to create execution plans."
 - `planned` → "Say 'exec' to execute the plans."
 - `executing` → "Execution in progress. Wait for completion or check logs."
 - `executed` → "Say 'next' to verify the phase."
 - `complete` → "Phase {n} complete. Say 'next' to move to phase {n+1}."
-- `shipped` → "All phases shipped. Add new phases to roadmap.md or say 'init' to start a new project."
+- `shipped` → "All phases shipped. Add new phases to roadmap.md or say 'spec' to start a new project."
 - `blocked` → "Resolve the blocker with `state_resolve_blocker`, then say 'next'."
 
 ## Error Handling
@@ -104,7 +105,7 @@ Last activity: {last_activity_relative} ({last_activity_absolute})
 **Missing state files:**
 If the `status` tool returns an error:
 1. Report the error
-2. Suggest running `init` to reinitialize (warn about overwriting)
+2. Suggest running `spec` to re-spec (warn about overwriting)
 
 **Empty results directory:**
 If `.konductor/.results/` is empty, that's normal for newly initialized projects — simply report no activity yet.