opencode-ship 1.1.8 → 1.1.9-rc.1

package/assets/commands/ship-deliver.md

@@ -1,11 +1,17 @@
 ---
-description: Start a delivery workflow. First checks the setup-pending marker, then dispatches the durable ship-controller through ship_deliver.
+description: Start a ship workflow. First checks the setup-pending marker, then dispatches the durable ship-controller through ship_deliver.
 ---
 
 # ship-deliver
 
 `ship-deliver <issue-number>` is the canonical entry point
-for a delivery workflow.
+for a ship workflow.
+
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
 
 ## Procedure
 
@@ -25,15 +31,20 @@ If the marker is present:
 
 If the marker is absent, continue.
 
+`ship_plan_start` runs stack skill sync before creating a workflow. Do not run the `skill-discovery` skill or `npx skills find` as a separate step.
+
 ### 1. Dispatch the controller
 
-Call `ship_deliver` with the issue number. Do not implement the issue through the legacy `delivery_issue` / `delivery_worktree` / `delivery_pr` path.
+Call `ship_deliver` with the issue number. Do not implement the issue through Build-owned `ship_issue` / `ship_worktree` / `ship_pr` calls.
 
 1. Check setup-pending.
 2. Call `ship_deliver(issueNumber)`.
 3. Surface the controller session and `wf-<issue>` workflow id.
-4. Await the explicit plan approval prompt.
-5. Resume only through `ship-controller`.
+4. After issue ensure, print `Track: issue #<number>.`
+5. Await the explicit plan approval prompt.
+6. Resume only through `ship-controller`. After each successful
+   tool, print the matching `progressLine` as a normal chat
+   sentence. Do not wrap in JSON. Do not explain the stage.
 
 ### 2. Plan + approve
 
@@ -41,15 +52,16 @@ The controller starts or resumes durable workflow state, dispatches the planner,
 
 ### 3. Execute
 
-The controller drives each task through the cheap builder, task reviewer, commit binding, and same-HEAD Standards + Spec + verifier + required CI gates.
+The controller drives each task through the cheap builder, task reviewer, commit binding, and same-HEAD Standards + Spec + verifier + required CI gates. Print `Build: task <k>/<n> <title>.` and `Review: pass.` or `Review: fail (see notes).` per task, then `Verify: pass.` or `Verify: fail.` once.
 
 ### 4. Ready
 
-Stop at Ready. Surface PR URL, worktree path, verifier SHA, and the explicit-merge instruction.
+Stop at Ready. Print `Ready: PR #<number>.` Surface PR URL, worktree path, verifier SHA, and the explicit-merge instruction.
 
 ### 5. Merge
 
 On explicit `merge it`: fresh gate recheck, squash merge, and cleanup.
+Print `Merge: <sha>.` then `Cleanup: done.`
 
 ## Hard rules
 
@@ -57,8 +69,8 @@ On explicit `merge it`: fresh gate recheck, squash merge, and cleanup.
 - **Never auto-approve a plan.** The user always reviews the plan.
 - **Never mark Ready or merge without a passing Standards review, a passing Spec review, a passing verifier run, and a passing required-CI check, all bound to one HEAD.**
 - **Never force-push, hard-reset, stash, or `git worktree remove`.**
-- **Never use `gh api` or raw shell on GitHub.** Use the typed `delivery_*` tools.
-- **Never abandon an attempt without an explicit user request after the PR is closed unmerged.** The controller may then call `delivery_abandon`.
+- **Never use `gh api` or raw shell on GitHub.** Use the typed `ship_*` tools.
+- **Never abandon an attempt without an explicit user request after the PR is closed unmerged.** The controller may then call `ship_abandon`.
 
 ## Stop conditions
 

package/assets/defaults/workflow-models.history.json

@@ -0,0 +1,7 @@
+[
+  {
+    "planner": "openai/gpt-5.6-sol",
+    "builder": "minimax/MiniMax-M3",
+    "finalReviewer": "openai/gpt-5.6-sol"
+  }
+]

package/assets/defaults/workflow-models.json

@@ -0,0 +1,5 @@
+{
+  "planner": "openai/gpt-5.6-sol",
+  "builder": "minimax-coding-plan/MiniMax-M3",
+  "finalReviewer": "openai/gpt-5.6-sol"
+}

package/assets/skills/brainstorming/SKILL.md

@@ -9,6 +9,12 @@ Help turn ideas into fully formed designs and specs through natural collaborativ
 
 Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
 
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
+
 <HARD-GATE>
 Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
 </HARD-GATE>
@@ -22,7 +28,7 @@ Every project goes through this process. A todo list, a single-function utility,
 You MUST create a task for each of these items and complete them in order:
 
 1. **Explore project context** — check files, docs, recent commits
-2. **Offer the visual companion just-in-time** — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.
+2. **Visual companion** — do not offer unless the user asked for a mockup. See the Visual Companion section below.
 3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
 4. **Propose 2-3 approaches** — with trade-offs and your recommendation
 5. **Present design** — in sections scaled to their complexity, get user approval after each section
@@ -128,17 +134,14 @@ Wait for the user's response. If they request changes, make them and re-run the
 
 **Implementation:**
 
-- Invoke the writing-plans skill to create a detailed implementation plan
+- After spec approval, invoke the writing-plans skill. Do not ask which skill to use.
 - Do NOT invoke any other skill. writing-plans is the next step.
 
 ## Visual Companion
 
 A browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.
 
-**Offering the companion (just-in-time):** Do NOT offer it upfront. Wait until a question would genuinely be clearer shown than told — a real mockup / layout / diagram question, not merely a UI *topic*. The first time that happens, offer it then, as its own message:
-> "This next part might be easier if I show you — I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you."
-
-**This offer MUST be its own message.** Only the offer — no clarifying question, summary, or other content. Wait for the user's response. If they accept, start the server with `--open` so their browser opens to the first screen automatically. If they decline, continue text-only and don't offer again unless they raise it.
+**Offering the companion:** Do not offer unless the user asked for a mockup. If they did, start the server with `--open` so their browser opens to the first screen automatically. Never upsell it.
 
 **Per-question decision:** Even after the user accepts, decide FOR EACH QUESTION whether to use the browser or the terminal. The test: **would the user understand this better by seeing it than reading it?**
 
@@ -157,4 +160,4 @@ This skill is part of the engineering profile shipped by
 Ship controller; the cheap builder (`minimax/MiniMax-M3`) cannot
 commit, push, mutate GitHub, mark Ready, or merge. The
 verification-before-completion rule is enforced by
-`delivery_verify`, not by the model self-asserting completion.
+`ship_verify`, not by the model self-asserting completion.

package/assets/skills/dispatching-parallel-agents/SKILL.md

@@ -173,4 +173,4 @@ This skill is part of the engineering profile shipped by
 Ship controller; the cheap builder (`minimax/MiniMax-M3`) cannot
 commit, push, mutate GitHub, mark Ready, or merge. The
 verification-before-completion rule is enforced by
-`delivery_verify`, not by the model self-asserting completion.
+`ship_verify`, not by the model self-asserting completion.

package/assets/skills/engineering-workflow/SKILL.md

@@ -13,7 +13,13 @@ Scaffold the per-repo configuration that the engineering skills assume:
 - **Triage labels** — the strings used for the five canonical triage roles
 - **Domain docs** — where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
 
-This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write.
+This is a prompt-driven skill, not a deterministic script. Explore, then write. Do not ask how to run the work.
+
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
 
 ## Process
 
@@ -38,9 +44,9 @@ Lead each section with the recommended answer so the user can accept it in a wor
 
 **Section A — Issue tracker.**
 
-> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-tickets`, `triage`, `to-spec`, and `qa` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
+> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-tickets`, `triage`, `to-spec`, and `qa` read from and write to it — they need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe.
 
-Default posture: these skills were designed for GitHub. If a `git remote` points at GitHub, propose that. If a `git remote` points at GitLab (`gitlab.com` or a self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:
+If a `git remote` points at GitHub, write the GitHub tracker without asking. If a `git remote` points at GitLab (`gitlab.com` or a self-hosted host), propose GitLab. Otherwise offer:
 
 - **GitHub** — issues live in the repo's GitHub Issues (uses the `gh` CLI)
 - **GitLab** — issues live in the repo's GitLab Issues (uses the [`glab`](https://gitlab.com/gitlab-org/cli) CLI)
@@ -76,7 +82,7 @@ Let them edit before writing.
 
 - If `CLAUDE.md` exists, edit it.
 - Else if `AGENTS.md` exists, edit it.
-- If neither exists, ask the user which one to create — don't pick for them.
+- If neither exists, create `AGENTS.md` without asking.
 
 Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa) — always edit the one that's already there.
 

package/assets/skills/executing-plans/SKILL.md

@@ -1,73 +1,28 @@
 ---
 name: executing-plans
-description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
+description: Hand an approved implementation plan to ship_deliver. Use when the user opens a new chat and says implement this plan. Never implement or commit in this session.
 ---
 
 # Executing Plans
 
-## Overview
+This skill does not implement. It starts Ship.
 
-Load plan, review critically, execute all tasks, report when complete.
+Never ask how to run the work: no Subagent vs Inline, no Tab vs Build,
+no GitHub issues vs Task N, no "what next".
+Never commit. Never push. Never edit source. Never work on `main`.
 
-**Announce at start:** "I'm using the executing-plans skill to implement this plan."
+## Procedure
 
-**Note:** Tell your human partner that Superpowers works much better with access to subagents (Claude Code, Codex CLI, Codex App, Copilot CLI, and Gemini CLI all qualify; see the per-platform tool refs in `../using-superpowers/references/`). If subagents are available, use superpowers:subagent-driven-development instead of this skill.
+1. Read the plan path the user named, or the latest `.opencode/plans/*.md`.
+2. Print `Plan: <path>`.
+3. Ensure a GitHub issue exists: call `ship_issue` with
+   `title` from the plan heading, `body` containing the plan path,
+   `baseBranch` from `.opencode/ship.config.json` `project.defaultBranch`,
+   `branch` `fix/<slug-from-title>`, `taskId` a slug from the title.
+   Print `Track: issue #N.`
+4. Call `ship_deliver` with that `issueNumber`. Print its `progress`
+   and `next` lines so the user sees the stage.
+5. Stop. The controller prints Build / Review / Verify / Ready.
 
-## The Process
-
-### Step 1: Load and Review Plan
-1. Ensure an isolated workspace: use superpowers:using-git-worktrees to create one or verify the existing one
-2. Read plan file
-3. Review critically - identify any questions or concerns about the plan
-4. If concerns: Raise them with your human partner before starting
-5. If no concerns: Create todos for the plan items and proceed
-
-### Step 2: Execute Tasks
-
-For each task:
-1. Mark as in_progress
-2. Follow each step exactly (plan has bite-sized steps)
-3. Run verifications as specified
-4. Mark as completed
-
-### Step 3: Complete Development
-
-After all tasks complete and verified:
-- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
-- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
-- Follow that skill to verify tests, present options, execute choice
-
-## When to Stop and Ask for Help
-
-**STOP executing immediately when:**
-- Hit a blocker (missing dependency, test fails, instruction unclear)
-- Plan has critical gaps preventing starting
-- You don't understand an instruction
-- Verification fails repeatedly
-
-**Ask for clarification rather than guessing.**
-
-## When to Revisit Earlier Steps
-
-**Return to Review (Step 1) when:**
-- Partner updates the plan based on your feedback
-- Fundamental approach needs rethinking
-
-**Don't force through blockers** - stop and ask.
-
-## Remember
-- Review plan critically first
-- Follow plan steps exactly
-- Don't skip verifications
-- Reference skills when plan says to
-- Stop when blocked, don't guess
-- Never start implementation on main/master branch without explicit user consent
-
-## Ship integration
-
-This skill is part of the engineering profile shipped by
-`opencode-ship@1.0`. Execution is driven by the deterministic
-Ship controller; the cheap builder (`minimax/MiniMax-M3`) cannot
-commit, push, mutate GitHub, mark Ready, or merge. The
-verification-before-completion rule is enforced by
-`delivery_verify`, not by the model self-asserting completion.
+If `ship_deliver` is missing, stop and say so. Do not fall back to
+local commits or subagent-driven-development.

package/assets/skills/planning-research-checkpoint/SKILL.md

@@ -1,12 +1,21 @@
 ---
 name: planning-research-checkpoint
-description: Offers a single, optional Deep Research gate before non-trivial plans proceed to implementation. Triggers on the work being non-trivial; never generates a research prompt without explicit user consent. Use when the parent agent has finished the plan-mode brief and the work touches architecture, lifecycle design, or an unfamiliar domain.
+description: Optional Deep Research gate before non-trivial plans proceed to implementation. Default is no research. Run research only if the user said "research" or "istrazi". Use when the parent agent has finished the plan-mode brief and the work touches architecture, lifecycle design, or an unfamiliar domain.
 ---
 
 # planning-research-checkpoint
 
 You trigger exactly once per non-trivial planning session. Trivial sessions (typo fixes, docstring changes, single-file edits, follow-up PRs on already-decided work) skip this gate silently.
 
+Default is no research. Do not ask “Run Deep Research?”.
+Run research only if the user said “research” / “istrazi”.
+
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
+
 ## When you trigger
 
 - The plan touches architecture, lifecycle, API surface, or test strategy
@@ -23,19 +32,13 @@ Do **not** trigger on:
 ## Procedure
 
 1. Read the current session's plan from the parent context. Do **not** ask the user to re-state it.
-2. **Ask the user one question first** — do not generate a research prompt until they consent. Use exactly this wording:
-   > This looks non-trivial. Run Deep Research before continuing? **[yes / no]**
-3. If the answer is **no**:
-   - Proceed with the plan as written.
-   - Do not mention the offer again this session.
-   - Do not generate any research prompt — the explicit goal is to save the user's tokens.
-4. If the answer is **yes**:
+2. If the user did not say “research” or “istrazi”, proceed with the plan as written. Do not mention research. Do not generate any research prompt.
+3. If the user said “research” or “istrazi”:
    - Output a single Markdown block titled "Research checkpoint" containing:
      - The plan summary in <= 3 bullets
      - A **one-line** decision the research is meant to inform
      - A draft Deep Research prompt in a copyable ```text fenced block
-   - Ask the user one question: "Run the research, or proceed without?"
-   - Wait for the result. Persist a concise dated summary into the consumer project's `docs/research/` only if the research materially shapes an ADR or other architectural decision; otherwise treat the result as session-local.
-5. Never ask the user to formulate the prompt themselves. The draft is yours to write when consent is given.
-6. Never loop. One offer, one outcome, continue.
-7. Never persist the full research output. The summary you write must be yours, dated, and bounded.
+   - Run the research. Wait for the result. Persist a concise dated summary into the consumer project's `docs/research/` only if the research materially shapes an ADR or other architectural decision; otherwise treat the result as session-local.
+4. Never ask the user to formulate the prompt themselves. The draft is yours to write when they asked to research.
+5. Never loop. One outcome, continue.
+6. Never persist the full research output. The summary you write must be yours, dated, and bounded.

package/assets/skills/receiving-code-review/SKILL.md

@@ -211,4 +211,4 @@ This skill is part of the engineering profile shipped by
 Ship controller; the cheap builder (`minimax/MiniMax-M3`) cannot
 commit, push, mutate GitHub, mark Ready, or merge. The
 verification-before-completion rule is enforced by
-`delivery_verify`, not by the model self-asserting completion.
+`ship_verify`, not by the model self-asserting completion.

package/assets/skills/requesting-code-review/SKILL.md

@@ -101,4 +101,4 @@ This skill is part of the engineering profile shipped by
 Ship controller; the cheap builder (`minimax/MiniMax-M3`) cannot
 commit, push, mutate GitHub, mark Ready, or merge. The
 verification-before-completion rule is enforced by
-`delivery_verify`, not by the model self-asserting completion.
+`ship_verify`, not by the model self-asserting completion.

package/assets/skills/setup-ship-workflow/SKILL.md

@@ -11,17 +11,23 @@ and before any `ship-deliver`. It is prompt-driven, idempotent, and refuses
 to return until every step is committed or explicitly skipped.
 
 The setup contract is GitHub-only. The skill refuses to drive GitLab,
-Jira, Linear, or local markdown because the controller's own delivery
+Jira, Linear, or local markdown because the controller's own ship
 tool belt is GitHub-bound. A team that needs a different tracker should
 hold off on `opencode-ship@1.1.2` until 1.2 ships the next tracker.
 
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
+
 ## When you trigger
 
 - The user runs `/setup-ship-workflow` or types "set up ship" / "continue setup".
 - The installer creates `.opencode/ship.setup-pending.json` after `init`.
 - The controller also routes `ship-deliver` to this skill until the marker is cleared.
 
-Do **not** trigger on a normal planning or delivery request.
+Do **not** trigger on a normal planning or ship request.
 
 ## Process
 
@@ -51,9 +57,9 @@ Also check:
 
 ### 2. Section A — GitHub repository
 
-The default is the GitHub repository that owns `git remote`. Confirm the
-detected `owner/repo` slug against the user's answer. If the user has
-multiple remotes, ask which one is the ship target.
+If `git remote` is GitHub, write the GitHub tracker without asking,
+using the detected `owner/repo` slug. If the user has multiple remotes,
+ask which one is the ship target.
 
 Write `docs/agents/issue-tracker.md` with the resolved `owner/repo`,
 `default branch`, and the canonical `gh` commands:
@@ -95,44 +101,32 @@ Write `docs/agents/domain.md`.
 
 ### 5. Section D — AI model roles
 
-Three questions, one at a time. Default to `openai/gpt-5.6-sol` and
-`minimax/MiniMax-M3`; offer alternative families only when the user
-explicitly states they have no credentials for the defaults.
+`init` already filled `workflow.models` from packaged defaults. Do not
+ask the user to type three ids. Ask only whether they want an override.
 
-| Role | Default | Suggestion |
+| Role | Packaged default | Suggestion |
 |---|---|---|
 | planner | `openai/gpt-5.6-sol` | strong model for plan writing |
-| builder | `minimax/MiniMax-M3` | cheap/fast model for code |
+| builder | `minimax-coding-plan/MiniMax-M3` | cheap/fast model for code |
 | finalReviewer | `openai/gpt-5.6-sol` | strong model for final Standards + Spec review |
 
+If the user keeps the defaults, leave `workflow.models` unchanged.
+CLI `--planner-model` / `--builder-model` / `--final-reviewer-model`
+mark that role as an override in the lock. To override later, edit
+`.opencode/ship.config.json` or run `opencode-ship update` with those
+flags (do not use `--force-config` just to change a model id).
+
 Alternatives to mention if the user has no OpenAI/MiniMax:
 
 - Anthropic: `anthropic/claude-opus-4.1`, `anthropic/claude-sonnet-4.5`
 - Google: `google/gemini-2.5-pro`, `google/gemini-2.5-flash`
 - Or any `<provider>/<model>` string the user has credentials for
 
-After the user answers, update `.opencode/ship.config.json`:
-
-```json
-{
-  "schemaVersion": 2,
-  "profile": "engineering",
-  "project": { ... },
-  "delivery": { ... },
-  "workflow": {
-    "models": {
-      "planner": "<answer>",
-      "builder": "<answer>",
-      "finalReviewer": "<answer>"
-    },
-    "approval": { "mirrorToIssue": true, "maxFailedRounds": 3 }
-  }
-}
-```
+If they choose an override, run:
 
-Then run `opencode-ship update --planner-model <a> --builder-model <b>
---final-reviewer-model <c> --force-config` to write the change with full
-transactional coverage.
+```
+opencode-ship update --planner-model <a> --builder-model <b> --final-reviewer-model <c>
+```
 
 ### 6. Section E — Provider auth probe
 
@@ -169,7 +163,7 @@ Pick the file to edit:
 
 - If `CLAUDE.md` exists, edit it.
 - Else if `AGENTS.md` exists, edit it.
-- If neither, ask the user to pick one — never create both.
+- If neither exists, create `AGENTS.md` without asking.
 
 If an `## Ship workflow` block exists, update in place. Otherwise append:
 
@@ -181,7 +175,7 @@ active model roles and approval policy. Issues live in GitHub.
 See `docs/agents/issue-tracker.md`. Triage labels are documented in
 `docs/agents/triage-labels.md`.
 
-For a single-issue delivery, the user invokes `/setup-ship-workflow`
+For a single-issue ship, the user invokes `/setup-ship-workflow`
 once, then `ship-deliver <issue-number>` (or types "Ship issue N"). The
 controller dispatches the planner, builder, and reviewers; no further
 user action is required until Ready.

package/assets/skills/{delivery-workflow → ship-workflow}/SKILL.md

@@ -1,15 +1,24 @@
 ---
-name: delivery-workflow
-description: Orchestrates the canonical delivery lifecycle from issue creation through Ready PR. Use when the user asks for "implement issue N", "work on ready issues", "delivery", "autonomous delivery", or after a plan-mode session confirms the work scope.
+name: ship-workflow
+description: Orchestrates the canonical ship lifecycle from issue creation through Ready PR. Use when the user asks for "implement issue N", "work on ready issues", "ship", "implement this plan", "execute the plan", "ok implement", or after a plan-mode session confirms the work scope.
 ---
 
-# delivery-workflow
+# ship-workflow
 
 You drive the opencode-ship package from a one-line user request to a green, conflict-free, ready-to-merge pull request by dispatching the durable controller.
 
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
+
 ## When you trigger
 
 - "Implement issue N", "work on issue N", "deliver issue N"
+- "implement this plan"
+- "execute the plan"
+- "ok implement"
 - "Pick the next ready issue and implement it"
 - "Open a PR for #N"
 - "Mark PR #N ready"
@@ -26,28 +35,45 @@ Do **not** trigger on:
 
 | Step | Tool | Notes |
 |---|---|---|
-| 1. Cleanup merged worktrees | `delivery_inspect` / `delivery_cleanup` | Only for provably merged attempts |
+| 1. Cleanup merged worktrees | `ship_inspect` / `ship_cleanup` | Only for provably merged attempts |
 | 2. Setup gate | `/ship-deliver` | Refuse if `.opencode/ship.setup-pending.json` exists |
 | 3. Dispatch controller | `ship_deliver` | Canonical Build-to-controller entrypoint |
 | 4. Plan + approve | controller / `ship_plan_approve` | Never auto-approve |
 | 5. Execute in linked worktree | controller | Builder, task review, commit, verifier, CI, dual-axis final review |
-| 6. Ready | `delivery_ready` | Controller-owned; same-HEAD gates required |
+| 6. Ready | `ship_ready` | Controller-owned; same-HEAD gates required |
 | 7. Stop at Ready | (this skill) | Do not merge without an explicit user request |
-| 8. Merge | `delivery_merge` | Explicit user request only |
-| 9. Cleanup | `delivery_cleanup` | After a successful merge |
-| 10. Abandon closed unmerged attempts | `delivery_abandon` | Only after the user explicitly closes the PR and requests abandon |
+| 8. Merge | `ship_merge` | Explicit user request only |
+| 9. Cleanup | `ship_cleanup` | After a successful merge |
+| 10. Abandon closed unmerged attempts | `ship_abandon` | Only after the user explicitly closes the PR and requests abandon |
+
+Do not call `ship_worktree`, `ship_pr`, `ship_ready`, or `ship_merge` from Build to implement an issue. Those mutations belong to `ship-controller` after `ship_deliver`.
+
+## Progress
+
+After each successful tool in the lifecycle, print the matching
+`progressLine` as a normal chat sentence. Do not wrap in JSON. Do not
+explain the stage.
+
+- Track: after issue ensure — `Track: issue #<number>.`
+- Build: per task — `Build: task <k>/<n> <title>.`
+- Review: per task — `Review: pass.` or `Review: fail (see notes).`
+- Verify: once — `Verify: pass.` or `Verify: fail.`
+- Ready — `Ready: PR #<number>.`
+- Merge — `Merge: <sha>.`
+- Cleanup — `Cleanup: done.`
 
-Do not call `delivery_worktree`, `delivery_pr`, `delivery_ready`, or `delivery_merge` from Build to implement an issue. Those mutations belong to `ship-controller` after `ship_deliver`.
+`shape` and `approve` have no line. Use `progressLine` from
+`src/runtime/stages.js`.
 
 ## Hard rules
 
 1. Every PR carries a `Closes #N` reference. If the issue does not exist, the controller creates it first.
-2. The lifecycle stops at Ready by default. An explicit "merge it" is the only thing that triggers `delivery_merge`.
+2. The lifecycle stops at Ready by default. An explicit "merge it" is the only thing that triggers `ship_merge`.
 3. Force-push, hard-reset, stash, and `git worktree remove` are denied. Use typed cleanup/abandon tools.
 4. You never edit `main` directly. You never bypass the reviewer/verifier gates.
 5. The typed tools are the only sanctioned way to mutate GitHub state. Do not invoke `gh pr merge`, `gh api`, or raw Git plumbing directly.
 6. When a gate fails, fix the cause and re-run only the failed gate; never skip.
-7. If `delivery_merge` returns a `MergeError`, surface it verbatim. Do not invent a workaround.
+7. If `ship_merge` returns a `MergeError`, surface it verbatim. Do not invent a workaround.
 
 ## Stop conditions