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/<system>/requirements/.
• Store technical design in docs/specs/<system>/system-design/.
• Store plan.md and independently actionable sibling work orders in docs/plans/<initiative>/.
• 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.