autoship

name	autoship
description	Sequentially drain ready br issues or tk tickets through the existing ship chains with retry limits and progress state.

Autoship

Use this skill when working on /ef-autoship or /ef-autoship-tdd behavior.

Autoship is implemented as a prompt chain loop, not as a nested run-prompt orchestrator. The chain selects one ready item, ships it through the normal work/review/finalize path, then repeats until the selector reports no eligible ready work or all ready work is exhausted by retry limits.

Commands

• /ef-autoship [--max-retries N] runs the quick chain: ship-resolve -> ef-work -> ef-review-with-followups -> finalize
• /ef-autoship-tdd [--max-retries N] runs the TDD chain: ship-tdd-resolve -> spec -> implement -> validation-fix --loop 5 -> ef-review-with-followups -> finalize
• /ef-ship [<work-item-ref>|--next] [--max-retries N] uses the same quick chain.
• /ef-ship-tdd [<work-item-ref>|--next] [--max-retries N] uses the same TDD chain.

Selection

ship-resolve and ship-tdd-resolve own ready-work selection.

• Explicit work-item reference → resolve that item directly.
• Empty input, --next, or autoship options → call scripts/autoship-state.mjs next.
• Quick mode must pass --mode ship.
• TDD mode must pass --mode ship-tdd.
• Parse only --max-retries N; default is 2; reject non-integer, negative, or values greater than 20.

The helper records attempts in .execflow/autoship-progress.json and ensures .execflow/lessons-learned.md exists. --max-retries 2 means up to three total attempts per issue in one autoship run: one initial attempt plus two retries.

On next-ready dispatch, selector prompts must also write .pi/execflow-autoship-loop-marker.json using the write tool. This harmless marker is not tracker state; it exists because prompt-template loop convergence currently detects productive iterations through write/edit tool calls, while delegated subagent and shell mutations may report changed: false. Do not write this marker on stop results, so the no-work iteration still converges cleanly.

Stop behavior

When the selector returns status: stop, it must emit a no-work # Ship Selection result. Downstream chain steps must treat that as a clean no-op:

• no edits
• no validation/review commands
• no commits
• no tracker notes/comments
• no tracker closure

This no-op iteration lets the chain loop converge without relying on nested prompt dispatch.

Persisted validation gate

The TDD chain (ship-tdd-resolve -> spec -> implement -> validation-fix --loop 5 -> ef-review-with-followups -> finalize) can re-dispatch a work item whose implementation already exists. When that happens the /validation-fix transcript may not carry forward into the fresh-context /finalize step, and the finalizer used to return REVISE purely for lack of a visible Gate: PASS — burning retries and, on the last attempt, aborting.

To make closure resilient, /validation-fix persists its gate to .pi/execflow-validation-gate.json via scripts/validation-gate.mjs write (invoked through bash, so prompt-template loop convergence is unaffected), and /finalize consults it via scripts/validation-gate.mjs verify. The helper still reads legacy .execflow/validation-gate.json gates as a compatibility fallback. A persisted PASS gate is only closable when both the recorded commit and the source dirty-tree hash still match the current tree — i.e. the code being closed on is byte-identical to the code that was validated. The gate file is workflow state; never stage or commit it.

Both leaf prompts degrade gracefully: if the helper is missing or errors, they fall back to the in-transcript gate and the normal REVISE/BLOCKED rules, so the chain is never broken by a persistence failure.

What autoship must not do

• Do not call run-prompt from inside autoship.
• Do not inline a separate /ef-ship or /ef-ship-tdd command.
• Do not bypass the normal work/review/finalize chain.
• Do not mutate tracker state from selector prompts except through the existing progress file created by autoship-state.mjs; the .pi/execflow-autoship-loop-marker.json convergence marker is allowed because it is local prompt-loop state, not tracker state.
• Do not append routine status updates, raw transcripts, or duplicates to .execflow/lessons-learned.md.

Lessons learned

At the start of each selected work iteration, downstream steps may read .execflow/lessons-learned.md if it exists.

Append only durable, non-obvious lessons discovered from ship output. Before appending, scan existing entries and skip substantively identical lessons.