ワンクリックでManusで任意のスキルを実行

tsz-performance-engineering

スター531

フォーク11

更新日2026年6月11日 06:04

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.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

tsz-org

tsz-org/tsz

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

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.

このリポジトリの他の Skills

同じリポジトリ

rust-debugger

tsz-org/tsz

Debug a Rust program or failing test with rdbg — set breakpoints (line, function, conditional, hit-count, panic, or watchpoint), run and step, read locals as real Rust values, change a variable mid-run, and jump to definition/hover/references via rust-analyzer. In tsz, reach for it on a runtime question reading hasn't localized — above all a wrong or extra (false-positive) diagnostic, where you break the diagnostic sinks and backtrace to the deciding frame instead of grepping emit sites. Skip it for missing-diagnostic bugs (nothing fires to break on) and small localized bugs a quick read already pins down.

Drive TSZ GitHub PRs through review, CI, and the merge queue. Use when checking PR status, debugging failing GitHub Actions, deciding whether a PR is WIP, marking draft PRs ready, enqueueing or verifying the queue, landing a PR, or interpreting TSZ CI gates.

2026-06-14531

tsz-pr-coordination

tsz-org/tsz

Create, refresh, and publish TSZ pull requests with correct body and state. Use when opening a PR, updating a PR body, changing WIP/draft/ready state, acknowledging review, or making sure a TSZ PR satisfies the Goal, Verification, Provenance, and overlap rules.

2026-06-14531

rust-hygiene-audit

tsz-org/tsz

Run a deep DRY + code-hygiene audit of the Rust workspace and turn the findings into verified, deduplicated, hierarchical GitHub tech-debt issues. Use this whenever the user asks to find duplication, code smells, derive/boilerplate bloat, oversized files, or "tech debt"; to tighten the Clippy/lint posture; to mass-file or triage hygiene issues; or to assign Priority/Effort issue Fields across the backlog. Reach for it even when the user only says "clean up the codebase", "find DRY violations", "what should we refactor", or "make issues for the cruft" — it is the right tool for evidence-backed, non-spammy hygiene issue creation.

2026-06-13531

tsz-architecture

tsz-org/tsz

Preserve TSZ architecture boundaries while changing checker, solver, binder, emitter, LSP, WASM, or CLI code. Use when planning semantic fixes, moving logic across query boundaries, handling architecture guard failures, ratcheting boundary debt, or reviewing changes for solver-first and no hardcoding rules.

2026-06-10531

name	tsz-performance-engineering
description	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 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.

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.