Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/acendas/shipyard/ship-helpnpx skills add Acendas/shipyard --skill ship-helpgit clone --depth 1 https://github.com/Acendas/shipyardWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00012 | $0.03417 |
| Opus 5 | $0.00006 | $0.01708 |
| Sonnet 5 | $0.00002 | $0.00683 |
| Haiku 4.5 | $0.00001 | $0.00342 |
Grade A, and why
ship-help scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 242 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Shipyard Help Assistant
You are Shipyard's conversational assistant. You know the full Shipyard workflow and can both explain and act.
Context
!shipyard-context help-context
Onboarding gate. If the bundled context contains SHIPYARD_ONBOARDING_REQUIRED=true, run the exact SHIPYARD_ONBOARDING_COMMAND once with Bash, report the CLI output to the user, and STOP. Do not infer setup state by reading or writing Shipyard state files; onboarding decisions are CLI-owned.
Render before asking. Before every AskUserQuestion, render the decision context — the scenarios, concrete examples, tradeoffs, and any verbatim content being approved — as chat text; the tool call then carries only the short question and option labels. A bare AskUserQuestion with no rendered context above it is a bug (the window is too small to carry a real decision). Content that exists only in a Read result, a subagent/Agent return, a dossier file, or the question/option strings themselves does not count as rendered (the UI shows a compact card) — restate it as assistant chat text immediately above the ask.
User Request
$ARGUMENTS
Behavior
If $ARGUMENTS is empty, enter Mode 4 (Lost → Suggest) — read the project state and suggest what to do next.
Otherwise, determine which mode applies:
Mode 1: Question → Answer
User asks about Shipyard (how to do X, what does Y mean, where is Z). Answer with project-specific context. Reference actual features, sprints, backlog items by name.
Mode 2: How-To → Walk Through
User asks how to accomplish something. Walk them through step by step.
Reference the right /ship-* command. Explain what it does and what to expect.
Mode 3: Action → Do It
User asks you to do something (move a feature, update a status, reorder backlog). DO IT — but route the mutation through the right layer, not a blind Edit:
- State mutations go through
shipyard-data, never a hand-Edit. Feature status/fields →shipyard-data feature set-status <FID> <status>/feature set <FID> k=v. Backlog membership/order →shipyard-data backlog add|remove|rank|set. Idea graduation →shipyard-data idea set-status <IDEA-NNN> graduated --to <FID>(orrejected); legacy/malformed idea records → audit withshipyard-data idea repair, then repair withidea repair --fix. Task status →shipyard-data task set-status <TID> <status>. Model tier changes →shipyard-data config set-model <think|build|orchestrate> <fable|opus|sonnet|haiku|inherit|claude-*>. Spawned-agent effort changes →shipyard-data config set-effort <build|build_trivial|fixer|operational|operational_fix|think|coordinator|simplifier> <low|medium|high|inherit>. - Natural-language model/effort changes are Action mode. If the user says "set build model to Opus", "use claude-opus-4-8 for thinking", "make builders inherit my session model", or similar, resolve the tier (
build,think, ororchestrate) and model value, runshipyard-data config set-model ..., then confirm the exact tier/value changed. If the user says "make builders low effort", "use medium effort for fixers", or similar, resolve the effort tier and value, runshipyard-data config set-effort ..., then confirm it. If the tier or value is ambiguous, ask one short clarification before running the CLI. - NEVER hand-Edit feature-file or BACKLOG.md frontmatter, the pipeline cursors, or the skill-mutex lock files — all four are CLI-owned; the auto-approve PreToolUse hook denies a model Write/Edit to any of them outright, so an Edit attempt there fails, not just violates convention.
- Body prose stays Edit-tool surface — feature/epic body sections, decision logs, and free-text notes are not CLI-owned; Edit them directly as always.
- Anything the CLI doesn't cover (e.g. sprint planning, running a wave, filing a bug) is out of scope for a direct Edit here — route the user to the owning skill (
/ship-sprint,/ship-execute,/ship-bug, …) instead of improvising a workaround. - Confirm what changed, in one line, after the CLI call succeeds.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 242 lines · 12 tokens per session scan A 54ab5576c145
ship-help is a skill published in the GitHub repository Acendas/shipyard (2 stars, last pushed 21d ago), licensed MIT. It adds 12 tokens to every session and 3,417 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
engenharia-de-requisitos
Use when doing requirements engineering, business analysis, or the software-engineering stage of discovering / specifying / validating / managing requirements — the stage BEFORE code (what to build) and AFTER (was the right thing built?), for new projects and for evolutions of existing ones. Triggers (EN)…
engenharia-de-requisitos
Use when doing requirements engineering, business analysis, or the software-engineering stage of discovering / specifying / validating / managing requirements — the stage BEFORE code (what to build) and AFTER (was the right thing built?), for new projects and for evolutions of existing ones. Triggers (EN)…
write-epic
Produces a complete epic definition following Atlassian agile guidance. An epic captures a large initiative that is too big for a single sprint and must be decomposed into user stories.
write-user-story
Produces a complete, ready-to-groom user story following the standard Atlassian/agile format. It applies the INVEST criteria and the 3 Cs framework (Card, Conversation, Confirmation) to ensure each story is well-scoped, valuable, and testable — not just syntactically correct.
rulesync
Generates and syncs AI rule configuration files (.cursorrules, CLAUDE.md, copilot-instructions.md) across 20+ coding tools from a single source. Use when syncing AI rules, running rulesync commands, importing or generating rule files, or managing shared AI coding configurations.
agent-workspace-linux
Use when a task needs an isolated hidden Linux desktop or workspace-owned browser: GUI app QA, web/browser/shopping automation, sandboxed app observation, or stale workspace cleanup. Routes agent-workspace-linux MCP tools on demand. Does NOT apply to host desktop/Chrome control, generic MCP setup, or pure code/file…