version: "1.0.0" name: orchestrate-implementation-run description: >- Orchestrate an approved feature or specification as a lightweight hub-and-spoke team. Use when it contains several bounded discovery or implementation slices that can run independently while one coordinator stays user-facing and the task plan is sufficient orchestration state.

Orchestrate Implementation Run

Use a hub-and-spoke topology: keep the invoking agent as coordinator and every delegated agent as a leaf. Keep the coordinator user-facing and make it the sole owner of integration, approvals, and closure. Use the coordinator's task plan as the orchestration state unless the repository contract owns another state artifact. Keep one authoritative decision/evidence record; do not mirror the same state across plans, feature docs, and HTML notes.

Run four coordinator phases in order: Orient → Assign leaves → Implement and integrate → Verify and close. Supporting skills satisfy steps inside a phase; only these four completion gates advance the run.

1. Orient

1. Read the repository's AGENTS.md, routed rules, specification or request, relevant source, tests, and current worktree state.
2. Build an acceptance map from every requested outcome to a checkable observation. Propose independent slices; name known dependencies and unknowns.
3. Resolve edit, commit, status, worktree, device, UI, and external-action authority separately. For commits, record the starting HEAD and dirty

paths, whether commits are allowed, the repository's message and staging conventions, and who may create them. Keep the coordinator as the sole integration and commit owner unless the repository explicitly establishes another safe ownership model; leaves do not commit by default.

1. Resolve the authoritative decision/evidence record. Use an existing plan, ticket, worklog, ADR, or feature document when it already owns the

information. Select $maintain-implementation-notes only when the user or repository requires it, or the skill's cold-handoff criteria apply; otherwise do not create an HTML ledger. If selected, keep the coordinator as its single writer.

1. Route each material uncertainty to a read-only scout or record it with its affected slice, impact, and recommended default. Ask the user when the

answer changes product, privacy, architecture, or release scope.

Complete orientation when: every requested outcome has an acceptance observation; every proposed slice has its dependencies and unknowns named; authority, the commit owner, commit conventions, and authoritative record are explicit; and every material uncertainty is routed to a scout or recorded as a blocking question.

2. Assign leaves

Use the user's or host's configured model by default; omit a model override unless an explicit preference or repository rule selects one. Check available models and supported reasoning efforts before applying an override. Place reasoning where the ambiguity is, using the closest supported effort when these labels are unavailable:

Default to fresh context. Inherit context only when a material conversation decision cannot be summarized safely. End every assignment with the leaf boundary:

Complete this assignment directly and return results to your parent. Remain a leaf: do not spawn other agents.

Give every leaf one self-contained assignment containing:

• deliverable and checkable completion criterion;
• repository root, relevant rules, specification sections, and acceptance observations;
• owned files or seam, read-only or edit scope, and exact authority;
• dependencies, canonical teammate recipients, required checks, evidence location, and return format;
• for Apple tests or runtime checks, the --label the leaf passes to every $manage-apple-simulators claim and release (for example its slice

name), or the parent claim it uses without releasing;

• preservation of unrelated dirty state and material decisions for the selected authoritative record.

Name information dependencies. Have a leaf message the named teammate and coordinator when it produces or needs dependency information, then summarize material peer messages in its final report. Messages carry information; the original ownership and authority remain unchanged.

Read the configured concurrency capacity. At four slots, run the coordinator and up to three independent leaves. Spawn only work with disjoint write ownership.

Treat a dependency-changing slice as in flight until the coordinator accepts its integrated result. When commits are authorized, do not assign work that depends on the changed seam until the prerequisite slice passes focused checks and is committed. Without commit authority, wait for the same integration and check gate, then name the exact uncommitted dependency in the downstream assignment. An explicit repository ownership model may allow another commit owner; follow its isolation and handoff rules rather than inventing one for the run.

Complete assignment when: every active leaf has the full assignment contract, all write ownership is disjoint, every dependency has a named recipient, and the coordinator remains available to the user.

3. Implement and integrate

1. Send independent read-only scouts in parallel when discovery can reduce implementation risk.
2. If orientation selected a separate implementation-notes ledger, invoke $maintain-implementation-notes before the first material implementation

decision when practical. Otherwise keep decisions in the selected existing record.

1. Convert stable findings into the smallest useful worker assignments. Use a smart worker for a difficult or ambiguous seam.
2. Inspect actual edits, underlying check output, and peer messages as each leaf finishes. Return focused gaps to the owning leaf while it is live.
3. Before replacement, inspect landed work and assign only the remaining scope.
4. Integrate a coherent slice in the coordinator. A leaf report is not a commit boundary: include every change required for one reviewable behavior or

contract, and exclude incomplete or unrelated work.

1. Run the slice's focused checks. At accepted milestones, update only the authoritative record with material decisions, deviations, and blockers.

Keep routine commands, device claim state, commit hashes, and duplicated acceptance text in their existing evidence, Git, or PR owners.

1. When commits are authorized, land the accepted slice before assigning dependent work:

• inspect git status against the recorded starting state and identify the exact owned files or patches;
• stage only that scope, never unrelated dirty state or a broad add whose contents were not inspected;
• inspect the complete staged diff and run the repository's staged-diff checks before every commit;
• commit with the repository's convention, then record the hash beside the slice and its check evidence.

1. Record resulting hashes in Git/PR metadata and orchestration status. Do not create a later notes edit or bookkeeping commit merely to copy hashes.

Apply these gates explicitly:

• No commit authority: do not stage or commit. Keep the accepted slice identifiable in the worktree, record its exact paths and evidence, and

report it as uncommitted. Downstream work may start only after the integrated predecessor passes its focused checks and the assignment names that shared-worktree dependency.

• Failed checks: do not commit the slice or unlock dependent work. Record the failure, return the smallest correction to the current owner when

practical, and rerun the focused gate after the fix.

• Partial integration: do not commit a mixture of finished and unfinished behavior. Commit an independently coherent subset only when it is safe

and reviewable on its own; otherwise keep the whole seam in progress.

• Shared dependency seam: when multiple leaves contribute to one seam, stop overlapping writes and serialize integration in the coordinator.

Run the seam's focused checks on the combined result and create one coherent commit before downstream assignment.

Complete integration when: every slice is integrated and inspected or explicitly blocked; every material peer message is resolved; all focused checks have observed results; every authorized accepted slice is committed before dependent work; and the authoritative record plus orchestration status reflect material decisions, evidence, and blockers.

4. Verify and close

Run the smallest relevant checks first and broaden only when the changed contract crosses boundaries. Assign one owner per verification resource and retain the underlying results.

For any Tuist, Xcode, xcodebuild, Simulator, Device Hub, Playbook snapshot, or Apple runtime-QA branch, invoke $run-apple-verification-loop. Before closure, require its evidence and the release of every claimed simulator or device through $manage-apple-simulators.

Close against the acceptance map:

• inspect the commit range from the recorded starting HEAD, each committed slice, and the current worktree;
• compare committed paths with git status, preserving recorded unrelated changes and identifying any intended scope left uncommitted;
• map every acceptance criterion to an observed result or explicit blocker;
• confirm every required test executed and every claimed Apple simulator or device was released;
• when a separate implementation-notes page was selected and changed, validate it with $maintain-implementation-notes; do not create final hash

bookkeeping;

• report committed hashes and summaries in order, the checks and evidence for each slice, remaining worktree changes, blockers, and exact verification

limits. When authority was absent, state that no commits were created and report the exact uncommitted scope instead.

Complete the run when: every acceptance criterion has an observed result or recorded blocker, every claimed simulator, device, or other resource is released, the scoped worktree and authoritative record agree with the implemented scope, every intended authorized change is committed or explicitly blocked, and no active assignment remains unresolved.