# Planner Orchestration > Enforce Kandev's single-session, user-controlled model workflow for feature, fix, debug, review, verification, and delivery work. - Skill: `kdlbs/planner-orchestration` (Agent Skill) - Install (CLI): `npx skillmds@latest add kdlbs/planner-orchestration` - Raw SKILL.md: https://api.skillmd.com/api/skills/kdlbs/planner-orchestration/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: kdlbs (https://skillmd.com/u/kdlbs) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kdlbs/planner-orchestration --- # Single-Session Orchestration The user-started primary conversation owns durable artifacts, integration judgment, and user communication. Platform-provided explorers and other predefined subagents may continue to serve the harness's normal investigation workflow. This skill governs planned implementation delegation, not the platform's general exploration behavior. ## Model Checkpoints The user, not the harness, selects the model. Keep each phase in the primary conversation so the active model, transcript, and costs are visible in one place. 1. **Design checkpoint — strong model.** Use the user's strong model for clarification, codebase investigation, requirements, system designs, plans, work-order decomposition, and high-risk decisions. Default Codex guidance is GPT-5.6 Sol/high. 2. **Design-package handoff.** Once the requirements, system design, plan, and work orders are ready, summarize their paths and end the turn. Do not call `ask_user_question_kandev` (or an equivalent approval prompt) to ask the user to approve the package or switch models. The user reviews the files, switches the main session if desired, and sends a later explicit implementation request. The files may remain `draft`/`pending`; do not wait for a separate approval marker. 3. **Execution checkpoint.** After that explicit request, read the work order, mark it `in_progress`, implement with `/tdd`, run its exact targeted checks, and mark it `done`. Work sequentially through the plan by default. The user, not the harness, chooses the active implementation model. 4. **Escalation checkpoint.** Stop and ask the user to switch back to a stronger model before an architectural redesign, a new public contract, a migration or persistence boundary, or a high-impact security decision. Record a durable decision when the `/record` trigger applies. Luna/low is appropriate only for clearly mechanical, read-only work such as short status summaries or simple command-output interpretation. It is not the default implementation or test model. The active agent must never claim a model change occurred based on self-identification; use runtime model-usage metadata when such confirmation is needed. ## Work-Order Workflow Feature work still follows `/spec`, `/plan`, and `/spec-driven-development`: - Store requirements in `docs/specs//requirements/`. - Store technical design in `docs/specs//system-design/`. - Store `plan.md` and independently actionable sibling work orders in `docs/plans//`. - Use `pending`, `in_progress`, and `done` work-order status as the durable execution record. The primary agent updates both the current work order and the plan's status after each completed work order. - Keep work orders small enough that the same conversation can resume from their acceptance criteria, owned files, and exact verification command after a user switches model. Work-order files are a model-switch handoff and, if the user explicitly asks for subagents, a compact work packet. They must include requirement IDs, system-design references, scope, dependencies, owned files, acceptance, verification, and risks. They must not name an agent role or model tier. ## User-Authorized Subagents Plans may label dependency waves and parallel-safe candidates. That is planning information only: execute sequentially unless the user explicitly asks to use subagents after selecting the implementation model. When the user authorizes subagents: - Use the platform's native delegation tool, never Kandev task/session MCP APIs. - Do not recreate project custom-agent files or pin a different worker model. The child must use the active model the user selected in the primary session. - Use `fork_turns: "none"` (or the platform equivalent), not a full-history fork. Put the work-order path, owned files, acceptance criteria, exact command, and dependencies in the initial prompt. - Launch only tasks explicitly marked parallel-safe with disjoint files and no shared schema, migration, generated contract, lockfile, or package config. - Tell each child not to spawn further children. Update shared `plan.md` status serially in the primary session. - Confirm model routing from runtime usage metadata, not a model's prose. If it does not show the user-selected model, stop the delegation and report it. If the user does not explicitly authorize delegation, do not infer permission from a plan's waves or parallelism labels. The read-only `pr-poller` is a delivery exception, not an implementation worker. Launch it only after the user explicitly asks to wait for or monitor PR updates; it reports status to the primary conversation and never remediates, comments, or spawns children. ## Task-Driven Validation And PR Review Each work order owns its TDD requirement and exact unit, integration, or E2E commands. Its completed status and recorded command results are the pre-PR evidence; do not add a second generic validation pass here. Do not automatically run `/simplify`, `/qa`, `/code-review`, security review, or broad `/verify` before opening a PR. Those duplicate the task validation and the two configured PR AI reviewers. Run them only when the user explicitly asks or an actionable PR/CI finding requires a focused remediation. After the PR opens, the two configured AI reviewers are the semantic-review gate. Use `/pr-fixup` only to address a CI failure or actionable reviewer finding. A remediation reruns its relevant task-defined checks, not a broad local suite unless explicitly requested. Treat the OpenCode App as trusted semantic evidence only when `trusted_producer=true` confirms its dedicated producer provenance. ## Guardrails - Do not treat a plan wave as authorization to launch implementation workers; that decision remains with the user. This does not restrict platform-provided explorers or other harness-managed investigation agents. - Do not use Kandev MCP task/session APIs as a worker mechanism. Use them only when the user explicitly asks to manage persistent Kandev tasks or sessions. - Do not create worktrees solely to parallelize plan tasks unless the user has explicitly authorized subagents for parallel-safe tasks. - Do not continue from the design-package handoff automatically or treat artifact creation as implementation authorization. Wait for a later explicit implementation request; the user controls any model switch between turns. - Do not replace durable requirements, system designs, plans, work orders, tests, or verification with chat-only summaries.