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/michaelycjo/specseal/debugnpx skills add MichaelYcJo/SpecSeal --skill debuggit clone --depth 1 https://github.com/MichaelYcJo/SpecSealWhat 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.00077 | $0.00433 |
| Opus 5 | $0.00039 | $0.00217 |
| Sonnet 5 | $0.00015 | $0.00087 |
| Haiku 4.5 | $0.00008 | $0.00043 |
Grade A, and why
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.
What it actually says
debug — one hypothesis at a time, and a failing test before the fix
The code runs and produces the wrong answer, which means it can be reproduced — and a bug you cannot reproduce is a bug you cannot claim to have fixed. Changing several things at once destroys the only signal you have: which change mattered.
Phase 1: Understand (before touching code)
- Read the FULL error message and stack trace
- Reproduce the issue (write a failing test if possible)
- Check recent changes that might have caused it
- Collect evidence: logs, error output, state
Phase 2: Locate
- Find working examples of similar code in the codebase
- Compare working vs broken - what's different?
- Binary search: narrow down the problem area
- Check inputs and outputs at each boundary
Phase 3: Hypothesize
- Form ONE hypothesis at a time
- Design minimal test to confirm/deny
- If denied → new hypothesis (don't patch the old one)
Phase 4: Fix
- Write a failing test that reproduces the bug
- Make the minimal change to fix it
- Verify: failing test now passes
- Verify: no other tests broke
Rules
- Never guess-and-check randomly. Be systematic.
- One change at a time. Verify after each.
- If 3 fix attempts fail → STOP (3+ Fix Rule). The problem may be architectural.
- Document what you tried and what you learned.
Output Format
Bug: [description]
Root cause: [why it happens]
Fix: [what was changed]
Test: [how it's verified]
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.
- yesterday First seen · 55 lines · 77 tokens per session scan A 582acdb244ae
debug is a skill published in the GitHub repository MichaelYcJo/SpecSeal (1 stars, last pushed 2d ago), licensed MIT. It adds 77 tokens to every session and 433 once invoked, about $0.0004 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
gsd-audit-milestone
Audit milestone completion against original intent before archiving.
spec-kitty-charter-doctrine
Run charter interview, generation, context, and sync workflows for project governance in Spec Kitty 3.x. Access doctrine artifacts programmatically via DoctrineService. Resolve agent profiles. Load action-scoped governance context iteratively, not all at once. Triggers: "interview for charter", "generate charter"…
spec-kitty-spdd-reasons
Drive REASONS Canvas authoring and review for Spec Kitty missions that opted in to Structured-Prompt-Driven Development (SPDD) via charter selection. Triggers: "use SPDD", "use REASONS", "generate a REASONS canvas", "apply structured prompt driven development", "make this mission SPDD". Does NOT handle: enforcing SPDD…
conductor-implement
Executes the tasks defined in the specified track's plan. Use this to start or continue working on a feature, bug fix, or chore.
spec-kitty-runtime-review
Review runtime-owned outputs using the Spec Kitty review workflow surface, then direct approval or rejection with structured feedback. Triggers: "review this work package", "check runtime output", "approve this step", "review WP", "is this WP ready to approve", "check this implementation". Does NOT handle: setup-only…
review
Review code changes for security, performance, bugs, and quality. Reviews staged changes, unstaged changes, specific commits, or PR-ready diffs.