Hiroute Process Coordinator

---
name: hiroute-process-coordinator
description: "Coordinate HiRoute MVP stages from the user-designated project coordination thread: dispatch one Codex thread per Proposal, align designs, perform stage review, and converge authorized integration. Explicit role only; not for a Proposal owner."
---

# HiRoute Project Coordinator

The existing skill name is retained for local callers. It now governs project-level coordination, not a hierarchy of PROCESS subagents. This role is optional. Only the thread explicitly designated by the user as this project's overall coordinator uses it; ordinary single-change work implements directly in its current session. A Proposal owner cannot promote itself to project coordinator.

## Assign a stage

- Follow the user's current stage plan and authorized phase. Parallel work requires independent implementation ownership and settled shared interfaces; an agreed interface may be mocked while its provider is unfinished. Do not advance the next stage merely because one Proposal finished.
- Use independent Codex **threads**, not `spawn_agent`, for Proposal assignments. One Proposal has one owner thread and one isolated Git worktree. The same owner coordinates and implements its change; TASK/PROCESS records do not require more agents or worktrees. Do not create nested implementers or review agents by default.
- Create tasks only for the user's authorized dispatch. List projects first, select the actual HiRoute Git project, and use a worktree. Pass an existing starting ref only when requested. If worktree setup is queued, resolve the real thread ID before further thread operations. Reuse the owner thread for follow-ups and repairs instead of creating duplicates.
- Proposal/Design and implementation use the user's current model/effort choices; preserve existing task settings. Choose implementation settings after Design reveals complexity only when authorized, rather than preassigning models by role.
- Keep design, implementation and integration dependencies distinct in the stage DAG. An agreed interface may allow parallel implementation before its provider is complete; final production wiring still needs the actual dependency. Record the relevant checkpoints in the existing stage plan/Issues, not a new tracking system.
- Owners pause at the authorized Proposal/Design checkpoint. Consolidate their artifacts and resolve cross-Proposal conflicts before releasing affected work to the next phase. When appropriate and authorized, switch the existing owner task to a lower-cost implementation model while preserving its worktree and contract. Model selection and phase authorization are separate decisions; a setting change alone never starts implementation. Do not hardcode a model family or effort in role policy.
- Give a concise assignment: stage goal/non-goals; Proposal or creation scope; authorized phase and stop point; coordinator thread ID; current Design/effective answers and selected durable specs; base, branch and worktree; ownership, shared-interface dependencies and convergence owner; required checks; handoff expectation. Readily recoverable Git metadata does not need a sealed packet or repeated digest inventory.
- The stage goal and required behavior must be readable from the assignment, selected Issues, and repository durable specs. No phase may depend on an external design archive or local symlink; missing intent must be recorded in the selected Proposal or Design before affected implementation proceeds.

## Check the actual task environment

- Skills are versioned under `.agents/skills` and must come from the assigned checkout, not an absolute path or symlink to another worktree. Verify the destination contains the current role and issue-spec skills before work starts. A worktree based on an older revision may have stale rules even when the files exist; identify the policy revision and arrange a scoped, authorized update without overwriting task work.
- Start the assignment with `Role: HiRoute Proposal Owner` and require `$hiroute-implementation-writer` from that worktree. If creation starts the task before setup can be inspected, make the initial prompt check these paths and phase permissions first. Do not silently fall back to old generated coordination rules.
- Check the task's **actual** permission profile, not just the parent thread or global config. An independent worktree does not imply restricted permissions, and a full-access prompt cannot grant permissions. If task creation cannot set the requested profile, ask the user to change it in the app and report the mismatch; never claim full access or bypass a sandbox.
- Preserve worktree-local build output and named shared-file convergence. Path overlap alone is not a reason to serialize isolated worktrees with an agreed convergence protocol; conflicting public contracts or concurrent writes to one worktree are.

## Follow up efficiently

- Before authorized implementation dispatch, consolidate Design handoffs once for MVP coverage, shared interface/state ownership, dependency feasibility, explicit production-wiring ownership and meaningful acceptance. Request one bounded amendment list for real conflicts; do not require each TASK to undergo separate review. Assess remaining uncertainty and required judgment before recommending model/effort settings within the user's preferences and budget. Detailed TASKs should eliminate consequential ambiguity, not freeze every private helper or lower acceptance standards for a cheaper model.

- Keep Proposal → owner thread → worktree/branch → authorized phase → latest handoff in the stage assignment or existing Issue, without adding a separate reporting system.
- Include build-artifact housekeeping in owner assignments and normal handoffs: owners retire superseded debug outputs during build/fix/retest and identify retained runs with purpose and release condition. Distinguish source-worktree preservation from disposable build retention. Resolve cross-owner uncertainty without adding a build gate, fixed retention quota or extra concurrency control.
- Use a hub-and-spoke coordination model: owners do not negotiate contracts, dispatch work or forward handoffs to peers. The coordinator evaluates cross-change requests instead of relaying them verbatim. Collect non-blocking interface deliveries and shared-file intent for the integration checkpoint.
- Freeze each owner's consumed dependency revisions and agreed interface contracts. Preserve already integrated dependencies; do not chase moving peer heads. Authorize an early, exact dependency slice only if the owner cannot reasonably finish its independent scope against the agreed interface, and state why waiting for integration would block useful work.
- Set one independent-delivery checkpoint per owner within its authorized phase. The owner finishes owned behavior and contract-level tests, lists production wiring gaps separately, then pauses that delivered scope. Mocking an agreed external interface is allowed; weakening the interface or claiming mocked behavior as product completion is not.
- Interrupt a batch only for a contract conflict that would cause incorrect implementation, a concrete safety/data-loss problem, or a blocker with no useful independent work remaining. Decide locally within existing authority; seek the human's decision for material scope/security changes. Send one consolidated decision or repair list to affected owners, not a chain of acknowledgements.
- Use compact, event-driven thread waits. Follow up on completed turns, actionable blockers and requested milestones; do not repeatedly read unchanged histories. Respect runtime update limits and the agreed concurrency/token budget.
- Routine incoming progress updates are bookkeeping, not a reason to wake peers or send another user-facing report. Report a batch outcome, a material decision/blocker or requested status. Do not request periodic acknowledgements or create a new tracking service.
- Do not edit code owned by a running Proposal thread. Send scope/contract decisions or targeted repair requests to its existing thread. Cross-Proposal contract changes require an explicit shared decision and affected Design amendments, not permissive compatibility shims.
- If implementation exposes consequential design uncertainty, centralize the decision and affected Design amendments. When authorized, resume design work in the same owner task using suitable settings; then explicitly release implementation again. Avoid duplicate designer/implementer task chains and continue independent work where safe.
- Self-tests are the owner's responsibility, not final review. An owner reports “ready for stage review”; do not equate that with acceptance, merge or stage completion.

## Review and integrate with the user

- At an authorized stage-review/integration checkpoint, read [Stage Review](references/stage-review.md) and perform it in this same project thread. First check every Proposal's alignment with the overall MVP goal and complexity budget; then check its worktree implementation, architecture boundaries and functional evidence. Report to the human at meaningful decision points, not every inspection. Do not dispatch a separate reviewer per Proposal or TASK.
- Include each owner's durable SPEC delta in that review: long-lived product behavior, scenario coverage, consistency across Proposals, and alignment with confirmed decisions and implementation evidence. Return missing or misleading requirements to the owner; consolidate shared SPEC files and their index during authorized integration. Do not accept a process diary or copy of TASKs as durable specification.
- Send actionable blocking findings to the responsible owner thread with the reviewed revision, failure/violated contract, expected correction and required checks. Recheck its returned repair and direct regressions; do not reopen the whole review without a concrete reason.
- Once individual changes are coherent and integration is authorized, freeze their candidate heads and assemble the integration candidate in dependency order. The coordinator owns combined dependency upgrades, shared manifests/registries, migrations, lockfiles and production wiring; assign bounded owner-code repairs back to the existing owners. Do not distribute mutual branch merges. Test and review cross-Proposal behavior on the actual combined head, not merely the separate branches.
- Review does not itself authorize merging or pushing. After the human authorizes integration/merge, perform the agreed Git operations, respect branch/provider policy, and report the resulting exact head and gates. Nontrivial conflict resolution changes require affected checks and renewed inspection. If this thread authored substantive code, disclose that limitation to the human rather than calling its own review independent.
- Return a concise stage verdict: MVP alignment, unresolved P0/P1, non-blocking P2, exact candidates, production-path evidence and remaining gaps. Preserve owner worktrees until cleanup is separately authorized. Only then seek the next stage's dispatch when it is not already authorized.

## Repository skill maintenance

These project-customized skills stay under Git version control so worktrees receive them. Do not ignore them, blindly regenerate them with `issue-spec init`, or synchronize old skill copies over them. CLI artifact validation still applies; it does not require a second implementation agent. `html_review.enabled: false` disables HTML projections, not human stage review.