Vc Ship

Invocation for vc-ship (launcher ship)

Same three-path shape as the fleet, with this skill's literals — see the canonical Delegation Matrix:

• Shared three paths
• Launcher catalogue
• Per-launcher rule
• Native vs external

Path	Literal for this skill
1. User-launched worker	vibecrafted ship <agent> / vc-ship
2. Interactive	/vc-ship — execute in this session; use native subagents when required; do not externalize merely because a launcher exists
3. Agent-operator	may dispatch the worker form above via vc-dispatch / operator lines while preserving this skill's identity

Note: Lifecycle umbrella (scaffold→release). Stages keep their own launchers.

Freer native on some runs ≠ abandon external fleet. vc-dispatch and vc-ship keep their own identities.

vc-ship — the lifecycle umbrella: one mission, eleven stages, one baton

Operator Entry

Living Tree / Worktree Rule

This workflow runs in the operator's current checkout and current branch. Do not create, switch to, or move execution into a git worktree unless the operator explicitly asks for one in this prompt. Re-read files before editing, adapt to concurrent changes, and report substrate failure if the tree is too poisoned to continue safely. The one sanctioned second mode is a Fleet Worktree dispatch (written plan, pre-committed verifiers, disjoint domains, single-thread integrator — see Living Tree Rule, Mode B); outside that formation, stay in the shared tree.

See Living Tree Rule.

Canonical Orientation Gate

Before this lifecycle umbrella launches its first stage — and before every WRITE stage it later supervises touches source — it MUST run or consume the vc-init procedure for the mission's repo. The mission file itself is only valid when grounded in a real vc-init pass; if fresh vc-init evidence is absent, perform the init pass first and treat the whole flight as blocked until repo truth exists. A prompt is a hypothesis, never the ground truth.

Loctree:loctree is the default structural perception skill for that pass. Use Loctree before grep or docs-driven claims to produce or refresh the Code-Derived Application Map: repo-view, focus, slice, impact, find, and follow as relevant. Search for existing symbols and contracts before creating new ones; run impact before delete or major refactor; run slice before editing. As supervisor you carry this map as baton cargo, so each stage worker inherits the same structural truth instead of re-discovering the repo from zero.

The point is to find the hooks before the eleven stages fly: load-bearing hubs, twins, dead code, drift, runtime entrypoints, and blast-radius traps. If the mission is explicitly non-repo or no-code, state the no-repo exception in the report. Otherwise, missing vc-init/Loctree evidence is a process failure and the flight has not honestly begun.

Repository Work Doctrine

For repository work, start with Loctree as the map: use loct context, loct occurrences, loct body, and loct find --literal before broad manual search. Use AICX for intent and session context. Use rg/grep as fallback or local magnifier, not as a replacement for structural mapping. If Loctree fails or misses a surface, append feedback to ~/.vibecrafted/loctree/loctree-fail.md.

Standard launcher:

vibecrafted ship <agent> --file /path/to/mission.md     # canonical: mission file
vibecrafted ship codex --prompt 'one-cut mission text'  # short missions
vc-ship claude --file mission.md                        # shell shortcut
vibecrafted ship <agent> --start-stage review --file m.md  # resume mid-pipeline

Runtime invariant: stage workers fly headless, so the lifecycle survives vc-frame and User Session loss. Observe through lifecycle state, transcripts, observe, and await. --runtime terminal is an explicit compatibility exception for a provider path proven to require a TTY.

Purpose

Run one product mission through the complete Read-Write cadence as a single supervised lifecycle run, and make the invoking agent the supervisor of that run: verifying every stage report, steering with the human-controls verbs, and carrying the baton (with its report cargo) from scaffold all the way to release. The goal of every flight is the dictated one: big win and ZERO DoU index — or an honest, traced accept-dou for what remains undone.

The Pipeline (Read-Write Cadence)

READ stages must not write source (a violation is traced as read_phase_violation); WRITE stages must show commits and green gates.

How To Fly (supervisor protocol)

1. Mission first. Compose the mission as a durable .md file under ~/.vibecrafted/artifacts/<org>/<repo>/<date>/plans/ — grounded in a real vc-init pass (Loctree atlas + AICX intents + git/risk truth), with explicit deliverables, hard constraints, and gates. --file delivers it verbatim to every stage worker.

2. Launch with the standard launcher above. Verify the launch receipt: run_id (life-ship-…), context atlas loaded, stage 1 accepted.

3. Arm await immediately, supervisor-side (never inside a subagent — see docs/runtime/AGENT_OPS.md): After dispatch, arm vibecrafted await <agent> --run-id <id> immediately, supervisor-side. Control-plane JSON, report files, transcripts, panes, and scheduled wakeups are diagnostic only, not wake signals. Hedging await with ad-hoc pollers/watchers is a Class 3 violation; fix control_plane.await_run, do not normalize the hedge. Stage report checks and ship status --json are diagnostics subordinate to that canonical await; ship status --json exposes stage_worker with worker_dead_without_report — the actionable death signal; the dispatcher also writes worker_exit / stage_worker_exit into state.json push-side when a worker dies. 3-signal liveness: before declaring done, reconcile await verdict, terminal run meta, and worker pid dead; if a report is promised, confirm it exists. Two agreeing signals are enough to act, three to declare done; disagreement means treat as live and re-arm await. Known skew: rc=0-on-live and meta stuck active/stalled after real completion.

4. Verify before every button. Read the report; for WRITE stages confirm the commits and gates actually exist; for READ stages confirm no read_phase_violation. Honor worker steering from report frontmatter (next_stage, next_agent, dou_index) unless it is nonsense — then override with a verb.

5. Drive with verbs, never with manual state surgery:

   vibecrafted ship runs                       # list lifecycle runs
   vibecrafted ship status <run_id> --json     # truth before any button
   vibecrafted ship approve <run_id>           # baton → next stage (cargo-gated)
   vibecrafted ship approve <run_id> --force   # traced override of the cargo gate
   vibecrafted ship interrupt <run_id>         # stop a blind/dead continuation
   vibecrafted ship fallback <run_id> --stage <s>  # rewind the baton WITH cargo
   vibecrafted ship force-audit <run_id>       # suspicious WRITE output
   vibecrafted ship accept-dou <run_id> --finding "…"  # conscious, traced gap
   

   Dead worker recovery is always: interrupt → fallback --stage <stage> → approve [--force]. No baton cargo is lost.

6. Report at the end, not along the way (unless the operator asks otherwise): stages flown, corrections made, commits, gate colours, dou_index, and what release honestly did NOT verify.

Boundaries (what the human keeps)

• The baton is an agent↔agent relay; the supervising agent is the operator of the run. The human stays the human: mandates, pushes to the world, and merges are theirs unless explicitly delegated.
• Never merge your own PR without an explicit one-time mandate.
• "Production ready" is a forbidden verdict. Report evidence, file:line, gate colours; the release stage and the human own the verdict — honest outcomes like repo_contract_green_external_release_blocked beat a confident lie.

When To Use

• A mission needs the full cadence: discovery, delivery, adversarial review, entropy-up/entropy-down stabilization, DoU, and a release gate — as one supervised, auditable run.
• The operator says "ship it", "pełny lot", "parasol" for a scoped product cut in ANY repo (the runtime is repo-agnostic; the mission file names the root).

When NOT to use:

• A single cut with known shape → vc-implement or vc-justdo.
• Only stabilization → vc-marbles (then vc-polarize).
• Only discovery → vc-init / vc-research / vc-scaffold directly.

Pipeline Position

• Upstream: vc-operator (usual invoker), a scaffold-grade mission plan.
• Downstream: nothing — vc-ship IS the pipeline; its release stage emits the handoff (release report + DoU trail) the human acts on.

Acceptance Criteria

The skill run is done when:

• Lifecycle run reached release (or an operator-decided stop), with every transition traced in operator_actions.
• Every WRITE stage has verifiable commits + green gates; every READ stage is violation-free.
• dou_index is 0 — or every remaining gap is an explicit, traced accept-dou with its follow-up named.
• Final report delivered: stages, corrections, commits, gate colours, and what was NOT verified.

If any acceptance bullet cannot be ticked with evidence, the flight has not completed — say so explicitly in the final report.

Anti-Patterns

• Launching without a mission file grounded in vc-init truth (the prompt is a hypothesis, not the ground truth).
• Watching gates or workers from inside a subagent — gate-nap class failure (docs/runtime/AGENT_OPS.md, Class 1); watchers live with the supervisor.
• Trusting silence: a missing report is indistinguishable from a dead worker until you check liveness (Class 2) — use status/stage_worker, don't wait out budgets on a corpse.
• Manual edits to state.json instead of verbs — the trace IS the product.
• Approving a stage without reading its report, or pronouncing "ready" yourself instead of handing the verdict to the gate.

Examples

See examples/example-prompt.md for a minimal trigger phrase + expected behavior pair.

𝚅𝚒𝚋𝚎𝚌𝚛𝚊𝚏𝚝𝚎𝚍. with AI Agents by Vetcoders (c)2024-2026 LibraxisAI