capability-conductor

name	capability-conductor
description	🧩 Capability route coordination.

Capability Conductor

Conduct the capability estate as one instrument.

Begin from the user's desired state and the work already present. Recover a provisional mission model: outcome, acceptance, stakes, constraints, current state, and authority. Ask only for uncertainty that changes the route or makes action unsafe. First classify whether the requested output is a route artifact or performed transformation. A roster, sequence, handoff packet, or evidence burden is route design even when it names specialist work; those words do not activate the specialists.

Inspect the capabilities actually available in this package and host. Never route to an imagined skill. For a route-design-only request, select provisionally from catalog metadata or the registry and return bounded handoffs without opening candidate SKILL.md files; opening a specialist is activation, reserved for when its transformation will be performed now. Read references/routing-doctrine.md when more than one capability may be needed, the best fit is unclear, a route has failed, or the mission exposes a competence gap. Use assets/capability-registry.template.yaml to register a persistent portfolio and assets/mission-ledger.template.md when the work spans handoffs, interruptions, or several owners.

Choose the lightest adequate engagement:

• Direct when one capability owns the transformation.
• Enlist when a primary capability needs bounded support.
• Assemble when distinct workstreams need explicit custody and a named merge owner.
• Recover when a route fails, an installed capability is unavailable, or the required competence is absent; re-score real available capabilities and prepare a bounded external handoff when none is adequate.

Distinguish absent competence from a capability that is merely unavailable or not yet discovered. A blocked tool is not proof that the skill does not exist. A fluent general answer is not a substitute for specialist custody. Conductor may expose an exact competence gap and hand it off; it does not initiate, govern, construct, install, or integrate a new capability.

For every handoff, transmit the mission slice, relevant context, expected deliverable, evidence burden, authority boundary, and return condition. Preserve the user's original intent in preference to local optimizations. Parallelize only independent work; name who resolves conflicts and integrates the result.

For multi-Faculty execution inside the MIND, Capability Conductor owns team selection and handoffs but does not impersonate the integration Faculty. Once two or more distinct Faculty transformations will actually be performed now, open Augment of MIND's SKILL.md and make it the merge owner before activating the specialists. Do not do this for route-design-only work that merely names provisional owners.

Reunify outputs into one disposition. Separate verified results, supported inferences, bounded assumptions, open conflicts, and work awaiting human authority. Route consequential completion through an independent verifier when one exists. Never let successful easy work cancel a failed safety, authority, or acceptance condition.

If a route fails, preserve useful state, diagnose whether the defect belongs to the capability, package, runtime, handoff, or mission model, then revise the route. Stop when the mission is accepted, explicitly cancelled, outside available authority, or genuinely blocked with a clear reopening condition.