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 agentmods add commands/mfmezger/ai_agent_dotfiles/typescript-engineeringgit clone --depth 1 https://github.com/mfmezger/ai_agent_dotfilesWhat 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 | $0.00118 | $0.00868 |
| Opus 5 | $0.00059 | $0.00434 |
| Sonnet 5 | $0.00024 | $0.00174 |
| Haiku 4.5 | $0.00012 | $0.00087 |
Grade A, and why
typescript-engineering 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 3d 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TypeScript Engineering
Produce TypeScript that is explicit at boundaries, narrow in surface area, and strict enough that refactors fail fast. Prefer inference inside small scopes, explicit types at module boundaries, runtime validation for external data, and simple control flow over clever type tricks.
Workflow
- Identify the boundary. Library: optimize for stable public types, portability, and narrow exports. Application: optimize for operability, runtime validation, and maintainable module boundaries.
- Model data before behavior. Prefer discriminated unions, branded/domain types, and small interfaces over optional-field soup.
- Decide where trust begins.
Treat network, env, file, CLI, and user input as
unknownuntil validated. - Keep types and implementation aligned. Prefer deriving types from values and functions over duplicating parallel definitions.
- Use async intentionally. Model failure and cancellation explicitly; avoid floating promises and hidden concurrency.
- Verify before finalizing. Run the project’s formatter, linter, type checker, and tests. Treat type errors as design feedback.
Load References By Need
| Need | Reference |
|---|---|
| Project shape, tsconfig, modules, exports, tooling | references/workflow.md |
| Boundary validation, error handling, async and promises | references/runtime-and-errors.md |
| API design, unions, narrowing, generics, utility types | references/types-and-api-design.md |
| React/TSX state, props, hooks, and event typing | references/react-and-tsx.md |
| Testing, mocks, fixtures, snapshots, review checklist | references/testing-and-quality.md |
| Performance, allocation, iteration, and common footguns | references/performance-and-footguns.md |
Default Standards
- Enable strict mode and keep it on.
- Prefer
unknownoveranyat trust boundaries. - Validate external data at runtime before treating it as domain data.
- Prefer discriminated unions over boolean mode flags and optional-field matrices.
- Keep exports intentional. Avoid giant barrel files that hide ownership and increase coupling.
- Return typed domain values from core logic; isolate framework types at the edges.
- Use
Promise<void>andawaitintentionally. Do not leave floating promises. - Prefer stable, readable types over maximally clever conditional-type machinery.
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.
- 3d ago First seen · 67 lines · 118 tokens per session scan A 9dfd547b4f1f
typescript-engineering is a command published in the GitHub repository mfmezger/ai_agent_dotfiles (5 stars, last pushed 1mo ago), licensed MIT. It adds 118 tokens to every session and 868 once invoked, about $0.0006 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-08-31.
Other commands, from other repositories
build-fix
빌드 에러를 자동으로 분석하고 수정합니다.
test-ts
Run TypeScript tests for Solana frontends and Anchor programs.
types
Debug and fix TypeScript type errors with systematic analysis and expert guidance.
setup-project
Initialize a new Bun + TypeScript backend project with best practices setup (Hono, Prisma, Biome, testing, Docker).
02-config
MCP server that serves deterministic, enterprise-grade prompts for rewriting any Node.js project to production-quality TypeScript. Supports http-api, library, cli, worker, and mcp-server project types.
05-validation
MCP server that serves deterministic, enterprise-grade prompts for rewriting any Node.js project to production-quality TypeScript. Supports http-api, library, cli, worker, and mcp-server project types.