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 ohad6k/VibeRaven --skill what-brokegit clone --depth 1 https://github.com/ohad6k/VibeRavenWrote 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/ohad6k/viberaven/what-broke)<a href="https://agentmods.dev/skills/ohad6k/viberaven/what-broke"><img src="https://agentmods.dev/badge/skills/ohad6k/viberaven/what-broke/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/ohad6k/viberaven/what-broke"><img src="https://agentmods.dev/badge/skills/ohad6k/viberaven/what-broke.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.00056 | $0.01016 |
| Opus 5 | $0.00028 | $0.00508 |
| Sonnet 5 | $0.00011 | $0.00203 |
| Haiku 4.5 | $0.00006 | $0.00102 |
Grade A, and why
what-broke 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 12d 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 — 84 lines — stays where its author put it; the contents beside it link to each section on GitHub.
What Broke
Use this skill when the app worked before and the agent is about to patch blind. Find the version that changed behavior, recover the version/release context, explain what broke, and connect the code diff to provider reality: database, storage, deployment, and external runtime behavior.
First Pass
- Inspect dirty work first:
git status --short. Do not reset, checkout, or overwrite user changes. - Identify the comparison range:
- Prefer explicit known-good and known-bad versions from the user.
- Otherwise infer from
git tag --sort=-creatordate,git log --oneline --decorate -n 40, package versions, release branches, and CHANGELOG entries.
- Map version names to concrete git refs: tags, branch names, release commits, package versions, or changelog headings.
- Build a narrow diff before editing:
git diff <good>..<bad> --stat, thengit diff <good>..<bad> --name-only, then focusedgit diff <good>..<bad> -- <path>. - Read provider-adjacent files touched in the range: migrations, schema files, storage policies, deployment config, provider SDK setup, seed data, and runtime boundary files. Add identity, billing, or event-delivery files only when the diff or user pain points there.
Evidence Packet
Before proposing code changes, produce a short packet:
- Range: good ref, bad/current ref, confidence, and why that range was chosen.
- Version name: semantic version, release name, tag, changelog heading, or "unknown".
- Changed surface: the files or modules that changed, grouped by app code, database, storage, deployment, provider SDK/setup, and external runtime behavior.
- Provider context: what provider-dependent behavior may have changed. Say when dashboard or runtime state is not verifiable from the repo.
- What broke path: the smallest chain from version change to observed breakage.
- Missing evidence: anything needed from logs, provider dashboards, release notes, or the user.
Smart Diff Workflow
Use the cheapest command that answers the next question:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago First seen · 84 lines · 56 tokens per session scan A ba77610a1779
what-broke is a skill published in the GitHub repository ohad6k/VibeRaven (38 stars, last pushed 2mo ago), licensed MIT. It adds 56 tokens to every session and 1,016 once invoked, about $0.0003 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-30.
Other skills, from other repositories
git-advanced-workflows
Master advanced Git workflows including rebasing, cherry-picking, bisect, worktrees, and reflog to maintain clean history and recover from any situation. Use when managing complex Git histories, collaborating on feature branches, or troubleshooting repository issues.
fix-merge-conflicts
Resolve merge conflicts non-interactively, validate build and tests, and finalize conflict resolution.
housekeep-dead-code
Apply-now dead-code removal by category — one commit each, typecheck and tests between, bisect on red, then install the Knip ratchet so it cannot grow back. Use when "delete the dead code", "remove unused files", "wire up Knip". Audit first → plan-dead-code. README/deps → workflow-housekeep.
bisect
Use when hunting a regression, phrases like "bisect", "find the commit that broke X", "this used to work", "regression in test Y", "when did start". Also use when escalated from ci-debug-loop because log analysis can't pinpoint the offending change, or when a previously-passing test/build/behavior is now failing and…
resolve-issue
Use when resolving an issue from any supported tracker (GitHub, JIRA, Bugsnag). Detects the source automatically from the provided link or ID, implements a safe fix or feature, validates with tests, and creates a pull request.
fix-issue
Fix a GitHub issue end-to-end. Use when given an issue number to fix, implementing bug fixes, or addressing reported problems.