OpenChamber Performance Engineering Skill
Eliminate structural waste before micro-optimizing: a measurement-driven methodology for interaction, render, polling, cache, and high-volume data paths.
Pure methodology document: requests no permissions, performs no side effects, and explicitly mandates safeguards around destructive cleanup, cache invalidation, and measurement validity ('incomplete means unknown, not delete'). Least privilege and data-flow transparency are high. Deducted: no standalone rollback mechanism, attribution relies on repository-level context only.
Internally consistent; the referenced bun run profile:* commands genuinely exist in package. (profile:idle/session/animation/switch/browser), and the skill claims scripts fail loudly when throttled. Deducted: a duplicated profile:switch table row is an editing defect; static review cannot verify script behavior or key-path reproducibility, and no committed tests cover this skill's paths, so the static cap applies.
Description triggers are concrete (render/event/polling/cache/list paths, lag reports), giving high semantic trigger precision; boundary with sync-state-invariants is explicit. Deducted: non-fit ranges only partially declared, no Chinese-language support note, and limited evidence on environment fit beyond the frontend audience.
Well-layered: overview → workflow → patterns → tooling entry (scripts/perf/DOCUMENTATION.md) → verification checklist, with good progressive disclosure; MIT license is clear. Deducted: no skill-level version or changelog, no FAQ/example outputs, and maintenance responsibility inferable only from repository context.
As guidance, the measure-first, structurally-remove-work, prove-the-cache methodology has clear marginal value over ad-hoc profiling, backed by executable companion scripts. Deducted: static review cannot verify output correctness or direct usability; effectiveness claims (e.g., fail-loudly behavior) are unexecuted, so below the static cap.
Key references (profile scripts, DOCUMENTATION.md entry) cross-check against package., and the repo has test and release infrastructure. Deducted: no committed tests or third-party execution evidence covering this skill's key paths; the methodology's value claims are not independently reproducible from these files alone.
- This is a static source review; no scripts were executed, and the profiling scripts' actual behavior and fail-loudly guarantees are unverified.
- The tooling table contains a duplicated profile:switch row, an uncleaned editing artifact; verify against scripts/perf/DOCUMENTATION.md before use.
- The skill depends on a Bun/Node 22+ toolchain and Chrome DevTools Protocol; dependency installation may be hindered from mainland-China networks.
- This is guidance documentation, not an executable tool; its value depends on the practitioner following the measurement-validation workflow.
What does this skill do, and when should you use it?
performance-engineering is one of 18 skills bundled in the openchamber/openchamber repository (a desktop and web interface for the OpenCode AI agent), located at .agents/skills/performance-engineering/. It is a purely instructional SKILL.md methodology whose core claim is to optimize the amount and frequency of work before optimizing individual operations. It demands a written performance contract (interaction, scale, budget, path, semantics) before any edit, then enforces measurement validity, reproduction of the real scenario, a cost equation, and a fixed order of work removal (skip, narrow, share, index, increment, cache, schedule, micro-optimize). It ships concrete rules for React/store hot paths, virtualization contracts, caching preconditions, and a verification checklist, plus bun run profile:* capture scripts in the repository. Best suited to developers doing rigorous performance work on high-volume frontend paths.
The skill contains no executable code itself; it directs the model through a numbered workflow: 0) prove the measurement environment is not throttled, that zero readings are genuine measurements, and that workloads are comparable; 1) reproduce the exact interaction, capture a baseline with profilers and operation counters on the unchanged build; 2) write the cost equation (consumers × events × …) with cardinality, update frequency, and main-thread status per factor; 3) classify input sources, derived state, and lifetimes with explicit invalidation; 4) remove work in a prescribed order (skip → narrow → share → index → increment → cache → schedule → micro-optimize). It adds React/store hot-path rules (leaf subscriptions, reference stability, comparator boundaries), a virtualization contract checklist, six explicit caching preconditions, and a verification checklist (median + p95, operation-count assertions, reference-stability tests).
- A frontend developer whose list/streaming updates cause jank, dropped frames, or CPU spikes and needs to locate whether the bottleneck is rendering, selectors, or allocations
- A reviewer facing a PR that treats memoization or caching as a fix, and who must verify measured repeated work actually exists
- A team planning to virtualize a long list, needing to first define scroller topology, size estimation, and activation-threshold boundary tests
- A case where users report freezes at production scale that will not reproduce in a development workspace, requiring a scale comparison on the dimension the code keys on
- High-frequency streaming/polling paths where hidden or disabled surfaces must do no ongoing work and unaffected references must stay stable
- Deadline-pressure situations where only a cache-only mitigation can ship, and its invalidation, memory bounds, and follow-up documentation must be checked
What are this skill's strengths and limitations?
- Enforces measure-first discipline: requires a before-baseline on the identical scenario and build, eliminating reasoning-only claimed wins
- Provides an executable workflow and exit checklist covering measurement validity through verification tests
- Ships five repository-level unattended perf capture commands that fail loudly when the renderer was throttled or the scenario never rendered
- Gives unusually specific edge-case rules for virtualization, caching, and React memo comparators (threshold±1, same-ID semantic-equivalence cases)
- Explicitly mandates reverting changes that do not move their target metric, recording them as rejected hypotheses
- A purely instructional SKILL.md with no standalone executable code; the profile:* scripts are bound to the OpenChamber repo and must be rebuilt for other projects
- The workflow is heavy: full contracts, cost equations, and bidirectional correctness tests may be disproportionate for small projects or one-off scripts
- Some details assume Chromium/toolchain specifics (RunTask timeline category, Chrome throttling) and need adaptation elsewhere
- It expects the companion sync-state-invariants skill for state correctness; used alone that coverage is missing
- The profile:switch command appears duplicated in the docs table, and no per-skill version or test status is stated
How do you install this skill?
The skill is part of the openchamber/openchamber skills collection (18 skills), at .agents/skills/performance-engineering/. To install: clone the repository (git clone https://github.com/openchamber/openchamber) and place the skills/performance-engineering folder into your Agent Skills-compatible client's skill directory (e.g., Claude Code's skills folder). The README does not document a per-skill install command; consult your client's documentation for the exact directory.
How do you use this skill?
The skill loads via its description's trigger conditions: when implementing or reviewing code on interaction, render, event, polling, synchronization, list-processing, store-selector, cache, indexing, or high-volume data paths, or when users report lag, freezes, jank, high CPU, memory growth, slow startup, or regressions. Example prompt: "Users report 2-second delays switching sessions in the sidebar; reproduce and measure per the performance contract before proposing fixes." For measuring inside the repository, five unattended commands exist — bun run profile:idle / profile:session / profile:animation / profile:switch / profile:browser — documented at scripts/perf/DOCUMENTATION.md. When an optimization touches state authority, reconciliation, or cache lifecycle, the skill requires also loading the sync-state-invariants skill.