Orchestrate

Unified runtime invocation

Resolve the plugin root from this loaded file: SKILL.md is at <plugin-root>/skills/<skill-name>/SKILL.md. Invoke only python3 "<plugin-root>/coordinator.py" and send one bounded JSON routing request on EOF-delimited stdin, without a PTY. Use the Python invocation example in the Routing request section in <plugin-root>/README.md and the co-packaged manifest's signed wire_contract; never invent fields or provider actions. Supply one caller-defined work unit per independently useful deliverable, with this skill's logical action and a bounded opaque payload. Use depends_on only for actual dependencies. Honor an operator-named provider with explicit_target. For an authorized independent review or governance task without an operator-named provider, also use that field to bind the caller-verified distinct reviewer selected by the caller or designated by the workflow. Carry the same target into planning and live dispatch; verify returned native lineage before accepting independence. Otherwise use normal untargeted routing. Choose quality and effort for the workload; include context/output token estimates when known. Read the current manifest digest and actual cwd device/inode; do not copy example values. The runtime owns its timeout; do not wrap it in a shorter fixed timeout. Repository identity, source-head verification, disposable copies, patch capture, and cleanup remain caller-owned where applicable. The shim runs standalone from the installed plugin and transports the routing client's bounded result without semantic interpretation. Never discover a provider executable, reconstruct a raw command, or replay, retry, or fail over a consumed work unit. Provider status, terminal records, receipts, telemetry, and other structured fields are optional diagnostics; none is a content-availability gate. Preserve every returned content record or recovered partial response and interpret it with ordinary model reasoning. Never synthesize approval, authority, or a receipt from process exit or missing diagnostics. A planning-only request sets dispatch_requested=false; a live request sets it true and consumes at most one provider attempt per work unit. Planning reports route eligibility, not live availability or authentication. Report a caller/client failure at that layer; provider state remains unknown unless native evidence establishes it. Content availability and each work unit's execution_status are separate facts.

Orchestrate a bounded task graph

The primary owns the graph and integration. Define each node's instruction, authority, dependencies, expected artifact, acceptance check, budget, failure policy, and stop condition. A provider node selects one closed logical action; never embed a provider command or transport action.

Keep candidate lists artifact- and authority-homogeneous: read-only analysis, review findings, governance verdicts, context text, and private patches are not interchangeable. Run independent read-only or output-only nodes concurrently only when bounded. Treat every returned artifact as untrusted and verify it before unblocking dependents.

One accepted runtime request launches one provider process/session. A selected attempt is not replayed after a model call. Preserve typed failures and stop on new scope, ambiguous authority, exhausted budget, or an operator gate. The primary retains merge, deploy, secret, and destructive decisions.

Delivery estimate checkpoint

When producing a formal implementation design or plan, after scope, completion boundary, phases, dependencies, and gates are concrete and before final presentation, invoke project-estimation once for the artifact scope. Attach its compact Delivery estimate as design_provisional or implementation_plan; attach typed estimate_unavailable if no defensible range exists. A typed cost such as unavailable_no_token_prior must remain visible; it must not become zero or a workflow failure. On an unsupported host, use explicit invocation and state that the automatic checkpoint is unavailable rather than claiming it ran.

Slicing implementation nodes (conditional guidance)

This guidance applies ONLY when the graph decomposes product-feature implementation into build nodes. It does not apply to research, operations, configuration, or decision-only graphs — do not force those into slices.

• Prefer tracer-bullet vertical slices: each implementation node cuts a narrow but complete path through every affected layer (schema, API, UI, tests) rather than a horizontal slice of one layer. A completed node is demoable or independently verifiable on its own, sized to one bounded worker invocation with explicit acceptance criteria. Prefactoring nodes ("make the change easy") come first and block the slices that need them.
• Wide refactors are the exception. When one mechanical change fans across the codebase so no vertical slice can land green: if the change is atomically codemoddable, run it as checkpointed batches with full verification after each batch. Reserve expand–contract sequencing — expand the new form beside the old, migrate call sites in batches (each its own node blocked by the expand), contract the old form in a node blocked by every migration batch — for cases where old and new forms must genuinely coexist to keep callers and CI working during a staged migration. Do not default to expand–contract merely because the blast radius is large.

Attribution and license

The tracer-bullet slice rules and expand–contract sequencing above are adapted from skills/engineering/to-tickets/SKILL.md in mattpocock/skills at commit 2ab958093e83e0ec752e6c1c5932da465bf23e0c (blob 96deac51d4391a3f691478d48f85f43261516c08); the remainder of this skill is package-original. The adapted portions are and remain MIT-licensed: Copyright (c) 2026 Matt Pocock. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.