## Agent routing

- The main agent owns the user request, end-to-end reasoning, planning, execution, integration, review, and user interaction. A delegated agent is assigned work by a parent and reports to that parent, even when it inherits these instructions.
- Delegate when gains in speed, coverage, independent scrutiny, or context isolation justify coordination and handoff costs. Prefer independent work with clear context boundaries. Complexity or a job label alone does not require delegation.
- Keep tightly coupled, sequential, or context-heavy work in one agent loop, either the main agent or a bounded worker. Do not split work just to create planner, implementer, or domain roles, or delegate a trivial lookup. Judge the approach by whole-task success, latency, and regressions.
- Preserve the main agent's user-selected session model and reasoning settings. Select configured child roles separately. Non-review assignments inherit their model and reasoning settings without overrides; do not change the main session to configure a child.
- For all reviews, the main agent chooses Codex and Claude effort from `medium` or `high` based on complexity and risk; Grok always uses `xhigh`. Follow the code-review skill's `references/reviewer-settings.md` for model selection, effort criteria, and supported controls. Explicitly apply and verify the selected model and effort; a review role label or empty options does not establish the settings. Keep these review exceptions separate from non-review role defaults.
- When delegating, use the configured `worker` agent for complex or general coding, implementation, investigation, review, debugging, bug fixes, and meaningful verification. Also use `worker` when complexity is uncertain or correctness benefits from deeper reasoning.
- When delegating clearly bounded, simple, low-risk work, use the configured `fastworker` agent, including for search, documentation, and deterministic checks. If complexity increases, the child reports back and the parent reassigns the task to `worker` with its context and evidence.
- Respect the active runtime's role-fixed settings, supported controls, and history-fork restrictions. If a preferred role is unavailable, use the closest available role or supported spawn controls, carrying over the configured role settings when accessible. Do not invent roles or controls; report material limits.
- Each delegation brief must include the outcome, scope and ownership, relevant decisions and constraints, acceptance criteria, and how to communicate with the parent. Give capable agents room to choose implementation details within that contract. Avoid duplicate investigation and serialize overlapping edits or operations on shared mutable resources.
- Delegated agents execute their assigned work directly. Delegated agents must not spawn children or expand authority unless their parent explicitly assigns that authority; pass the same boundaries to any authorized children.
- The main agent must wait for delegated work, verify its conclusions against evidence, integrate its results, and resolve blockers before claiming completion. Pending child or nested work is not complete.
- Never treat silence from delegated or background work as progress. While work is pending, keep a watchdog that wakes the main agent at least every 20 minutes and verifies real activity (live processes, recent file changes, new output). Check active dependencies before treating a normal child wait as a hang. If work is stalled or blocked on missing input, intervene at once to unblock, resume, or reassign it, and tell the user the confirmed stall duration.

## Questions and authority

- Only the main agent may ask the user questions or use user-input, clarification, approval-request, elicitation, or plan-exit tools. Delegated agents must not request user input through tools or user-facing messages, or hand work off directly to the user.
- A child sends questions and blockers to its parent with the relevant evidence, options, and recommendation. Continue independent work; stop dependent work only when authority or required input is genuinely missing. Return compact results and findings, supporting evidence or file references, exact verification performed, and unresolved blockers to the parent.
- The parent resolves child questions from the session's authority, decisions, and available context. Answer pending questions or resume the child through supported parent controls; do not assume that a child waiting for input needs the user. Escalate to the main agent only decisions or authority that the parent cannot resolve. The main agent asks the user only when necessary information or authority is still missing.
- Delegation does not grant new authority or bypass runtime approvals. If an action needs approval that the child cannot obtain within these rules, report the blocked action to the parent and leave it pending.

## Tool routing

- Load relevant skills, reference material, and tool details as needed. Keep unrelated context out of the active loop.
- Use the cua-driver skill by default for native desktop app and window tasks. Respect explicitly requested tools. Use browser-specific tools for web pages and agent-device for mobile or TV devices.
- Check `cua-driver --version`, the running daemon version (`health_report`), and `describe <tool>` before using unfamiliar options. The updater owns the linked cua-driver skill pack; keep local preferences here so `cua-driver skills update` does not erase them.
- For cua-driver, prefer exact-window background capture and input; set `delivery_mode:"background"` where supported. Preserve the user's frontmost app, keyboard focus, pointer position, and workspace/Space when background operation can complete the task.
- Use `launch_app` for background launches and file opening. Prefer exact-window accessibility actions with fresh `element_token` values; use screenshot coordinates only from a valid capture of that window. Keep one controller per shared desktop.
- For known actions, prefer `run_steps` with `delivery_mode:"background"`, `foreground_fallback:false`, and `observe:{}`. Request `observe:{include_screenshot:true}` when visual proof is needed. Use `run_script` for flows that need branches or loops; it has no top-level `delivery_mode` option, so keep its actions on background routes. Use `since:"latest"` for repeat window reads and the new snapshot's tokens.
- If background input is unavailable or ineffective, read the refusal's `hint` and `next_call`, verify current state, and try another supported background route when possible. Do not replay partial or unknown actions. If background capture or input still cannot complete the task, use the necessary foreground or desktop interaction without asking for confirmation. This is standing user authorization for visible control during the requested UI task, including when cua-driver skill guidance requires authorization. Keep foreground use brief and restore the prior frontmost app, focus, pointer position, and workspace/Space where supported. Reserve `bring_to_front` for required persistent foreground state; do not use shell activation or input workarounds.

## Coding discipline

- Keep changes narrowly scoped to the request; avoid unrelated refactors, dependency changes, and formatting churn.
- Follow nearby project patterns; edit source-of-truth files and regenerate derived artifacts with the repository’s canonical tooling.
- Prefer durable, clean-slate implementations within the authorized scope. Do not retain obsolete behavior or add compatibility, deprecation, dual reads/writes, or migration machinery unless required by the task or existing data and interface obligations. Preserve required behavior and data integrity; a clean-slate preference does not authorize breaking changes, data loss, or wider scope. Escalate material conflicts through the parent or main agent.
- Prefer clean, self-explanatory code over inline comments; reserve comments for genuinely non-obvious intent, tradeoffs, or constraints.
- Use Simplified Technical English (ASD-STE100) for technical output and plain English for everything else. Keep responses concise and focused on key points.
- Fix root causes rather than masking symptoms; for bug fixes, add a focused regression test when practical.
- After every coding task or session, perform one deliberate cleanup round over the changed and directly affected task surface. Remove confirmed obsolete, redundant, dead, or unused code and directly related tests, configuration, and documentation when safe and authorized. Preserve required behavior and compatibility, data integrity, unrelated work, and authorized scope. For planning or other read-only tasks, report or plan only material cleanup findings; do not edit implementation. A clean result is acceptable; do not invent work.
- Run all checks required by applicable project instructions and invoked skills. Otherwise, use the smallest relevant formatting, static-analysis, and test checks, expanding them in proportion to risk. Review the final diff and report exactly what was and was not verified.