s

Query the oracle before interrupting a human: shape a request into one compact decision, consult the workspace wiki and the repo's spec surfaces through the `s:oracle` agent, and relay its verdict — a cited recommendation, or a question queued for a person to answer later. Use when asked to "ask the oracle", consult the oracle, or get the user's standing opinion on a decision before escalating to the user. Trigger phrases: "ask the oracle", "consult the oracle", "/s:ask".

Drive an approved epic's unplanned members to shipped PRs unattended: plan → gate → build → auto-merging PR per member over the configured pipeline, in risk-ascending order, one worktree/branch each. Preflights the epic, confirms the run controls, runs the autopilot in the foreground, and relays its report with resume pointers for any parked members. Use when asked to "autopilot an epic", "deliver an epic", "ship the epic's members", or "/s:autopilot". Trigger phrases: "autopilot", "deliver", "ship the epic", "/s:autopilot".

Orchestrate a feature end-to-end with spec-driven development: plan and design the shipd artifacts on the most powerful model, then delegate implementation to execution sub-agents on the tier below, answer their questions, verify, and merge + archive with the plugin's own spec engine. Use when asked to build/implement/ship a feature, add a capability, or "orchestrate" work — anything non-trivial that benefits from a spec-first plan plus delegated execution. Trigger phrases: "build", "implement", "add a feature", "/s:build".

Diagnose and repair a shipd environment: run the read-only `shipd doctor` preflight, parse its `ok|warn|fail <check> — <detail>` lines, propose one remedy per remediable finding, run only the remedies the user consents to, then re-run the preflight and report the before/after. Use when asked to "fix my setup", "check my environment", diagnose why shipd is not working, or run a preflight before starting work. Trigger phrases: "doctor", "fix my setup", "check my environment", "preflight", "/s:doctor".

Author or revise documentation against the shipd documentation standard: load the one canonical rules file, classify each target doc as concept, how-to, or reference, write or rewrite it to the standard, then run the stdlib-only lint until it exits clean and self-review the rules a machine cannot check. Edits documentation only — it never commits, never pushes, and never opens a pull request. Use when asked to document something, write or rewrite a doc, tighten prose under `docs/`, or bring a doc up to the house standard. Trigger phrases: "document this", "write the docs", "rewrite this doc", "/s:document".

Drive a real browser with Playwright to operate an app, verify a change against it, and optionally record a branded demo video: resolve the target and its credentials, run the `drive.py doctor` preflight, obtain or reuse a cached login, start the one-browser session daemon, probe the live DOM before authoring any selector, drive the requested instructions while waiting for a named completion signal, and end on a PASS/FAIL verdict backed by console and network evidence. Use when asked to drive the app, verify a change in a real browser, click through a flow, or record a demo video of a change. Trigger phrases: "drive the app", "verify this in the browser", "click through this flow", "record a demo", "/s:drive".

Talk an idea, a process, or a concept through with an adversarial rubber-duck critic before any of it is planned or built: read the repo and the engine-mediated spec surfaces to ground the critique, push back rather than agree, surface the strongest alternative, and name the shipd skill that should pick the idea up once it converges. Strictly read-only — it changes no file, emits no artifact, and invokes no other skill. Use when asked to rubber-duck something, talk an idea through, validate a concept or a process, or get a second opinion before planning. Trigger phrases: "rubber duck", "talk through this idea", "validate this concept", "be my duck", "/s:duck".

Decompose a feature into an epic: investigate the codebase first, ask the user only what can't be inferred (one batched round), record the epic's Decisions and Design, and emit the stub table of member changes with complexity ratings — then stop. Member changes are planned later, one at a time, via /s:plan. Invoked as `/s:epic <slug> amend`, runs the amendment flow on a live epic instead: stamped Decisions and shelf edits only, gated by the linter and `epic-amend-check`, then shipped as a PR from a fresh `epic-amend-<slug>` worktree — or, where the epic resolves into an external store, as one scoped local commit in the store's repository. Use when asked to "create an epic", "decompose a feature", "group changes", "amend an epic", or plan a multi-change initiative before spec'ing the individual changes. Trigger phrases: "epic", "create an epic", "decompose", "amend the epic", "/s:epic".

Read a shipd epic through the engine and explain it: run the mediated `cat epic` and `epic-show` verbs, then print a short explanation covering what the epic is for, the decisions holding it up, how its member changes compose, and where delivery stands — with a diagram only where one carries structure prose cannot. Strictly read-only — it writes no file, emits no artifact, and runs no mutating engine verb. Use when asked to explain, summarize, or make sense of an epic. Trigger phrases: "explain this epic", "summarize the epic", "what is this epic about", "/s:explain".

Debug a reported problem against the spec library: distill the description into search terms, retrieve the related spec artifacts with the engine's `related` verb and read them through the mediated `cat` verbs, reproduce the problem, then either fix the code that drifted from the documented behavior (with a regression test) or — when the documented behavior itself is wrong — stop and hand off to `/s:plan`. Ends with diagnosis, fix, and verification evidence; never commits, branches, pushes, or opens a PR, and never edits a spec artifact. Use when asked to fix a bug, debug a failure, or find and fix something that is behaving wrongly. Trigger phrases: "fix this bug", "debug this", "find and fix", "/s:fix".

Remove a captured preference from the personal memory store: take a free-text description of the memory to forget, locate the matching `memory-*` page, confirm the removal with a single dialog, and delete it through `wiki-remove --personal` — the remove counterpart to `/s:remember`. Use when asked to "forget that I prefer …", "remove a memory", "delete what you remember about …", "drop that preference", or "/s:forget". Trigger phrases: "forget that", "remove a memory", "delete a memory", "forget my preference", "/s:forget".

Set up the shipd semantic review gate in a repository end to end: preflight the prerequisites, install the four managed files with `shipd copilot add`, commit and push them, then — on consent — require the `semantic-review` check, enable auto-merge, hand off the reviewer token, and verify with `shipd doctor`. With the `update` argument, run the refresh-only flow instead: re-read the managed files' states, refresh what is stale or absent, and ship the refresh — no settings, no token. Use when asked to set up the review gate, block PRs on the semantic review, turn on the merge gate, or refresh an already-installed gate to the running plugin version. Trigger phrases: "set up the gate", "install the review gate", "block PRs on review", "/s:gate", "/s:gate update", "update the gate".

Drive workspace initiatives through their CLIs: create a lint-clean brief from a workspace-first interview (new), report every initiative's status and requirement progress (list), walk a brief's outcomes and sync its status (review), or tag an epic with exactly one initiative via a PR (set). Use when asked to "start an initiative", "create/review a brief", "track outcomes", or "attach an initiative to an epic". Trigger phrases: "initiative", "brief", "attach an initiative", "/s:initiative".

List the durable preferences captured in the personal memory store: resolve the personal store, read its index, and print the stored `memory-*` pages — the read-only browse counterpart to `/s:remember`. Use when asked to "show my memories", "list what you remember", "what preferences are stored", "browse the memory store", or "/s:memory". Trigger phrases: "show my memories", "list my memories", "what do you remember", "browse memory", "/s:memory".

Run the guided shipd tour: a fixed nine-step walkthrough the user drives with `/s:onboard next` and `/s:onboard back`. Steps 1–7 explain Spec-Driven Development and the artifacts over a pre-baked example in a throwaway sandbox, step 8 builds it for real on the engine, and step 9 hands over the exact command to plan a first enhancement. Progress persists to disk so the tour resumes across sessions. Use when a user wants to learn shipd from scratch or asks how the workflow fits together. Trigger phrases: "onboarding", "onboard", "tour", "how does shipd work", "teach me shipd", "/s:onboard", "/s:onboard next", "/s:onboard back".

Converge context into an execution-ready spec: investigate the codebase first, ask the user only what can't be inferred (batched on the fast path; grouped question rounds when the depth gate fires), then emit the lean shipd artifacts (plan.md, delta specs, tasks.md) and stop. Use when asked to "plan", "spec this", "plan before building", or work out an approach before writing code. Trigger phrases: "plan", "spec this", "plan before building", "/s:plan".

Interrogate a product idea into a lint-clean workspace PRD: resolve the workspace, investigate the codebase and the workspace's knowledge surfaces with the engine's `search` retrieval before asking anything, then grill the user round by round — one template section at a time against the active tier (`basic`, `standard`, `comprehensive`; `standard` by default) — and install the result through the engine's staged `prd` emit. The discover phase's front door: it ends at the installed PRD and points at `/s:epic`, never decomposing it itself. Use when asked to "create a PRD", "write a PRD for ...", capture "product requirements", or run the "discover phase". Trigger phrases: "PRD", "product requirements", "discover phase", "/s:prd".

Capture the user's durable memories into the personal memory store: extract memory candidates from the invocation argument or the session, reconcile each against existing `memory-*` pages, confirm the proposed set in a typed round, and install through one staged `spec_emit.py wiki --personal` call. Use when asked to "remember that I prefer …", "capture a preference", "save this to memory", "note that …", or "/s:remember". Trigger phrases: "remember I prefer", "capture a preference", "save to memory", "note that", "/s:remember".

Turn a question into a cited research report: decompose it into bounded sub-questions, search each with the session's built-in WebSearch, select the strongest sources, extract anchored findings with WebFetch, and compose a report with a summary, themed findings, gaps & caveats, and a numbered `## Sources` list with `[n]` citation markers — then install it through the spec engine so an epic can link it. Use when asked to "research" a topic, produce a "deep research" or "research report", or gather external prior art before planning. Trigger phrases: "research", "deep research", "research report", "/s:research".

Run an AST-aware semantic review of local changes, in the style of popular code-review tools, against a base ref before they are pushed: map changed files into cohorts, reason over a syntax-aware structural diff (never raw file dumps), chase changed signatures to their call sites, and report findings by cohort with a high/medium/low severity rubric and a ship-it/fix-required verdict. When a planned shipd change is in scope, verify the diff against its delta scenarios. Read-only; a `--json` mode feeds the future PR gate. Use when asked to "review my changes", run a "semantic review", review a diff/branch/PR before pushing, or "/s:review". Trigger phrases: "review my changes", "semantic review", "review this diff", "/s:review".

Report or change a spec's lifecycle status through the guarded status CLI: print the bare status, validate the change's structure, run a guarded transition that asks before forcing past a guard, or report the effective autonomous pipeline (and expand a named preset). Use when asked to check, validate, or set a change's status, to promote/complete/verify a change, or to see which pipeline this repo resolves. Trigger phrases: "status", "validate change", "set status", "pipeline", "/s:status".

Teach the oracle: distill the repo's spec artifacts and answered queue entries into the workspace wiki. Scan the engine-mediated spec surfaces, interview the user only on the gaps and contradictions the scan surfaces, drain answered queue entries into pages, and ingest through the store's staged, lint-gated emit verb. Use when asked to "teach the oracle", "distill knowledge into the wiki", "fill the wiki", "drain the queue", or "/s:teach". Trigger phrases: "teach the oracle", "distill knowledge into the wiki", "drain the queue", "/s:teach".

Turn a screen recording into an intent brief: confirm the toolchain with `video_ingest.py doctor`, obtain a bundle by ingesting a supplied video or reusing a supplied slug, read the bundle's transcript and indexed frames, extract candidate intents anchored on transcript words, ground each on its nearest frame, resolve conflicting statements by recency, and compose a cited brief installed through the spec engine. Use when asked to ingest a video, turn a recording into a brief, or process a screen recording's feedback. Trigger phrases: "video ingest", "ingest this recording", "turn this video into a brief", "/s:video-ingest".

Set up and inspect the shipd workspace through its CLI: create the workspace marker with a guided target-root choice (init), report the workspace roster of projects and initiatives (show), bootstrap a job workspace from its repository URL (clone), materialize its members by executing the engine's plan with real git (sync), or map members to the checkouts they already have on this machine (map). Use when asked to "set up a workspace", "create a workspace", "initialize a workspace", "clone a workspace", "sync the workspace", "materialize members", "map a member", or to see what a workspace contains. Trigger phrases: "workspace", "set up a workspace", "workspace init", "clone a workspace", "sync the workspace", "materialize members", "map the workspace", "/s:workspace".

Author and register the setup scripts a new worktree runs: turn a described setup need into an executable script under `<content-dir>/hooks/`, register its repo-relative path through the binary's `worktree hooks add` verb, and verify the registration by reading `worktree hooks list` back. Also browses the registered hooks (flagging any whose script file is missing) and removes one on confirmation. Use when asked to "run something after creating a worktree", "set up new worktrees automatically", "copy my .env into every worktree", "seed the database in new worktrees", or to list/remove the configured post-worktree scripts. Trigger phrases: "worktree hook", "post-worktree script", "set up new worktrees", "run this in every worktree", "/s:worktree-hooks".