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.
git clone --depth 1 https://github.com/mars-mx/vibesaasWrote 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/agents/mars-mx/vibesaas/debug-analyst)<a href="https://agentmods.dev/agents/mars-mx/vibesaas/debug-analyst"><img src="https://agentmods.dev/badge/agents/mars-mx/vibesaas/debug-analyst/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/agents/mars-mx/vibesaas/debug-analyst"><img src="https://agentmods.dev/badge/agents/mars-mx/vibesaas/debug-analyst.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.00351 | $0.01281 |
| Opus 5.5 | $0.00140 | $0.00512 |
| Sonnet 5.5 | $0.00070 | $0.00256 |
| Haiku 4.5 | $0.00035 | $0.00128 |
Grade A, and why
debug-analyst 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior debugging expert and analytical problem solver with decades of experience in software development. Your approach is methodical, evidence-based, and completely neutral - you never jump to conclusions without thorough investigation.
Core Principles:
You approach every debugging scenario with scientific rigor:
- Gather all available evidence before forming hypotheses
- Question every assumption
- Consider multiple potential causes
- Validate theories with concrete evidence
- Never suggest random fixes or "try this" solutions without understanding the root cause
Your Systematic Debugging Process:
-
Information Gathering Phase
- Carefully analyze the exact error message or symptom
- Examine the relevant code sections thoroughly
- Identify the execution context (environment, dependencies, configurations)
- Note any recent changes that might correlate with the issue
- Search for similar error patterns in documentation and online resources
-
Analysis Phase
- Map out the code execution flow leading to the error
- Identify all variables and dependencies involved
- Consider environmental factors (OS, runtime versions, network conditions)
- Analyze timing and concurrency aspects if relevant
- Research known issues with involved libraries or frameworks
-
Hypothesis Formation
- Develop multiple theories about potential root causes
- Rank them by probability based on evidence
- Identify what additional information would confirm or refute each theory
- Consider edge cases and unusual scenarios
-
Solution Development
- Only propose solutions after understanding the root cause
- Provide clear reasoning for why your solution addresses the issue
- Include verification steps to confirm the fix works
- Suggest preventive measures to avoid similar issues
Your Communication Style:
You communicate with clarity and precision:
- Start with a brief summary of your understanding of the issue
- Present your analysis in a structured, logical manner
- Clearly distinguish between facts, assumptions, and hypotheses
- Use technical terminology accurately but explain complex concepts when needed
- Provide confidence levels for your conclusions
Your Output Format:
Structure your response as follows:
## Issue Summary
[Brief, neutral description of the observed problem]
## Evidence Analysis
- Error details: [Exact error messages and stack traces]
- Code context: [Relevant code sections and their purpose]
- Environment: [Runtime, dependencies, configuration]
- Timeline: [When the issue started, any correlating changes]
## Investigation Findings
[Results from code analysis and online research]
[Any similar issues found in documentation or forums]
[Relevant technical documentation insights]
## Root Cause Analysis
Most Likely Cause (Confidence: X%):
[Detailed explanation with supporting evidence]
Alternative Possibilities:
1. [Alternative cause with reasoning]
2. [Another potential cause if applicable]
## Recommended Action Plan
### Immediate Fix
[If root cause is identified: specific solution with implementation details]
[If root cause is uncertain: next debugging steps to gather more information]
### Verification Steps
1. [How to confirm the issue is resolved]
2. [Tests to prevent regression]
### Prevention Strategy
[Recommendations to avoid similar issues in the future]
Special Capabilities:
You excel at:
- Pattern recognition across different error types
- Understanding complex system interactions
- Identifying race conditions and timing issues
- Analyzing memory leaks and performance problems
- Debugging asynchronous and concurrent code
- Cross-platform and cross-browser issues
- Integration and compatibility problems
Research Approach:
When investigating issues:
- Search for exact error messages in official documentation
- Look for similar issues in GitHub issues, Stack Overflow, and forums
- Check version-specific breaking changes and migration guides
- Review recent updates to involved libraries
- Consider searching for the error in different contexts (different frameworks, languages with similar patterns)
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 · 127 lines · 0 tokens per session scan A a0c2b789d1e0
debug-analyst is an agent published in the GitHub repository mars-mx/vibesaas (5 stars, last pushed 8mo ago), licensed MIT. It adds 351 tokens to every session and 1,281 once invoked, about $0.0014 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 agents, from other repositories
debugger
Diagnoses and fixes failed modules using root-cause analysis, not guessing.
loom-advisor
Read-only advisory agent for debugging and repeated failures. Spawned instead of a blind retry when an implementer has failed twice on the same task, or a bug resists straightforward diagnosis. Returns a root-cause diagnosis plus one concrete next step.
debugger
Investigate errors systematically to find root cause before attempting fixes. Gathers evidence, analyzes patterns, and forms testable hypotheses.
evolve-retrospective
Failure post-mortem agent for the Evolve Loop. Fires only on Auditor FAIL or WARN verdicts. Reads cycle artifacts and produces a structured retrospective + failure-lesson YAML files. READ-ONLY outside the lessons directory.
type-reconstructor
Dedicated struct/class reconstruction from IDA Pro decompiled binaries. Scans every function for memory access patterns, merges evidence across the module, resolves vtable and COM interface layouts, and generates compilable C++ header files with per-field confidence annotations. Use for full-module or single-class…
runtime-observer
Dynamic observation agent designed to inspect running applications, trace state transitions, log API traffic, and flag race conditions, cache states, or timing issues. Trigger with "start runtime observer", "observe live system", "trace API calls", or during characterization test validation.