Menu
Sequentially drain ready br issues or tk tickets through the existing ship chains with retry limits and progress state.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Update a work item with a concise execution note and close it only when validation and review evidence prove the acceptance criteria. Use for prompts that finalize work-item status after manual execution chains.
Review work items, ExecPlan delivery, or arbitrary code changes with evidence-backed findings. Reviews are read-only by default and create tracker follow-ups only when explicitly requested with --create-followups.
Implement or fix a work item using minimal diffs while preserving scope, local conventions, and testability. Use for prompts that change code or apply validation/review fixes.
Validate work-item changes using concrete evidence, exact commands, and explicit gap reporting. Use for validation prompts and review passes that audit proof.
Create a self-contained ExecPlan from a brainstorm artifact and/or a user brief. Follows the project's .execflow/PLANS.md spec. Applies the Ousterhout design lens. Use when creating execution plans, turning ideas into implementable steps, or wants a PRD/RFC/brainstorm turned into a step-by-step plan.
Convert an ExecPlan's milestones into tracked work items, automatically selecting tk tickets or br issues from repo context unless the user forces a tracker with --tk or --br. Use when the user wants one entrypoint that works across both tracker backends.
| name | autoship |
| description | Sequentially drain ready br issues or tk tickets through the existing ship chains with retry limits and progress state. |
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.
/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.ship-resolve and ship-tdd-resolve own ready-work selection.
--next, or autoship options → call scripts/autoship-state.mjs next.--mode ship.--mode ship-tdd.--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.
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:
This no-op iteration lets the chain loop converge without relying on nested prompt dispatch.
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.
run-prompt from inside autoship./ef-ship or /ef-ship-tdd command.autoship-state.mjs; the .pi/execflow-autoship-loop-marker.json convergence marker is allowed because it is local prompt-loop state, not tracker state..execflow/lessons-learned.md.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.