ship

name	ship
description	Use when the user asks to run the whole AFK flow, ship a feature, take work from idea or plan to verified evidence, resume an AFK workflow, or make a final ship/no-ship call across planning, implementation, cleanup, and QA

Ship

Drive AFK's existing skills to an evidence-backed verdict. This skill orchestrates afk:grill, afk:implement, afk:simplify, afk:review, and afk:qa without replacing their detailed instructions.

Core principle: do not claim something can ship until the relevant AFK phase artifacts exist or are deliberately skipped with a reason.

When to Use

Use this skill when:

• The user asks to run the full AFK loop, ship something, or take a feature from idea, prompt, or plan to verified evidence.
• The user wants to resume a partly completed AFK workflow and needs the next phase chosen from repo state.
• The user asks for one command that plans when needed, implements, cleans up, and QA-checks the result.

Do not use this skill for:

• A specific phase request such as "grill me", "implement this plan", "simplify the diff", or "QA this"; use that named skill directly.
• PR creation, branch management, release notes, or deployment monitoring. AFK Ship stops at verified local evidence plus a brain reflection; it does not push, deploy, or manage releases.

Process

Always track the run with the TodoWrite tool. As soon as the route is chosen (steps 1–2), write one todo per phase that will actually run — skipped phases are omitted — and keep it updated: mark the active phase in_progress and each finished phase completed before starting the next. The list gives the user a live view of the flow, for example:

◼ Implement vim-trainer MVP via orchestrator
◻ Simplify implementation diff
◻ Review diff (afk:review)
◻ QA behavior (afk:qa)
◻ Reflect learnings (afk:reflect)

1. Inspect current state before routing.

   • Read the user's request, git status --short, git diff --stat, available plans (brain/plans/ from afk:grill and afk:plan), and available qa/ reports.
   • If the user supplied a plan path, use that plan as the source of truth. Do not route back to afk:grill merely because the plan is terse; ask only when a specific missing decision blocks implementation.
   • If the user asks to resume, treat existing plans, diffs, and QA reports as possible progress, not as proof until checked.
   • If the user explicitly asks only for the route, a dry run, or eval-mode explanation, do not invoke child AFK skills. Report the route and gates using the output shape below.

2. Choose the planning route.

   • If a plan path was supplied or one relevant plan clearly matches the work, read it and continue to implementation.
   • If the work is small, local, and already clear enough to implement, skip afk:grill and record that planning was skipped because the scope is clear.
   • If product intent, contracts, edge cases, glossary terms, or source of truth are unresolved, invoke afk:grill and use its brain/plans/<slug>.md output before implementation.

3. Run or resume implementation.

   • Invoke afk:implement for repo-changing work, passing the selected plan path or clear prompt.
   • If a working-tree diff already exists, inspect it before implementing and continue from the current state instead of restarting.
   • Do not accept implementation as complete until relevant verification was run or the skip reason is explicit.

4. Run cleanup when useful.

   • Invoke afk:simplify when the implementation diff is meaningful and non-mechanical.
   • Skip simplify only for tiny, mechanical, generated, formatting-only, or documentation-only changes, and say why.

5. Review before QA.

   • Invoke afk:review on the implementation diff to get a principle-grounded, no-changes read before behavioral verification. Run it after simplify so review judges the cleaned-up diff.
   • Review only diagnoses; it never edits. If review returns Revise (high-severity findings), loop back to afk:implement or afk:simplify to resolve them before QA, or carry the unresolved findings as a caveat or . Do not advance to QA pretending high-severity findings are absent.

Stop and Ask

STOP and ask the user when:

• More than one plan could plausibly own the requested work and repo state does not identify the right one.
• Continuing would require product intent, credentials, paid services, destructive actions, or external state that the repo does not provide.
• The user wants PR creation, deployment, or release management; that is outside AFK Ship's v1 scope.

Do not ask about facts discoverable from plans, diffs, docs, tests, or QA artifacts.

Red Flags

Thought	Reality
"Ship should copy the other skills so it is self-contained."	Ship is an orchestrator. Load the phase skill that owns the detailed work.
"There is a QA report, so QA is done."	Reuse it only if it still matches the current diff and requested behavior.
"Tests passed, so the final verdict is SHIP."	Tests are verification. Behavior-bearing work still needs afk:qa evidence.
"The work is almost done, so report success."	Missing phase evidence is a caveat or blocker, not success.

Output

Return this compact shape:

Verdict: SHIP | DO NOT SHIP | SHIP WITH CAVEATS
Route: grill skipped/used -> implement -> simplify skipped/used -> review skipped/used -> qa skipped/used -> reflect skipped/used
Plan: brain/plans/<slug>.md or "none, reason"
Changed: <files or summary>
Verification: <commands/results>
Review: accept | accept with notes | revise, or "skipped, reason"
QA: qa/<slug>.md or "skipped, reason"
Memory: <brain files written/updated, or "skipped, reason">
Caveat: <one sentence, only if needed>

If the work stops before a final verdict, report the current phase, exact blocker, and the next AFK skill to run.