Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

tsz-performance-engineering

Sterne443

Forks8

Aktualisiert2. Juni 2026 um 05:23

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.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

mohsen1

mohsen1/tsz

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

3 Dateien

SKILL.md

readonly

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

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: Project Corpus Impact, invariant, exact commands/CI, green row timing only, RSS/failure-class evidence for runtime blockers, counter deltas, noise/caveats, AgentName.

Mehr aus diesem Repository

gleiches Repository

tsz-architecture

mohsen1/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-02443

tsz-ci-pr

mohsen1/tsz

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-02443

tsz-conformance

mohsen1/tsz

Triage and maintain TSZ diagnostic conformance. Use when investigating conformance regressions, accepted-regression drift, fingerprint-only failures, issue creation from conformance data, or focused parity fixes that must preserve the conformance gate.

2026-06-02443

tsz-disk-cache-hygiene

mohsen1/tsz

Prevent TSZ machines and worktrees from running out of disk while preserving useful build caches. Use before creating worktrees, running large builds/tests, diagnosing low disk, cleaning artifacts, deciding whether to delete caches, or recovering space without slowing future Rust/TypeScript builds.

2026-06-02443

tsz-iteration-audit

mohsen1/tsz

Audit TSZ repo iteration speed and quality. Use when asked to deep-dive repo health, identify avoidable delays, improve agent workflows, reduce CI/PR churn, add guardrails, choose skills to install or create, or turn recurring TSZ process failures into focused tooling/docs PRs.

2026-06-02443

tsz-pr-coordination

mohsen1/tsz

Create, refresh, and publish TSZ pull requests with correct coordination state. Use when opening a draft PR, updating a PR body, applying canonical agent labels, changing WIP/draft/ready state, acknowledging review, handing off readiness to a manager agent, or making sure a TSZ PR satisfies AgentName, Project Corpus Impact, verification, and overlap rules.

2026-06-02443

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

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: Project Corpus Impact, invariant, exact commands/CI, green row timing only, RSS/failure-class evidence for runtime blockers, counter deltas, noise/caveats, AgentName.