Mission Control Delivery

Keep software-factory work traceable from operator intent through verified delivery. This skill governs how to reason about the work. It does not grant permission to claim tasks, change Mission Control state, publish packages, merge pull requests, deploy releases, or spend money.

Start from the execution contract

Before editing, identify the available contract fields:

• Mission, WorkOrder, and Task identifiers
• requested outcome and acceptance criteria
• repository, base revision, and allowed code scope
• assigned owner, worker, and approval policy
• change budget, cost budget, and deadline
• required checks, evidence, and review gates

Use repository instructions and the current task context as evidence. Mark a missing material field as Needs confirmation; do not invent identifiers, approvals, owners, or completion state. Routine implementation details inside an authorized scope can be inferred when they do not change the outcome or expand authority.

Execute one bounded Attempt

1. Confirm the repository and base revision before making changes.
2. Use the worktree or checkout assigned to this Attempt. Create isolation only when the harness has not already provided it.
3. Keep edits within the WorkOrder's code scope and change budget. Surface a needed scope expansion before making it.
4. Follow repository architecture and testing rules. Load specialized skills only when their trigger matches the work.
5. Record material decisions, blockers, commands, and evidence against the current Attempt when Mission Control tooling is available.
6. On failure, preserve the failed Attempt and its evidence. Retry through a new Attempt or the product's recovery path instead of rewriting history.

Build the evidence chain

Evidence must identify what it proves and the exact candidate it covers. Capture the failing state before a bug fix when practical, then capture the passing state after the change.

For each required check, retain:

• requirement or acceptance criterion
• command, interaction, or observation
• result: passed, failed, or untested with a reason
• commit SHA, deployment URL, or artifact digest
• artifact path or durable link
• known limitation or stale condition

Tests and visual evidence complement each other. Neither substitutes for the other when the WorkOrder requires both. Never attach old passing evidence to a new candidate without rerunning or proving that it remains current.

Respect decision boundaries

Pause before an action that exceeds the execution contract or requires a human decision. Common examples include expanding scope, changing production data, publishing a context package, merging, deploying, changing an approval policy, or accepting a known failed gate.

Prepare the reviewable result and supporting evidence before requesting the decision when safe work remains. If an approval is denied or expires, stop the dependent action and preserve the current state.

Handoff contract

End with a factual operator handoff:

## Handoff — <WorkOrder or Task ID>

State: <current authoritative state>
Outcome: <what changed or Needs confirmation>
Candidate: <commit, branch, PR, or artifact>
Evidence: <checks and durable references>
Unresolved risk: <known risk or none known>
Decision required: <approval or none>
Next owner: <person, role, or Needs confirmation>
Next action: <one explicit action>

Task completion is not automatically WorkOrder acceptance, Mission completion, pull-request approval, or release authorization. Report each boundary at its actual state.

Mission Control integration

When the repository provides focused Mission Control integration skills, use them for API-specific operations such as registration, heartbeat, task lifecycle, approvals, deliverables, memory, budget, and run logging. Their contracts control those mutations. This skill supplies the delivery model and does not replace them.