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 Samuel0101010/wisp-orchestrator --skill wisp-diagnosegit clone --depth 1 https://github.com/Samuel0101010/wisp-orchestratorWrote 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/samuel0101010/wisp-orchestrator/wisp-diagnose)<a href="https://agentmods.dev/skills/samuel0101010/wisp-orchestrator/wisp-diagnose"><img src="https://agentmods.dev/badge/skills/samuel0101010/wisp-orchestrator/wisp-diagnose/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/samuel0101010/wisp-orchestrator/wisp-diagnose"><img src="https://agentmods.dev/badge/skills/samuel0101010/wisp-orchestrator/wisp-diagnose.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.00077 | $0.00820 |
| Opus 5.5 | $0.00031 | $0.00328 |
| Sonnet 5.5 | $0.00015 | $0.00164 |
| Haiku 4.5 | $0.00008 | $0.00082 |
Grade A, and why
wisp-diagnose scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -s "http://127.0.0.1:${WISP_PORT:-4400}/api/runs/<runId>/events?limit=500" How it starts
The opening of the file, as written. The whole thing — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
WISP — Diagnose Run
Inspect a run's event timeline to figure out what failed and why.
Platform note: snippets below show both bash and PowerShell forms. Pick the one matching the user's shell. The bash form also runs from Git Bash / WSL on Windows.
Inputs
- runId: the run UUID. Ask the user if not provided.
Steps
-
Fetch the events:
# bash curl -s "http://127.0.0.1:${WISP_PORT:-4400}/api/runs/<runId>/events?limit=500"# PowerShell $port = if ($env:WISP_PORT) { $env:WISP_PORT } else { 4400 } Invoke-RestMethod -Uri "http://127.0.0.1:$port/api/runs/<runId>/events?limit=500"Response:
{"events": [{"type":"...", "payload":..., ...}, ...]}ordered oldest-first. -
Show the timeline, condensed: print one line per event of interest. Skip noisy types (
task.text-delta,task.usage— print usage totals at the end instead). Format:<timestamp> <event type> <task id> <one-line summary> -
Highlight failures: for each
task.failed,harness.verify-failed,qa.replan-triggered,qa.replan-exhausted,rate-limit.hit,run.pausedevent, print the FULL payload (not a one-liner). Especially:harness.verify-failed.payload.failures[*]— kind, cmd, exitCode, tailharness.verify-failed.payload.output— full output (truncate to last 100 lines if huge)qa.replan-triggered.payload.reason— what QA reported
-
Token & duration totals: query
/api/runs/<runId>to get the per-task token/turn totals. Print as a small table. -
Verdict: in 1-2 sentences, summarise WHY the run failed (or what it's currently stuck on). Quote a specific event payload as evidence.
Useful event types to know
| Type | Means |
|---|---|
task.started |
A task subprocess began |
task.completed |
The subprocess returned (regardless of verify result) |
harness.verify-failed |
The verify gate (build/test/lint/custom/preflight) rejected the task; full failures + output payload |
task.failed |
Terminal failure; subsequent dependent tasks were cancelled |
qa.replan-triggered |
M5 — QA failure caused the walker to swap in a new plan |
qa.replan-exhausted |
M5 — replan cap hit OR replan callback returned null |
rate-limit.hit |
A subprocess hit a Claude rate limit; usually followed by run.paused |
run.paused |
Walker paused (rate-limit / user / shutdown / consecutive-failures) |
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 · 61 lines · 77 tokens per session scan A 98f764366250
wisp-diagnose is a skill published in the GitHub repository Samuel0101010/wisp-orchestrator (4 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 77 tokens to every session and 820 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
postmortem
Auto-generates a structured postmortem from a completed campaign. Reads the campaign file, telemetry logs, and feature ledger. Produces a documented analysis of what broke, what the safety systems caught, and what patterns emerged. Can also be invoked manually for any incident.
systematic-debugging
4-phase root cause analysis: observe, hypothesize, verify, fix. Enforces investigation before any code changes. Emergency stop after 2 failed fixes. Prevents shotgun debugging and fix cascades.
root-cause
Find the mechanism behind a failure instead of patching its symptom - reproduce first, one variable per experiment with the prediction written before the run, exit by naming the mechanism and pinning it with a failing test. Use for a bug, an unexplained red test, or a failure that will not reproduce.
claude-md-drift-check
Use when detecting drift between CLAUDE.md (or AGENTS.md, the Codex CLI alias) / meta narrative and live repository state. Ten checks: absolute-path resolution, 01-projects/ count claims, issue-reference freshness, session-file existence, command-count sync, session-config-parity (mandatory template keys = error…
discovery
Use this skill when running systematic quality discovery and issue detection. Runs modular probes adapted to the project's tech stack, presents findings interactively for user triage, and creates VCS issues for confirmed problems. Invoked standalone via /discovery or embedded in session-end.
debug
Use when encountering any bug, test failure, build break, or unexpected behavior — runs a 4-phase systematic debugging process before proposing any fix. Iron Law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. Produces a .orchestrator/debug/ artifact the fixer agent must reference.