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 3awny/qship --skill qshipcheckgit clone --depth 1 https://github.com/3awny/qshipWrote 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/3awny/qship/qshipcheck)<a href="https://agentmods.dev/skills/3awny/qship/qshipcheck"><img src="https://agentmods.dev/badge/skills/3awny/qship/qshipcheck/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/3awny/qship/qshipcheck"><img src="https://agentmods.dev/badge/skills/3awny/qship/qshipcheck.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.00051 | $0.03044 |
| Opus 5.5 | $0.00020 | $0.01218 |
| Sonnet 5.5 | $0.00010 | $0.00609 |
| Haiku 4.5 | $0.00005 | $0.00304 |
Grade A, and why
qshipcheck 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 — 236 lines — stays where its author put it; the contents beside it link to each section on GitHub.
qshipcheck — Pipeline Completion Validator
Verifies that the orchestrator's Phase 2 (review, bug hunt, fixes — per ticket), Phase 3 (E2E testing — once across all tickets), and Phase 4 (PR creation, final review, pipeline check — once across all tickets) were fully executed for a qship run. This is a hard gate — if any step was skipped, it must be run before the pipeline can be considered complete.
⛔ AUTONOMY & PERSISTENCE CONTRACT
The qshipcheck report MUST end in one of two states: PASSED, or still running remediation. There is no "FAILED — reporting incomplete" state. If you find missing steps, you run them, push any fixes, update the progress tracker, and loop back to Step 1 to re-verify. Repeat with no iteration cap until every row is VERIFIED.
Anthropic official guidance (verbatim):
Never artificially stop any task early regardless of the context remaining.
This applies here: if context is tight during remediation, save progress to the progress tracker file and keep going — compaction is automatic.
When to Run
Run /qshipcheck <TICKET_ID> after /qship finishes. The orchestrator should invoke this automatically as the very last step before the final completion message.
What It Checks
Phase 2 Steps (per ticket — static analysis)
| Step | What to verify | How to verify | Required evidence |
|---|---|---|---|
| 7.5 Simplify | code-simplifier:code-simplifier agent dispatched |
Progress tracker + conversation | Agent dispatch tool call + result |
| 8 Code Review (Agents 1+2+4) | 3 review agents dispatched | Progress tracker + conversation | 3 separate Task tool calls + results |
| 9 Bug Hunt | 5 bug hunter agents dispatched | Progress tracker + conversation | 5 separate Task tool calls + results |
| 10 Bug Validation | qbcheck ran on raw findings | Progress tracker + conversation | Validation summary (X real, Y false positive) |
| 11 Fix Issues | Validated bugs were fixed | Git log + progress tracker | Fix commits OR "AUTO-PASS (0 real bugs)" |
| 11.5 Verification Gate | Tests pass + formatting clean | Progress tracker | pytest output + black/isort check output |
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 · 236 lines · 51 tokens per session scan A 2dcc21c9745e
qshipcheck is a skill published in the GitHub repository 3awny/qship (2 stars, last pushed 3mo ago), licensed MIT. It adds 51 tokens to every session and 3,044 once invoked, about $0.0002 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
evidence-publish
Deliver a QA/evidence packet to a tracker or keep it local, behind an always-ask preview gate. Protocol for /orc:qa Phase 6, /orc:evidence, and any evidence-delivery step.
dhpk-repo-intake
Project initialization inventory (one-time), for first onboarding a project or rebuilding cache after structural changes. Not for: day-to-day development (read cache directly), finding specific files (use code-trace). Output: project map with entrypoints + test map + next steps.
visual-verification
Use for any UI/web project — make the verify gate cover more than unit tests by composing a pipeline (types → unit → design-scan → flow-smoke) and running the built-in yoke flow-smoke gate (landmark + zero console errors + screenshot proof to .yoke/proof/ /, video kept on failure). Catches the unwired-page /…
test-native-extension
Validate a third-party control repo across four automated layers plus one printed manual recipe. Layer 1 asserts native-source structure (Android getName() and iOS +moduleName to manifest nativeModule; @ReactMethod / RCTEXPORTMETHOD to methods; no @ReactModule) plus load/init readiness (ReactPackage public no-arg…
test-site
Tests a deployed, activated Power Pages site at runtime using browser-based navigation, page crawling, and API request verification via Playwright. Use when the user wants to test, verify, or smoke-test their deployed site.
live-preview
Mid-build visual verification loop. Takes screenshots of components during construction, not just after. Catches visual regressions and invisible features before they compound. Requires Playwright or similar screenshot tool.