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 mizukaizen/hive-doctrine-mcp --skill bug-analysisgit clone --depth 1 https://github.com/mizukaizen/hive-doctrine-mcpWrote 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/mizukaizen/hive-doctrine-mcp/bug-analysis)<a href="https://agentmods.dev/skills/mizukaizen/hive-doctrine-mcp/bug-analysis"><img src="https://agentmods.dev/badge/skills/mizukaizen/hive-doctrine-mcp/bug-analysis/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/mizukaizen/hive-doctrine-mcp/bug-analysis"><img src="https://agentmods.dev/badge/skills/mizukaizen/hive-doctrine-mcp/bug-analysis.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.00000 | $0.00705 |
| Opus 5 | $0.00000 | $0.00352 |
| Sonnet 5 | $0.00000 | $0.00141 |
| Haiku 4.5 | $0.00000 | $0.00071 |
Grade A, and why
bug-analysis 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 10d 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Bug Analysis Skill
Use when analysing bug reports. Identifies root cause, suggests fix approach, assesses blast radius, recommends regression tests.
When to Activate
- User asks to "investigate a bug", "find the root cause", or "why is this breaking?"
- The
/triagecommand is invoked - User reports unexpected behaviour and wants to understand why
Process
-
Reproduce the understanding. Before investigating code:
- Clarify the exact steps that trigger the bug
- Understand the expected vs actual behaviour
- Identify the environment and conditions (browser, OS, data state)
- Determine if the bug is consistent or intermittent
-
Locate the affected code. Search systematically:
- Start from the user-facing symptom and trace inward
- Search for function names, error messages, or UI text mentioned in the report
- Check recent git changes to the affected area
- Look at related tests — do they cover this scenario?
-
Identify the root cause. Distinguish between:
- Proximate cause — The line of code that produces the wrong result
- Root cause — The underlying reason the bug exists (missing validation, wrong assumption, incomplete specification, race condition)
- Contributing factors — Things that made the bug harder to catch (missing tests, unclear requirements, complex code)
-
Assess blast radius. Determine what else is affected:
- What other features use the same code path?
- What other data could be affected by the same bug?
- Is the bug in shared code (utility function, base class, middleware)?
- Could the fix introduce new issues elsewhere?
-
Suggest fix approach.
## Root Cause Analysis
### Symptom
[What the user sees]
### Proximate Cause
[The specific code that is wrong]
File: [path:line]
### Root Cause
[Why the code is wrong — the underlying issue]
### Blast Radius
- **Directly affected:** [features/components using the same code path]
- **Potentially affected:** [features that share related logic]
- **Not affected:** [features confirmed safe]
### Recommended Fix
[Specific approach with rationale]
- Option A: [approach] — Pros: [X] Cons: [Y]
- Option B: [approach] — Pros: [X] Cons: [Y]
- Recommended: [A or B] because [reason]
### Regression Tests Needed
1. [Test for the specific bug scenario]
2. [Test for blast radius scenarios]
3. [Test for edge cases related to the root cause]
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.
- 10d ago First seen · 80 lines · 0 tokens per session scan A afbfcff2c324
bug-analysis is a skill published in the GitHub repository mizukaizen/hive-doctrine-mcp (0 stars, last pushed 2mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 705 tokens. 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
api-linter
MCP definition linter rules reference. Use when bun run lint:mcp or bun run devcheck reports a lint error or warning (format-parity, schema-is-object, name-format, server-json-, etc.) and you need to understand the rule, its severity, and how to fix it. Every rule ID the linter emits has an entry in this doc.
report-issue-framework
File a bug or feature request against @cyanheads/mcp-ts-core when you hit a framework issue. Use when a builder, utility, context method, or config behaves contrary to the documented API — not for server-specific application bugs.
a11y-debugging
Uses Chrome DevTools MCP for accessibility (a11y) debugging and auditing based on web.dev guidelines. Use when testing semantic HTML, ARIA labels, focus states, keyboard navigation, tap targets, and color contrast.
chrome-devtools
Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to --slim mode (MCP configuration).
n8n-error-handling
Wire n8n error handling so failures are loud, structured, and recoverable. Use when building any webhook/API workflow, a scheduled or unattended workflow, or any path where a silent failure would drop user-visible work — and whenever the user mentions error handling, onError, continueErrorOutput, error…
n8n-validation-expert
Interpret validation errors and guide fixing them. Use when encountering validation errors, validation warnings, false positives, operator structure issues, or need help understanding validation results. Also use when asking about validation profiles, error types, the validation loop process, or auto-fix capabilities.…