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 elbwalker/walkerOS --skill walkeros-debugginggit clone --depth 1 https://github.com/elbwalker/walkerOSWrote 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/elbwalker/walkeros/walkeros-debugging)<a href="https://agentmods.dev/skills/elbwalker/walkeros/walkeros-debugging"><img src="https://agentmods.dev/badge/skills/elbwalker/walkeros/walkeros-debugging/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/elbwalker/walkeros/walkeros-debugging"><img src="https://agentmods.dev/badge/skills/elbwalker/walkeros/walkeros-debugging.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Prompt Injection · line 66 Large whitespace padding was detected (a block of blank lines or a long run of spaces). This can push injected instructions below or to the right of the visible area so a human reviewer never sees them while the agent still reads them. Manual review of the hidden content is recommended.Fix: Remove the large whitespace padding (blank-line blocks or long space runs) and review any content hidden below or to the right of it. Keep skill files compact and reviewable so no instructions can be
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.00030 | $0.02408 |
| Opus 5.5 | $0.00012 | $0.00963 |
| Sonnet 5.5 | $0.00006 | $0.00482 |
| Haiku 4.5 | $0.00003 | $0.00241 |
Grade A, and why
walkeros-debugging 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 5d 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 — 338 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging walkerOS Events
Quick Diagnosis
| Symptom | Likely Cause | Check |
|---|---|---|
| No events at all | Source not initialized | Console for errors, verify startFlow() |
| Events fire but destination silent | Mapping mismatch | Event name matches mapping? |
| Partial data missing | Path doesn't exist | Log event structure, check nested paths |
| Consent blocking | Required consent not granted | Check consent config, grant consent |
| Destination error | Vendor API issue | Check network tab, vendor console |
Debugging Strategies
1. Console Logging
Log all events at collector level:
import { startFlow } from '@walkeros/collector';
const { elb } = await startFlow({
destinations: {
debug: {
push: async (event, context) => {
console.log('[walkerOS Event]', {
name: event.name,
data: event.data,
context: event.context,
consent: event.consent,
timestamp: event.timestamp,
});
},
config: {},
},
// ... other destinations
},
});
2. Network Tab Inspection
For destinations that make HTTP calls:
- Open DevTools → Network tab
- Filter by destination domain (e.g.,
google-analytics.com,facebook.com) - Trigger event
- Inspect request payload
What to look for:
- Request being made at all?
- Correct endpoint URL?
- Payload structure matches vendor spec?
3. Vendor Debug Tools
| Vendor | Debug Tool |
|---|---|
| GA4 | GA4 DebugView |
| Meta | Facebook Pixel Helper |
| Plausible | Plausible Dashboard real-time |
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.
- 5d ago Changed d08fa9c04556
- 12d ago Changed · -5 lines c7cb58b46d54
- 13d ago Changed d30a2a8a9faa
- 18d ago Changed · +2 lines ff96c68182a2
- 27d ago Changed · +44 lines 60f6fc36661a
- 1mo ago First seen · 297 lines · 30 tokens per session scan A 53fa55b7b149
walkeros-debugging is a skill published in the GitHub repository elbwalker/walkerOS (347 stars, last pushed today), licensed MIT. It adds 30 tokens to every session and 2,408 once invoked, about $0.0001 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-30.
Other skills, from other repositories
migrate-oxlint
Guide for migrating a project from ESLint to Oxlint. Use when asked to migrate, convert, or switch a JavaScript/TypeScript project's linter from ESLint to Oxlint.
resolving-ingestion-warnings
Diagnoses and resolves PostHog ingestion warnings — problems recorded while ingesting events (dropped events, rejected person merges, oversized payloads, invalid data). Use when a user asks why events are missing, dropped, or undercounted, why identify/alias calls don't work or accounts stay duplicated, why person or…
exploring-llm-traces
Debug and inspect LLM/AI agent traces using PostHog's MCP tools. Use when the user pastes a trace or session URL (e.g. /ai-observability/traces/ or /ai-observability/sessions/ ), asks to debug a trace, figure out what went wrong, check if an agent used a tool correctly, verify context/files were surfaced, inspect…
investigating-error-issue
Investigates a single PostHog error tracking issue end-to-end. Use when the user provides an issue ID or pastes an issue URL (/error-tracking/ ) and wants to understand the error — who it affects, what triggers it, when it started, whether it correlates with a release, browser, OS, or feature flag, and what the next…
debugging-experiments
Debug and support PostHog Experiments (A/B tests) for a customer looking at their own results. Use whenever an experiment support ticket is pasted or a customer asks a results question, most commonly "why aren't my exposures even?", "why is one variant getting no traffic?", "why am I missing / seeing too few…
grouping-noisy-errors
Consolidate PostHog error tracking issues that are the same actual error reported under different fingerprints. Use when the user asks "why do I have so many TypeError issues that look the same?", "merge these duplicates", "stop splitting this error into new issues", or wants to clean up fingerprint sprawl. Decides…