opencode-ship 1.1.8 → 1.1.9-rc.1

package/assets/skills/skill-discovery/SKILL.md

@@ -1,104 +1,32 @@
 ---
 name: skill-discovery
-description: Discover and conditionally install skills from the open agent skills ecosystem before non-trivial work. Use when the parent agent is starting a new task and wants to ensure the most relevant public skills (React, testing, deployment, etc.) are available to the cheap builder.
+description: Documentation for automatic stack skill discovery. Discovery runs inside init and ship_plan_start via syncSkills; do not treat this skill as a step the model must remember.
 ---
 
 # skill-discovery
 
-Discover skills from the open agent skills ecosystem (`npx skills`) that match the current task objective, then install the trusted ones locally. The hard rule is that this skill is **suggest-first, install-conditionally**: trusted sources may auto-install; everything else must be approved by the user.
+Trusted stack skills are discovered and installed by `syncSkills`, not by remembering to run `npx skills find`. `init` runs the pipeline after a successful commit. `ship_plan_start` runs the same pipeline before creating a workflow, so discovery cannot be skipped.
 
-## When you trigger
+This skill is documentation only. Do not run a separate discovery pass unless the user asks.
 
-- The parent agent (typically `ship-deliver` or `ship-task-builder`) is about to dispatch a new task.
-- The task objective references a domain where a public skill likely exists (web frameworks, testing, deployment, design, etc.).
-- The user has not yet opted out of skill discovery for this session.
+## What the pipeline does
 
-Do **not** trigger on:
+1. Map `package.json` dependencies to 1–5 short queries (`react`, `nextjs`, `vitest`, …).
+2. On `ship_plan_start`, append extra queries from issue text without replacing the stack.
+3. Query the public skills registry and partition with `isAutoInstallable`.
+4. Auto-install trusted owners (`vercel-labs`, `anthropics`, `obra`, `mattpocock`, `ComposioHQ`) with `minInstalls >= 1000`, max 5 per pass, into `.opencode/skills/<name>/`.
+5. Skip untrusted owners, managed-skill name collisions, existing destinations, and policy rejects.
 
-- Trivial edits, doc rewrites, single-line fixes
-- Tasks that are already covered by a vendored skill from the engineering catalog
+## Untrusted candidates
 
-## Procedure
-
-### 1. Extract a discovery query
-
-From the current task brief (interfaces, files, technology stack), build one short query string (2–5 words). Example: `react testing`, `docker deploy`, `postgres migrations`, `tailwind components`.
-
-### 2. Search the skills ecosystem
-
-```bash
-npx skills find "<query>"
-```
-
-The CLI returns candidates with source repo, install count, and skill name. Parse the output, do not transcribe it.
-
-### 3. Score and filter
-
-The install allowlist and quality threshold live in `ship.config.json` under `skillDiscovery`:
-
-```json
-{
-  "skillDiscovery": {
-    "trustedOwners": [
-      "vercel-labs",
-      "anthropics",
-      "obra",
-      "mattpocock",
-      "ComposioHQ"
-    ],
-    "minInstalls": 1000,
-    "blocklist": ["known-bad-owner/example"]
-  }
-}
-```
-
-**Auto-install** is allowed only if all of the following are true:
-
-- source owner is in `trustedOwners`
-- install count >= `minInstalls` (default 1000)
-- skill name does not conflict with a managed `opencode-ship` skill
-- the user has not previously blocked this skill in this repo
-
-Otherwise:
-
-- If the source is untrusted but the skill looks relevant, present 1–3 candidates to the user and wait for a yes/no.
-- If no candidates match, continue without installation.
-
-### 4. Install project-locally
-
-Auto-approved candidates install to `.opencode/skills/<skill>/SKILL.md` (project-local). The typed tool `ship_skill_install` records every install in the run ledger so `doctor` and `uninstall` can audit it.
-
-Manual install if the user prefers global:
-
-```bash
-npx skills add <owner/repo@skill> -g -y
-```
-
-Prefer project-local unless the user explicitly asks for global.
-
-### 5. Report
-
-After discovery, emit a one-line summary in the run:
-
-```text
-Skill discovery: <n> candidates, <m> installed (<owner/skill list>).
-```
-
-If 0 installed, say `Skill discovery: 0 installed, continuing with catalog skills only.`
+- `init`: print untrusted package/skill names; do not wait.
+- `ship_plan_start`: return them on the success envelope as `skills.skippedUntrusted`. Ask the user yes/no before any extra install.
 
 ## Hard rules
 
-- Never run `npx skills add` for an untrusted source without explicit user approval.
-- Never install a skill that shadows a managed opencode-ship skill (name collision).
-- Never run discovery when offline or when the registry is unreachable. Warn and continue.
+- Never auto-install an untrusted owner.
+- Never shadow a managed opencode-ship skill.
+- Never overwrite an existing `.opencode/skills/<name>` directory.
 - Never install more than 5 skills in one discovery pass.
-- Never persist discovery results to `ship.config.json`. The discovery is per-task, not per-repo.
-
-## Permissions
-
-This skill expects the following bash allowances on the host (configured in `ship-controller` frontmatter):
-
-- `npx skills find *`
-- `npx skills add *`
-- `ls .opencode/skills`
-- `cat .opencode/skills/*/SKILL.md`
+- Registry / `skills` CLI failure is a warning. Continue with catalog skills only.
+- Prefer project-local `.opencode/skills` unless the user explicitly asks for `~/.config/opencode`.

package/assets/skills/subagent-driven-development/SKILL.md

@@ -1,10 +1,14 @@
 ---
 name: subagent-driven-development
-description: Use when executing implementation plans with independent tasks in the current session
+description: Do not use when opencode-ship is installed. Use ship_deliver. (Upstream Superpowers executor; ship consumers must not run it.)
 ---
 
 # Subagent-Driven Development
 
+If this repo has `.opencode/plugins/opencode-ship.js`, do not use this
+skill. Call `ship_deliver` (via executing-plans / ship-workflow)
+instead. Never implement or commit in the current session.
+
 Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.
 
 **Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
@@ -509,4 +513,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/systematic-debugging/SKILL.md

@@ -289,4 +289,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/test-driven-development/SKILL.md

@@ -326,4 +326,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/verification-before-completion/SKILL.md

@@ -126,4 +126,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/wayfinder/SKILL.md

@@ -6,6 +6,12 @@ disable-model-invocation: true
 
 A loose idea has arrived — too big for one agent session, and wrapped in fog: the way from here to the **destination** isn't visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a **shared map** on the repo's issue tracker, then works its **decision tickets** — questions whose resolution is a decision, not slices of a build to execute — one at a time until the route is clear.
 
+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.
+
 The destination varies per effort, and naming it is the first act of charting — it shapes every ticket. It might be a spec to hand off and iterate on, a decision to lock before planning starts, or a change made in place like a data-structure migration. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
 
 ## Plan, don't do
@@ -109,7 +115,7 @@ Two modes. Either way, **never resolve more than one ticket per session** — wi
 User invokes with a loose idea.
 
 1. **Name the destination.** Run a `/grilling` and `/domain-modeling` session to pin down what this map is finding its way to — the spec, decision, or change. The destination fixes the scope, so it's settled first.
-2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Stop and ask the user how they'd like to proceed.
+2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Continue into `ship_deliver`, or stop after the map exists.
 3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.
 4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section.
 5. **Fire the research subagents.** For each `research` ticket you just created, spin up a `/research` subagent to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.

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

@@ -149,29 +149,40 @@ If you find issues, fix them inline. No need to re-review — just fix and move
 
 ## Execution Handoff
 
-After saving the plan, offer execution choice:
-
-**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Two execution options:**
-
-**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
-
-**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints
-
-**Which approach?"**
-
-**If Subagent-Driven chosen:**
-- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
-- Fresh subagent per task + two-stage review
-
-**If Inline Execution chosen:**
-- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans
-- Batch execution with checkpoints for review
+After saving the plan, tell the user the file path in one sentence
+using: `Plan: <path>`. Ask one product question: whether the plan
+matches what they want. Then stop.
+
+Never ask how to run the work: no Subagent vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next".
+
+### After the user confirms the plan
+
+The plan is product-shaped, not workflow-shaped. The next step is
+a single fork — does the user want to start building now in this
+chat, or continue later in a new chat?
+
+1. Ask **one** `question`: "Start building now in this chat, or
+   continue later?" Recommend "Start now" — this chat waits until
+   the controller finishes and prints the PR Ready.
+2. On **Start now**: call `ship_issue` (use the plan heading as
+   the title and the plan path as the body) and then call
+   `ship_deliver` with that issue number. Print the envelope
+   `progress` and `next` lines so the user sees the stage. Stop
+   talking about how the work runs; the controller prints Build /
+   Review / Verify / Ready per task.
+3. On **Continue later**: print exactly two lines and stop.
+
+   ```
+   Plan: <path>
+   To build this later, start a new chat and say: Implement the approved plan at <path>
+   ```
 
 ## 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
+Ship controller; the cheap builder (`minimax-coding-plan/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.