ship-debug

A debugging workflow that saves investigation progress between sessions. Debugging means finding and fixing the cause of a software problem.

In plain words
What is it for?
Use it to track suspected causes, evidence, decisions, and next steps while diagnosing bugs across multiple sessions.
Why use it?
It prevents lost context when a session ends or is interrupted, so you can continue an investigation without starting over.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/acendas/shipyard/ship-debug
Any agent
npx skills add Acendas/shipyard --skill ship-debug
Clone the repo
git clone --depth 1 https://github.com/Acendas/shipyard

Made for: Claude Code, Codex.

Per session 12 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 4,550 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00012 $0.04550
Opus 5 $0.00006 $0.02275
Sonnet 5 $0.00002 $0.00910
Haiku 4.5 $0.00001 $0.00455

Measured yesterday against content hash 2f48c26650f7, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

ship-debug 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 yesterday.

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.

plugins/shipyard/skills/ship-debug/SKILL.md · 298 lines

How it starts

The opening of the file, as written. The whole thing — 298 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Shipyard: Persistent Debugger

Systematic debugging that doesn't lose progress when context compacts or sessions break.

Context

!shipyard-context debug-session

Paths. All file ops use the absolute SHIPYARD_DATA prefix from the context block. No ~, $HOME, or shell variables in file_path. Bash invocation of shipyard-data is limited to the onboarding command surfaced by context plus the lock check/lock acquire/lock release subcommands (see Step 4's mutex checks), and shipyard-context reads — no other shell-out; use Read / Grep / Glob for everything else. Never use echo/printf/shell redirects to write state files — use the Write tool (auto-approved for SHIPYARD_DATA).

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.

Quiet by default. Between user-input gates, work quietly — investigate, run captures, and update the debug file without narrating each hypothesis-test in chat (the debug file is the record; that's where the running log lives, not the conversation). Only a one-line transition marker per boundary (status change, hypothesis eliminated) reaches the chat between gates. The diagnosis, fix plan, and resolution are rendered in full ONLY at a gate (render-before-ask — Step 3.5 fix plan, Step 6 close) or when the fix-attempt escalation fires. No running commentary ("Now I'll…", "Let me…", explaining a no-input step). Full doctrine: ${CLAUDE_PLUGIN_ROOT}/skills/ship-discuss/references/communication-design.md § "Interim Communication: Quiet by Default".

Read the full file on GitHub · 298 lines

Changes

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.

  1. yesterday First seen · 298 lines · 12 tokens per session scan A 2f48c26650f7

Subscribe to this mod's changes

ship-debug is a skill published in the GitHub repository Acendas/shipyard (2 stars, last pushed 20d ago), licensed MIT. It adds 12 tokens to every session and 4,550 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.

Related

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)…

seekdevcore/sk-requirements-engineering-theskill · 0 tokens

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)…

seekdevcore/sk-requirements-engineering-theskill · 0 tokens

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.

MarieLynneBlock/arcanum-artifex · 40 tokens

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.

MarieLynneBlock/arcanum-artifex · 64 tokens

agentflow

Orchestrate autonomous AI development pipelines through your Kanban board (Asana, GitHub Projects, Linear). Manages multi-worker Claude Code dispatch, deterministic quality gates, adversarial review, per-task cost tracking, and crash-proof pipeline execution.

sickn33/agentic-awesome-skills · 52 tokens

backlog-grooming

Review Agiflow Planning tasks for readiness, prioritize approved work, group related tasks into work units, and promote ready tasks to Todo. Use when grooming a backlog, organizing planned tasks, creating work units, or deciding what should be executed next.

hashgraph-online/awesome-codex-plugins · 55 tokens