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 tt-a1i/matt-skills-with-to-goal --skill setup-ts-deep-modulesgit clone --depth 1 https://github.com/tt-a1i/matt-skills-with-to-goalWrote 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/tt-a1i/matt-skills-with-to-goal/setup-ts-deep-modules)<a href="https://agentmods.dev/skills/tt-a1i/matt-skills-with-to-goal/setup-ts-deep-modules"><img src="https://agentmods.dev/badge/skills/tt-a1i/matt-skills-with-to-goal/setup-ts-deep-modules/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/tt-a1i/matt-skills-with-to-goal/setup-ts-deep-modules"><img src="https://agentmods.dev/badge/skills/tt-a1i/matt-skills-with-to-goal/setup-ts-deep-modules.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.00044 | $0.01823 |
| Opus 5 | $0.00022 | $0.00911 |
| Sonnet 5 | $0.00009 | $0.00365 |
| Haiku 4.5 | $0.00004 | $0.00182 |
Grade A, and why
setup-ts-deep-modules 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 12d 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.
This is a copy
91% identical to setup-ts-deep-modules — 48 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Setup TS Deep Modules
Make every package in this repo a deep module: a lot of behaviour behind a small interface. A package's public surface is its entry points — the files at the package root — and everything in its subfolders is hidden. This skill installs dependency-cruiser and the rules that make the entry points the only way in, then proves the rules bite.
For the vocabulary (deep module, interface, seam, depth), run the /codebase-design skill — use its language throughout.
The shape this enforces
src/packages/
<name>/
index.ts ← an entry point (public). Import this from outside.
client.ts ← another entry point. Packages may expose SEVERAL.
lib/ ← implementation: hidden from outside, free to import each other.
tests/ ← co-located tests + fixtures (a subfolder, so private).
The public surface is the package's root files — not one designated index.ts. By convention implementation lives in lib/ and tests in tests/, giving every package the same two-folder shape. The rule itself is general, though: anything in any subfolder is private, so you never extend the config to add a folder.
Four rules, all error:
- Entry-point boundary — code outside a package (app code or another package) may import only that package's entry points (its root files), never anything in its subfolders.
- Intra-package freedom — a package's own files import each other freely.
- Tests through the entry points — files under
<pkg>/tests/may import any package's entry points and their owntests/fixtures, but never any package's subfolder internals (not even their own). Integration tests across packages are fine; deep imports are not. - No cycles — no dependency cycles.
Entry points, not a barrel. Because the public surface is every root file, a package can expose several small entry points (index.ts, client.ts, server.ts) instead of funnelling everything through one giant index.ts. Barrel files that re-export a whole subtree are discouraged — keep entry points small and hide implementation in subfolders.
What ships with it
2 files 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.
- 12d ago First seen · 103 lines · 44 tokens per session scan A 2c6e39ccdd77
setup-ts-deep-modules is a skill published in the GitHub repository tt-a1i/matt-skills-with-to-goal (160 stars, last pushed 15d ago), licensed MIT. It adds 44 tokens to every session and 1,823 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 91% identical to setup-ts-deep-modules, differing in 48 lines, and is treated as a copy.
Other skills, from other repositories
ts-debug
TypeScript/Node debugging expert. Use when the user needs to debug, profile, or trace TypeScript or Node.js code — e.g. "how do I debug this", "find the memory leak", "why is this slow", "add a breakpoint", "profile this function", "why won't the process exit".
typescript-conventions
Use when writing, reviewing, or refactoring TypeScript or JavaScript code — naming conventions, type annotations, private fields, null vs. undefined, async/await pitfalls, and module structure.
nestjs-patterns
NestJS architecture patterns for modules, controllers, providers, DTO validation, guards, interceptors, config, and production-grade TypeScript backends.
bun-runtime
Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
effect-v4
Write, review, or upgrade Effect v4 code in the Composio CLI, cli-keyring, and json-schema-to-effect-schema packages, all pinned exactly to [email protected] — Context.Service and explicit layers, Schema.TaggedError and typed recovery, the effect/unstable/cli command surface, and the vendored effect source oracle.…
typescript
TypeScript strict mode with eslint and jest.