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 berekvolgyipeter/dotclaude --skill ts-debuggit clone --depth 1 https://github.com/berekvolgyipeter/dotclaudeWrote 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/berekvolgyipeter/dotclaude/ts-debug)<a href="https://agentmods.dev/skills/berekvolgyipeter/dotclaude/ts-debug"><img src="https://agentmods.dev/badge/skills/berekvolgyipeter/dotclaude/ts-debug.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.1 | $0.00068 | $0.01752 |
| Opus 5 | $0.00034 | $0.00876 |
| Sonnet 5 | $0.00014 | $0.00350 |
| Haiku 4.5 | $0.00007 | $0.00175 |
Grade A, and why
ts-debug 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 today.
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 — 150 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TypeScript Debugging
Not sure what's wrong? Start with the Node inspector — step through the code and observe. Once you can characterize the problem (slow, leaking memory, hanging), switch to the matching profiler.
| Problem | Tool |
|---|---|
| Need to step through execution interactively | node --inspect-brk + Chrome DevTools or VS Code |
| Need to step through a failing test | vitest --inspect-brk --no-file-parallelism |
| Which function is slow, and where does the time go? | node --cpu-prof, read as a flame chart in DevTools |
| Investigating memory growth or leaks | node --heap-prof, then v8.writeHeapSnapshot() |
| Process won't exit or hangs after work is done | process.getActiveResourcesInfo(), escalating to why-is-node-running for the creation stacks |
| Hard to read debug output (nested objects, long arrays) | console.dir(value, { depth: null }) |
Every Node flag above is stock — no build step, no loader, no dependency. why-is-node-running is the single gap worth a package: the built-in process.getActiveResourcesInfo() names the handle types holding the loop open but not where they were created. Run scripts/setup.sh to add it.
Behavioral Rules
- Lock the bug with a failing test once reproduced — before patching incorrect behavior, capture the faulty behavior as a regression test (through the public interface where one exists), so the fix is verified and the bug can't silently regress; skip this for pure performance or memory investigations, where a test through the public interface is rarely the right artifact
- Suggest only one tool per problem — don't list all options and ask the user to choose
- Explain the fit in one sentence before showing usage — e.g. "Since the process hangs after the work finishes,
why-is-node-runningis the right tool here." - Prefer the inspector as the default for general debugging; only reach for profilers when the problem is clearly performance- or memory-related
- Reach for a built-in before a dependency — adding a package to a project mid-investigation is a cost the user pays forever, so justify it
- Run the TypeScript source, not the build — stack frames and breakpoints land on the right lines with no source maps; only a compiled
node dist/…run needs--enable-source-maps - Place the
debuggerstatement just before the suspect line, not at the top of the function - Debug tests in a single worker —
--no-file-parallelism, otherwise breakpoints land in a worker thread the debugger isn't attached to - Never leave instrumentation in production code paths —
debuggerstatements,why-is-node-runningdumps, and heap-snapshot calls must be removed before deploying
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.
- today First seen · 150 lines · 68 tokens per session scan A 1a59c0720cc2
ts-debug is a skill published in the GitHub repository berekvolgyipeter/dotclaude (2 stars, last pushed yesterday), licensed MIT. It adds 68 tokens to every session and 1,752 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-09-06.
Other skills, from other repositories
javascript-sandbox
Best practices for using the clodex built-in JavaScript sandbox for browser debugging, fetched-data processing, attachments, and mini-app orchestration within its bundled capability boundary.
fix-typescript-build
How to fix a failing tsc/npm run build (type-check) run in a project, batching fixes into sprints to preserve context.
strict-typescript
Enforce strict TypeScript compiler settings and type narrowing patterns. Use when the user creates a new TypeScript project, configures tsconfig.json, encounters null/undefined errors, deals with indexed access issues, or asks about strict mode, type safety, or narrowing techniques.
typescript-circular-dependency
Detect and resolve TypeScript/JavaScript circular import dependencies. Use when: (1) "Cannot access 'X' before initialization" at runtime, (2) Import returns undefined unexpectedly, (3) "ReferenceError: Cannot access X before initialization", (4) Type errors that disappear when you change import order, (5) Jest/Vitest…
bun
Generate Bun project setup.
typescript-strict
Use this skill when writing or reviewing TypeScript code with strict mode in WrongStack. Triggers: user mentions "TypeScript", "strict", "type error", "type safety", "narrowing", "branded type", "discriminated union", "noUncheckedIndexedAccess".