
debug-my-harness
Diagnose why an agent harness misbehaved by reading the local flight-recorder ledger (.vigiles/runs.jsonl) — which skills fired or got hijacked, which hooks blocked or wrongly allowed, which subagent tool-contract violations happened, and how a skill's trigger rate moved. Use when asked why a skill stopped firing, why a hook didn't block, why the wrong skill ran, or to debug/investigate what the harness actually did. NOT for writing new rules (use strengthen) or editing the spec (use edit-spec).
- Installs
- 1.5K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/zernie/vigiles --skill debug-my-harness- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads debug-my-harness automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Diagnose harness misbehavior from the flight recorder — the local, append-only ledger
at .vigiles/runs.jsonl that vigiles writes as your harness runs. It records what actually
happened, so you debug from evidence instead of guessing.
What's in the ledger
One JSON record per line, each with a kind:
hook— a compiled-hook gate decision:{event, decision: allow|deny|ask, mode: enforce|observe, rule, cmd, reason}.agent— a subagent tool-contract decision:{name, tool, allowed, reason}(afalse= the agent went outside its lane).skill— a skill activation:{name, fired}.eval— a measured metric:{name, metric, value}(e.g. trigger-rate recall/precision).capability-diff— a blast-radius change:{pr, added, removed, widened}.
Instructions
Step 1: Read the ledger
Read .vigiles/runs.jsonl (JSONL — one record per line; tolerate a torn last line). If it's
absent or empty, say so — there's nothing recorded yet; suggest running the harness (or
vigiles audit) first. Do NOT fabricate records.
Step 2: Answer the specific question, evidence-first
Match the user's question to the ledger:
- "Why did skill X stop firing / why does the wrong one run?" — count
skillfires by name over time. If X's fire-rate dropped, look for a sibling that fired on the same kinds of prompts (a selection collision) and check their descriptions for overlap. Recommend differentiating or merging the descriptions. - "Why didn't my hook block that?" — find
hookrecords for the event. Adecision: allowon something that should be denied, ormode: observe(shadow, never blocks), or the absence of any record, tells you which. Recommend flippingobserve→enforceor fixing the gate logic. - "Did a subagent misbehave?" — list
agentrecords withallowed: false: the agent reached for a tool outside its declared contract. Point at the contract to tighten or widen. - "Is it getting worse?" — compare
evalmetric values (recall/precision) across runs; a downward trend is drift (often after a harness/model upgrade).
Step 3: Recommend a fix, tied to the evidence
Prefer promoting an ignored-but-decidable rule from prose to a deterministic gate: a
repeated agent violation or a rule the agent keeps breaking → a compiled hook or a tighter
tool-contract (the strengthen skill can help). A description collision → differentiate the
skill descriptions. Always cite the specific records you based the diagnosis on.
Step 4: Offer the next step
If the fix is a spec change, hand off to edit-spec. If it's promoting guidance to a linter
rule, hand off to strengthen. If a behavioral claim needs measuring (does the skill fire
now?), hand off to test-harness (measureTriggerRate).
FAQ
What does the debug-my-harness skill do?
Diagnose why an agent harness misbehaved by reading the local flight-recorder ledger (.vigiles/runs.jsonl) — which skills fired or got hijacked, which hooks blocked or wrongly allowed, which subagent tool-contract violations happened, and how a skill's trigger rate moved. Use when asked why a skill stopped firing, why a hook didn't block, why the wrong skill ran, or to debug/investigate what the harness actually did. NOT for writing new rules (use strengthen) or editing the spec (use edit-spec).
How do I install debug-my-harness?
Run npx skills add https://github.com/zernie/vigiles --skill debug-my-harness in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/debug-my-harness/ (personal) or .claude/skills/debug-my-harness/ (project).
Which AI agents can use debug-my-harness?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is debug-my-harness safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains debug-my-harness?
It is published by zernie in zernie/vigiles. It has 1,542 recorded installs.
More from zernie/vigiles
edit-spec
zernie/vigiles
Edit a vigiles .spec.ts to change a compiled instruction file (CLAUDE.md / AGENTS.md) — add, modify, or remove a rule, section, command, or file pointer (including a request to add a "key file" — the keyFiles field is deprecated). Use whenever you need to change a CLAUDE.md/AGENTS.md that carries a vigiles hash (edit the spec, never the artifact), including adding a new enforce()/check()/guidance() rule.
strengthen
zernie/vigiles
Upgrade a vigiles spec's guidance() rules to enforce() — scan the guidance rules in a CLAUDE.md/AGENTS.md spec and find existing linter rules (ESLint, Ruff, Clippy, Pylint, RuboCop, Stylelint) that back them. Use when asked to strengthen, harden, or make vigiles rules enforceable; NOT for general linting or fixing lint errors.
test-harness
zernie/vigiles
Install vigiles and test a Claude Code harness — hooks, skills, agents, settings, CLAUDE.md — by picking the right tier (unit / deterministic / eval) and writing a test that passes. Use to check that a hook fires or blocks, that a skill triggers, that injected context lands; or to observe a run — which tools it called, whether it stayed inside its declared allowed-tools, what files and side effects it produced, how to intercept a call without executing it.
linter-docs
zernie/vigiles
Deep linter reference for authoring or debugging a vigiles enforce() rule — plugin tables, AST selectors, type-aware rules, auto-fix, and edge cases for ESLint, Ruff, Pylint, RuboCop, Stylelint, and Clippy. Use when you need the exact rule name or config for a specific linter, not for running a linter. (JVM/Go linters — detekt, ktlint, Checkstyle, golangci-lint — and Cedar have no deep-dive file yet; their reference lives in docs/linter-support.md.)
adopt-spec
zernie/vigiles
Adopt a typed .spec.ts for an existing hand-written CLAUDE.md — start from the file you already have, non-destructively
deep-research
zernie/vigiles
Use when the user asks to research a topic in depth, map a competitive/market landscape, run a multi-source investigation, or "fan out" parallel research agents — anything where many findings must be gathered and then NOT lost. Enforces durable, detail-preserving research (write full findings to disk; keep a full appendix beside the synthesis).
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.