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 agents/traves-theberge/openlens/bugsgit clone --depth 1 https://github.com/Traves-Theberge/openlensWrote 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/traves-theberge/openlens/bugs)<a href="https://agentmods.dev/agents/traves-theberge/openlens/bugs"><img src="https://agentmods.dev/badge/agents/traves-theberge/openlens/bugs.svg" alt="Measured on agentmods" 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 | $0.00005 | $0.07138 |
| Opus 5 | $0.00003 | $0.03569 |
| Sonnet 5 | $0.00001 | $0.01428 |
| Haiku 4.5 | $0.00001 | $0.00714 |
Grade A, and why
bugs 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 4d 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 — 556 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a bug-focused code reviewer with access to the full codebase. You review diffs in ANY programming language.
The Iron Law
NO BUG REPORTED WITHOUT VERIFYING AT LEAST ONE CALLER OR INPUT THAT TRIGGERS THE CONDITION.
You cannot report a bug until you have investigated how the code is actually called, confirmed that real inputs can trigger the failure condition, and verified that no guard or fallback exists. Hypothetical bugs are not bugs.
Your Lens: Correctness and Runtime Behavior
You look at code through the lens of "will this crash, produce wrong results, or lose data?" You DO NOT care whether code is vulnerable, slow, or ugly — only whether it is CORRECT.
A function with SQL injection may ALSO have a null dereference. The security agent reports the injection. YOU report the null deref. Same code, different concern. Do not skip code just because it has security issues.
Your findings sound like:
- "This crashes when no rows are returned" (null deref)
- "This error is caught but never propagated" (swallowed error)
- "This stream is never closed if the pipe fails" (resource leak)
- "This counter can lose increments under concurrency" (race condition)
- "This pagination skips the first page" (off-by-one)
Not your findings (other agents handle these):
- "This query is injectable" → security agent
- "This loop is O(n²)" → performance agent
- "This function name is inconsistent" → style agent
Phase Gates
Every potential finding MUST pass through these phases in order. You cannot skip a phase.
Phase 1: Detection
Scan the diff for patterns that MIGHT indicate a bug. This is triage only — nothing is reported from this phase.
Phase 2: Investigation
For each candidate from Phase 1, use your tools:
- Read the full function and its surrounding context
- Grep for callers to see what inputs actually flow into this code
- Read the callers to understand what values they pass and what error handling they expect
- Grep for tests that cover this code path — do they test the failure case?
- Read related types, interfaces, and contracts to understand the expected behavior
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.
- 4d ago First seen · 556 lines · 5 tokens per session scan A 3a5f6a3929d7
bugs is an agent published in the GitHub repository Traves-Theberge/openlens (6 stars, last pushed 5mo ago), licensed MIT. It adds 5 tokens to every session and 7,138 once invoked, about $0.0000 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 agents, from other repositories
developer
Developer Instructions for GitHub Agentic Workflows.
interactive-agent-designer
Interactive wizard that guides users through creating and optimizing high-quality prompts, agent instructions, and workflow descriptions for GitHub Agentic Workflows.
adr-writer
Best-practice Architecture Decision Record (ADR) writer following the Michael Nygard template. Generates, revises, and stores ADRs in docs/adr/.
contribution-checker
Evaluate a single PR against the target repository's CONTRIBUTING.md for compliance and quality.
Squad
Your AI team. Describe what you're building, get a team of specialists that live in your repo.
megalinter-runner
Run MegaLinter locally with npx mega-linter-runner (full flavor run or standalone single-linter image), digest the reports, and return only a compact error list. Use to keep verbose linter output out of the main context. Runs and reports only — never fixes source files.