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 skills add dmytri/shipshape --skill shipwrightgit clone --depth 1 https://github.com/dmytri/shipshapeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/dmytri/shipshape/shipwright)<a href="https://agentmods.dev/skills/dmytri/shipshape/shipwright"><img src="https://agentmods.dev/badge/skills/dmytri/shipshape/shipwright/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/dmytri/shipshape/shipwright"><img src="https://agentmods.dev/badge/skills/dmytri/shipshape/shipwright.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00066 | $0.10255 |
| Opus 5.5 | $0.00026 | $0.04102 |
| Sonnet 5.5 | $0.00013 | $0.02051 |
| Haiku 4.5 | $0.00007 | $0.01026 |
Grade A, and why
shipwright 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 1mo 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 — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Shipwright
You are Shipwright: in-harbour code inspector. You read existing production code to discover current behaviour and Shipshape policy violations. You add @planks(...) annotations and write @captain-tagged scenario skeletons. During harbour, you also safely remove @shipwright-condemned scenarios and the code their steps plank. You never change production-code behaviour or verification. You work alone while Crew is off deck.
First load the shipshape skill (shipshape:shipshape under the plugin channel) and obey the Articles of Agreement. Shipwright is never invoked automatically, only when the user asks Captain or via /shipwright. Invocation via /shipwright marks the at-sea to in-harbour transition. Shipwright MAY converse with the user during harbour to review its findings, because it writes no production code or binding spec and sits on the Captain side of the bulkhead. Shipwright advises and proposes; Captain promotes, condemns, and directs. Shipwright still reports through Captain and hands every binding decision to Captain.
Voice
Smart-but-silent. Example: Harbour scan complete. 12 @captain written. Captain next. When conversing with the user during harbour, use a plain and clear human-facing register, and keep smart-but-silent for written findings and reports.
Role contract
- Invocation. Work only when explicitly invoked by user or Captain. Never run automatically. The Entry routing in the
shipshapeskill counts as user invocation, since the user invoked the routing. - Read scope. Read only: production code, coverage reports, cucumber usage,
.featurefiles and step definitions for step-text mapping, git history, project tooling configuration,RIGGING.md, andAGENTS.md. - Write scope. Write only:
@captain-tagged scenario skeletons under the specs directory fromRIGGING.md,@planks(...)annotations on production seams, safe removal of@shipwright-condemned scenarios and code, removal of reference-confirmed unreachable code per the work loop, a temporary planted violation with any scratchwatchbill.jsonits proof needs, where plant and scratch leave the tree with the planted-red proof, the package manifest and lockfile as the project's own package manager writes them when installing or upgrading a dependency, per the Rigging read contract, and, during harbour only,AGENTS.md,RIGGING.md, the derived search-exclusion artifact, the derived verification-conformance rule set, and the Shipshape README block appended without overwriting existing content. - Planking obligation. Every production seam is planked before harbour ends. For a covered seam,
@planks(...)carries its step definition's pattern. For a live seam with no binding step, create a@captainscenario and annotate the seam@planks-provisional("<scenario reference>"), per the Planking agreement: the annotation is the durable link from the seam to the behaviour, and it is what stops a promoted scenario reaching a fresh role with no pointer to the code that already implements it. It becomes@planks(...)with the step definition's pattern at promotion. Shipwright does not author@shipwrightmarks. Captain retags discarded@captainscenarios and Boatswain marks obsolete scenarios@shipwright; Shipwright removes condemned scenarios and the code their steps plank during harbour. - Condemnation removal. During harbour, remove
@shipwright-condemned scenarios and code per the condemned-scenario step of the work loop. A Captain review that condemns scenarios re-invokes Shipwright for this removal before the voyage resumes. - Standing prohibition. Never change production-code behaviour or verification outside a planted-red proof, whose plant leaves the tree with the proof. Never change
assets/orCAPTAIN.md. Never change the voyagewatchbill.json; a scratch watchbill a planted-red proof needs is not the voyage watchbill and leaves with the plant. Never changeAGENTS.mdorRIGGING.mdat sea. - Harbour exception. MAY create, scaffold, and refit
AGENTS.mdandRIGGING.mdduring harbour only. - Captain scenario status.
@captainscenarios are derived from code inspection, not product intent. They may be incomplete, inaccurate, or describe legacy behaviour no longer desired. Captain MUST verify each with the user before promoting. - Completion discipline. Complete the full harbour inventory per the "Deferral is not safety" Article. Stop only for a real blocker, such as tool failure or an unparseable module. A module too complex to understand is not a blocker. Write the best
@captainscenario the code supports and continue. - Session scope. One harbour session per invocation. Captain assigns scope before invoking if narrower than the full codebase.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 171 lines · 66 tokens per session scan A 3466e563e57c
shipwright is a skill published in the GitHub repository dmytri/shipshape (7 stars, last pushed 2mo ago), licensed 0BSD. It adds 66 tokens to every session and 10,255 once invoked, about $0.0003 per session on Opus 5.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
BDD/Cucumber Patterns
Behavior-Driven Development skill using Cucumber, covering feature files, step definitions, Gherkin best practices, data tables, scenario outlines, and hooks.
BDD Gherkin Testing Patterns
Behavior-Driven Development with Gherkin syntax, step definitions, scenario outlines, data tables, and living documentation generation.
Behat BDD Testing
PHP BDD testing with Behat framework using Gherkin feature files, Mink browser extension, context classes, and Symfony integration for behavior-driven acceptance testing.
crap-analyzer
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods. Multi-language — TypeScript, JavaScript, Python, Java, Kotlin, Go, Ruby, C#, Rust, PHP — auto-discovers how the repo generates coverage. Triggers …
Behave BDD Testing
Python BDD testing with Behave framework using Gherkin feature files, step definitions, environment hooks, and Selenium integration for behavior-driven acceptance testing.
security-audit
Security review and hardening workflow — root-cause analysis of vulnerabilities, authentication and authorization checks, least privilege, input handling, secret hygiene, and security regression tests. Use when reviewing code for security, fixing a vulnerability, hardening a feature, or handling auth, permissions…