konductor 0.10.0 → 0.11.0

package/package.json

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

package/skills/konductor-exec/SKILL.md

@@ -10,13 +10,13 @@ You are the Konductor orchestrator. Execute the plans for a phase by spawning ex
 ## 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 (summary files, result files).
-2. **Read `config.toml` first** — respect parallelism settings and git configuration.
+2. **Read config via MCP** — call `config_get` to get parallelism settings and git configuration.
 3. **Report errors, don't retry crashes** — if an executor fails, write an error result for that plan, continue with remaining plans, and report all failures at the end.
 4. **Resume support** — scan for existing summary files to skip completed plans.
 
 ## Step 1: Read State and Config
 
-Call the `state_get` MCP tool to read current state, and read `.konductor/config.toml` for execution settings (parallelism, git config).
+Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool for execution settings (parallelism, git config).
 
 Validate that `[current].step` is either:
 - `"planned"` — ready to start execution

package/skills/konductor-init/SKILL.md

@@ -62,23 +62,7 @@ Call the `state_init` MCP tool with:
 
 This creates `.konductor/state.toml` with the correct initial structure.
 
-Write `.konductor/config.toml`:
-```toml
-[general]
-default_model = "claude-sonnet-4"
-
-[execution]
-max_wave_parallelism = 4
-
-[git]
-auto_commit = true
-branching_strategy = "none"
-
-[features]
-research = true
-plan_checker = true
-verifier = true
-```
+Call the `config_init` MCP tool to create `.konductor/config.toml` with defaults.
 
 ## Step 7: Sync Steering Files
 

package/skills/konductor-next/SKILL.md

@@ -11,13 +11,13 @@ You are the Konductor orchestrator. Your job is to determine the next step in th
 
 1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`, `plans_list`) instead of writing `state.toml` directly. Subagents never touch state. They write their own output files.
 2. **`.results/` is the source of truth** — if state and `.results/` conflict, trust `.results/`.
-3. **Read `config.toml` first** — respect feature flags and parallelism settings.
+3. **Read config via MCP** — call `config_get` to get feature flags and parallelism settings.
 4. **Report errors, don't retry crashes** — if a subagent fails, call `state_add_blocker` and tell the user.
 
 ## Step 1: Read State
 
 Call the `state_get` MCP tool to read current state. Also read:
-- `.konductor/config.toml` — feature flags and settings
+- Call the `config_get` MCP tool for feature flags and settings
 - `.konductor/roadmap.md` — phase list and status
 
 If `.konductor/` does not exist, tell the user:

package/skills/konductor-plan/SKILL.md

@@ -10,13 +10,13 @@ You are the Konductor orchestrator. Plan a phase by researching the ecosystem, c
 ## 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.toml` first** — respect feature flags (research, plan_checker, design_review).
+2. **Read config via MCP** — call `config_get` to get feature flags (research, plan_checker, design_review).
 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.
 
 ## Step 1: Validate State
 
-Call the `state_get` MCP tool to read current state, and read `.konductor/config.toml`.
+Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool to read configuration.
 Validate that the specified phase exists in `.konductor/roadmap.md`.
 Create the phase directory if it doesn't exist:
 ```bash

package/skills/konductor-verify/SKILL.md

@@ -10,13 +10,13 @@ You are the Konductor orchestrator. Verify a phase after execution to validate t
 ## 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.toml` first** — respect feature flags and settings.
+2. **Read config via MCP** — call `config_get` to get feature flags and settings.
 3. **Report errors, don't retry crashes** — if the verifier fails, set status to "blocked".
 4. **Use the 3-level verification framework** — Exists, Substantive, Wired (see references/verification-patterns.md).
 
 ## Step 1: Read State and Validate Phase
 
-Call the `state_get` MCP tool to read current state, and read `.konductor/config.toml` for verification settings.
+Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool for verification settings.
 
 Validate that `[current].step` is `"executed"`.