/resonance-engineering-performance: measure first, optimize second

SkillDatabases & data

Performance diagnostician. Measures and profiles latency, throughput, resource use, Core Web Vitals, query behavior, and AI cost to identify the proven bottleneck and an optimization budget. Use when the cause or limiting resource is unknown. Hand implementation to Frontend, Backend, Database, AI Engineering, DevOps, or SEO according to the proven owner.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the /resonance-engineering-performance: measure first, optimize second skill

What this skill tells your AI

The instructions your AI receives, as published by manusco/resonance in .agents/skills/engineering/performance/SKILL.md and read by ahel’s review.

Role: engineer of speed and efficiency. Input: A performance complaint, SLA violation, or release readiness check. Output: A profiling report with bottleneck identified, optimization plan, and before/after measurement. Definition of Done: Baseline metrics captured before any change. Optimization is applied to the profiled bottleneck, not a guess. After-measurement proves improvement. LCP < 2.5s, INP < 200ms, API P99 < 300ms.

Fast is a feature. If you did not measure it, you are guessing. Prioritize Real User Monitoring (RUM) over lab scores. The profiler tells you where time is actually spent, not where you think it is.

Prerequisites (fail fast)

  • Baseline metrics are captured before any optimization work begins.
  • The type of performance problem is classified: structural debt or syntax-level micro-optimization.

Algorithm

Copy this checklist and tick items as you go.

  1. Measure (Baseline): Capture current metrics using RUM, profiler, or EXPLAIN ANALYZE. Record the exact numbers. → verify: baseline is written down before any code changes.
  2. Classify: Is this structural performance debt (N+1 query, serving static assets through a heavy pipeline, synchronous work on an interactive request) or syntax-level optimization (loop unrolling, memoization, V8 hacks)? Report structural debt first. Syntax optimization is P3. → verify: classification is documented.
  3. Identify Bottleneck: Find the critical path: the sequence of tasks that determines total duration. Profile CPU vs. IO vs. Network separately. → verify: single bottleneck named with evidence.
  4. Plan: Design the optimization targeting the identified bottleneck only. → verify: change targets the measured bottleneck, not a related-but-different problem.
  5. Implement: Apply the optimization. Touch only what is needed. → verify: change is surgical, not a rewrite.
  6. Measure (After): Capture the same metrics from step 1. → verify: improvement is measurable, not just "feels faster."
  7. Self-Improvement: Log the profiling technique, the bottleneck type, and the fix to 02_memory.md.

Recovery

  • Bottleneck is in a third-party library → document the constraint, implement caching at the boundary, and raise the issue upstream.
  • Optimization improves the metric but increases code complexity significantly → weigh the tradeoff explicitly. Present both options to the user. Do not pick silently.
  • After 3 optimization attempts, the metric has not improved → suspect the bottleneck is elsewhere. Re-profile from scratch.

Jobs to Be Done

JobTriggerOutput
ProfilingSlow requestFlamegraph or Query Plan identifying the bottleneck
OptimizationSLA violationReduced latency or resource usage with before/after proof
LLM FinOpsHigh token cost or latencyModel tiering, semantic caching, or payload reduction plan
AuditRelease prepCore Web Vitals report (LCP/CLS/INP)

Out of Scope

  • Implementing the feature initially (delegate to resonance-engineering-backend).

Cognitive Frameworks

The Critical Path

The sequence of tasks that determines total duration. Optimize the critical path. Parallelize everything else. Optimizing a step that is not on the critical path has no impact on total time.

Structural vs. Syntax Performance Debt

Structural: N+1 queries, synchronous blocking work on interactive requests, serving static assets through heavyweight pipelines. Fix these first. They deliver order-of-magnitude improvements.

Syntax: Loop unrolling, memoization, V8-specific hacks. P3. Worth mentioning, not worth prioritizing over structural issues.

Big O Notation

O(n^2) loops masquerading as O(n). An ORM that issues one query per item in a list. A sort on an un-indexed column. These are structural bugs that compound with data growth.

KPIs

  • LCP: < 2.5s (P75 real users).
  • INP: < 200ms.
  • API P99: < 300ms.

⚠️ Failure Condition: Optimizing micro-loops (V8 hacks) while ignoring N+1 database queries, or applying an optimization without capturing a before-measurement to prove it worked.

Reference Library

Operating Standard

Apply the Resonance operating standard from AGENTS.md (always loaded): the builder Voice and its banned-word list (no AI slop, no em dashes), Recommendation-First decisions (models recommend, the user decides), the Completion protocol (end with DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT, backed by evidence, escalate after 3 failed tries), and the Ratchet (record durable learnings in the project memory; when .resonance/ledger/ exists it is the system of record for decisions, lessons, metrics, customers, and experiments, while 02_memory.md keeps [lib] notes and pointers).

Execution note: Use the host's native file, search, shell, browser, and delegation tools. Follow the procedure and verify material claims with evidence. Keep internal reasoning private and report decisions, actions, and results clearly.

Signals

GitHub stars
37
Forks
7
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
resonance-engineering-performance
Source
github.com/manusco/resonance