메뉴
Sequentially drain ready br issues or tk tickets through the existing ship chains with retry limits and progress state.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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.
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.