How do I install the Tsz Performance Engineering skill?

Run npx skillmds@latest add tomevault-io/tsz-performance-engineering in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tsz Performance Engineering safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tsz Performance Engineering?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tsz Performance Engineering free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tsz Performance Engineering?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tsz Performance Engineering by tomevault-io

Name: Tsz Performance Engineering
Author: tomevault-io

Tsz Performance Engineering

Use when planning, implementing, reviewing, or interpreting TSZ performance work, including benchmark regressions, cache/residency changes, timing claims, perf counters, hotspot investigations, OOM/timeout/stack-overflow blockers, or optimization PR evidence.

tomevault-io Updated Sep 17, 2026

File contents

TSZ Performance Engineering

Use for performance, cache/residency, OOM/timeout/stack-overflow, counters, benchmark regressions, and timing claims.

Rules

Read AGENTS.md, docs/plan/ROADMAP.md, and relevant PR/issues.
Correctness first. Timing claims matter only for green rows or explicit runtime/residency blockers.
Optimize the repeated operation, not a fixture spelling.
State invariant: cache key, invalidation/reset, request scope, fuel/cycle behavior, residency bound, or complexity change.
No checker-local semantic algorithms, display-string heuristics, source-text shortcuts, name allowlists, or cross-interner TypeId comparisons.
Read references/perf-mistakes.md before adding/widening caches, changing residency, or claiming speedups.

Evidence

Use narrow, reproducible commands; wrap heavy runs.

python3 scripts/perf/cache-visibility-report.py --json
python3 scripts/perf/visited-clone-report.py --json
python3 scripts/perf/debug-print-report.py --json
python3 scripts/perf/migration_callsite_counts.py --json
python3 scripts/perf/query-perf-counters.py --json <artifact> --baseline <baseline>
scripts/safe-run.sh ./scripts/bench/perf-hotspots.sh --quick --json-file /tmp/hotspots.json
scripts/safe-run.sh ./scripts/bench/bench-vs-tsgo.sh --filter '<row>' --json-file /tmp/bench.json
scripts/bench/measure-tsz.sh --timeout 420 --json-file /tmp/m.json -- --noEmit -p <tsconfig>

Use focused compile guard or cargo nextest run -E 'test(...)' when shortest. Do not run full conformance, emit, fourslash, or broad project suites locally.

For ad-hoc timing or perf bisects on shared boxes, use scripts/bench/measure-tsz.sh: it snapshots the binary to an immutable hash-verified copy (never time the live dist-fast/ path — sibling sessions overwrite it) and records process CPU time next to wall time, so wall-only timeouts under CPU contention are reported as unmeasured instead of slow. See references/perf-mistakes.md and issue #13174.

Cache Checklist

What semantic question is cached?
What stable identity is the key? Avoid cross-file NodeIndex and cross-interner TypeId.
Does the key include all behavior modes: relation, variance, freshness, contextual typing, inference source, any, target/module/options, request scope, cycle/fuel, file/session generation?
Where is reset/invalidation?
What happens cold/disabled/order-randomized?
Is size/residency bounded or observable?

PR/comment packet: goal (usually fast) and affected rows, invariant, exact commands/CI, green row timing only, RSS/failure-class evidence for runtime blockers, counter deltas, noise/caveats.

Source: mohsen1/tsz — distributed by TomeVault.

---name: tsz-performance-engineeringdescription: Use when planning, implementing, reviewing, or interpreting TSZ performance work, including benchmark regressions, cache/residency changes, timing claims, perf counters, hotspot investigations, OOM/timeout/stack-overflow blockers, or optimization PR evidence.---# TSZ Performance EngineeringUse for performance, cache/residency, OOM/timeout/stack-overflow, counters,benchmark regressions, and timing claims.## Rules- Read `AGENTS.md`, `docs/plan/ROADMAP.md`, and relevant PR/issues.- Correctness first. Timing claims matter only for green rows or explicit runtime/residency blockers.- Optimize the repeated operation, not a fixture spelling.- State invariant: cache key, invalidation/reset, request scope, fuel/cycle behavior, residency bound, or complexity change.- No checker-local semantic algorithms, display-string heuristics, source-text shortcuts, name allowlists, or cross-interner `TypeId` comparisons.- Read `references/perf-mistakes.md` before adding/widening caches, changing residency, or claiming speedups.## EvidenceUse narrow, reproducible commands; wrap heavy runs.```bashpython3 scripts/perf/cache-visibility-report.py --jsonpython3 scripts/perf/visited-clone-report.py --jsonpython3 scripts/perf/debug-print-report.py --jsonpython3 scripts/perf/migration_callsite_counts.py --jsonpython3 scripts/perf/query-perf-counters.py --json <artifact> --baseline <baseline>scripts/safe-run.sh ./scripts/bench/perf-hotspots.sh --quick --json-file /tmp/hotspots.jsonscripts/safe-run.sh ./scripts/bench/bench-vs-tsgo.sh --filter '<row>' --json-file /tmp/bench.jsonscripts/bench/measure-tsz.sh --timeout 420 --json-file /tmp/m.json -- --noEmit -p <tsconfig>```Use focused compile guard or `cargo nextest run -E 'test(...)'` when shortest.Do not run full conformance, emit, fourslash, or broad project suites locally.For ad-hoc timing or perf bisects on shared boxes, use`scripts/bench/measure-tsz.sh`: it snapshots the binary to an immutablehash-verified copy (never time the live `dist-fast/` path — sibling sessionsoverwrite it) and records process CPU time next to wall time, so wall-onlytimeouts under CPU contention are reported as unmeasured instead of slow.See `references/perf-mistakes.md` and issue #13174.## Cache Checklist- What semantic question is cached?- What stable identity is the key? Avoid cross-file `NodeIndex` and cross-interner `TypeId`.- Does the key include all behavior modes: relation, variance, freshness, contextual typing, inference source, `any`, target/module/options, request scope, cycle/fuel, file/session generation?- Where is reset/invalidation?- What happens cold/disabled/order-randomized?- Is size/residency bounded or observable?PR/comment packet: goal (usually `fast`) and affected rows, invariant, exactcommands/CI, green row timing only, RSS/failure-class evidence for runtimeblockers, counter deltas, noise/caveats.---> Source: [mohsen1/tsz](https://github.com/mohsen1/tsz) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions