Performance

Performance

Handle $ARGUMENTS.

Use this when a Plate plan claims speed, responsiveness, large-document readiness, or production performance. This skill owns the review shape around cohorts, repeated-unit budgets, p95/p99 interactions, memory/DOM tags, degradation contracts, native editor behavior, trace proof, and RUM gaps. It delegates React/Next micro-tactics, effect law, and complexity analysis to the skills that already own them.

Owner Map

Rule: if the plan only says "use React best practices", "avoid O(n)", or "seems fast locally", it is not done.

Required Output

Record this in the active plan or review:

### Performance

- applicability: applied | skipped
- Vercel rules used:
- extra rules used:
- repeated unit:
- cohorts:
- budgets:
- React/runtime primitives:
- interaction metrics:
- trace/CWV proof:
- memory tags:
- degradation contract:
- dashboard/RUM gap:
- plan delta:

Keep it short. If this pass cannot change the plan, write the no-change defense with evidence.

Quick Pass

1. Segment the workload into normal, large, stress, and pathological cohorts.
2. Name the repeated unit: block, row, cell, leaf, decoration, overlay, island, listener, or subscription.
3. Set current and target budgets for DOM nodes, components, handlers, effects, subscriptions, allocations, layout reads/writes, and memory per repeated unit.
4. Simplify the normal path before adding special modes.
5. Move rare state out of the repeated unit: comments, menus, hover chrome, selection tools, debug panels, context actions.
6. Add O(1) indexes or cached lookups only where the hot path proves repeated scans.
7. Choose the degradation contract for aggressive modes: native, DOM-present staged, shell island, virtualized, or model-backed.
8. Instrument p50/p75/p95/p99 interaction rows by cohort and mode.
9. Record browser trace proof and production/RUM tags when the claim matters outside the lab.

Done. The review has a workload, a unit budget, an interaction matrix, and a proof path.

Blockers

Stop the performance claim or mark the plan incomplete when any required answer is missing:

If a blocker does not apply, say why in one line. Silence is not a pass.

Vercel Rule Selection

Load exact Vercel rule files only when the code or plan needs them:

Use the Vercel rule name in Vercel rules used:. Do not copy its explanation unless the plan needs a specific quote-level constraint.

Extra Rules Owned Here

Load only the relevant rule files. These are the unique performance-lane questions.

Plate Example: Huge Document 10k

Use this shape for a large-document Plate review:

### Performance

- applicability: applied
- Vercel rules used: rerender-derived-state, rerender-defer-reads, js-set-map-lookups
- extra rules used: cohort-segmentation, repeated-unit-budget, interaction-inp-matrix, memory-dom-tagging, editor-native-behavior-proof
- repeated unit: block
- cohorts: normal 100 blocks; large 1,000 blocks; stress 10,000 blocks; pathological 50,000 nested/mixed blocks
- budgets: per block <= 1 element component, 0 per-block global listeners, 0 per-block effects unless scoped by id/range, O(1) id/path lookup for hot interactions
- React/runtime primitives: fast render path and derived subscriptions; transitions only for non-urgent side panels, not editor typing
- interaction metrics: startup, first type, middle type, range select, paste, undo, table range select by p50/p75/p95/p99
- trace/CWV proof: Browser trace for load/hydration if route claim is included; editor interaction trace for typing/select/paste latency
- memory tags: heap, DOM nodes, mounted block count, listener count, subscription count, node-id/cache size
- degradation contract: native DOM-present editing for normal/large; any staged or virtualized mode must list browser find/copy/paste/select-all/IME/undo/collab behavior
- dashboard/RUM gap: tag interaction name, cohort, document size, mode, browser, mobile, IME, release, heap/DOM sample when available
- plan delta: add missing rows before claiming the 10k path is ready

That is enough to review a huge-document claim without rereading the entire performance rule set.

Slate Plan Performance Pass

When used inside slate-plan, record this lens in the implementation review matrix.

Must answer:

• Which Vercel rules cover the micro-tactics?
• Which extra rule files from this skill apply?
• What is the repeated unit and current/target budget?
• Which cohorts are normal, large, stress, and pathological?
• Which interaction-level INP rows or lab proxies prove responsiveness?
• Which memory tags prove heap/DOM/component/listener/subscription counts stay bounded?
• Which degradation mode applies only to which cohort?
• Which native browser behaviors are preserved or intentionally degraded?
• Which React 19.2 primitive applies, and what does it explicitly not solve?
• Which Chrome trace or Core Web Vitals proof is relevant, and which load metrics are out of scope?
• What Datadog/RUM view would catch the regression?

No-Change Defense

If the performance pass changes nothing, write:

### Performance

- applicability: skipped
- reason:
- evidence:
- residual risk:

The reason must cite current plan evidence. "No obvious perf issue" is not evidence.