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/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/berekvolgyipeter/dotclaude/ts-debug"><img src="https://agentmods.dev/badge/skills/berekvolgyipeter/dotclaude/ts-debug.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.00068 | $0.01752 |
| Opus 5.5 | $0.00027 | $0.00701 |
| Sonnet 5.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 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.
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.
- 1mo ago 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 9d ago), licensed MIT. It adds 68 tokens to every session and 1,752 once invoked, about $0.0003 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-09-06.
Other skills, from other repositories
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-best-practices
TypeScript best practices. Use when reading or editing any .ts or .tsx file.
node-modern
Use this skill when writing, reviewing, or refactoring Node.js code — modules, async flow, cancellation, file and process I/O, HTTP — on a current Node.js release. Triggers: user mentions "Node", "Node.js", "ESM", "CommonJS", "require", "import", "fetch", "AbortSignal", "AbortController", "stream", "childprocess"…
typescript-strict
Use this skill when writing, reviewing, or fixing TypeScript where type safety matters — type errors, narrowing, unsafe casts, or tightening compiler strictness. Triggers: user mentions "TypeScript", "type error", "tsc", "strict", "type safety", "narrowing", "any", "unknown", "discriminated union", "branded type"…
angular
Use when building, refactoring, or debugging Angular (v20/21+): standalone components, signals, zoneless change detection, @if/@for/@defer control flow, inject() DI, resource()/httpResource(), RxJS interop, NgRx SignalStore, ng CLI. NOT React (that is react), NOT Next.js (that is nextjs), NOT a TypeScript language…
phaser-pixi-2d-games
Use when building a 2D web game with Phaser (3.x/4.x) or PixiJS 8 in TypeScript - framework vs renderer, Phaser scenes/game objects/arcade physics/groups as pools/scale manager/loader, scene shutdown cleanup, PixiJS 8 async init, Assets bundles, ticker units and destroy, and keeping rules in plain TS modules.