DOCS · REFERENCE · COMMANDS · SHIP

performance-audit/synthex:performance-audit

Ship

Quantified analysis across frontend, backend, db, infra.

Invocation

Run from inside Claude Code in any project where Synthex is installed:

/synthex:performance-audit

Some commands accept parameters; see the source-of-truth file linked below for the full parameter list and workflow.

Lifecycle phase

Ship. Performance, observability, and ops audits.

  • Tech Lead · Full-stack orchestrator. Breaks tasks down, delegates to specialists, rolls up the result.
  • Lead Frontend Engineer · Coordinates frontend delivery, enforces UX quality, accessibility, and design-system fidelity.
  • Security Reviewer · Mandatory gate. Secrets, injection, auth, supply chain, OWASP.
  • Terraform Reviewer · Plan review with cost, blast-radius and security verdict for AWS.
  • Performance Engineer · Quantified, full-stack performance analysis with budgets.
  • SRE · SLOs, observability, runbooks, deployment risk, postmortems.
  • Technical Writer · API docs, guides, migrations, changelogs verifiable against code.

Source

The command's parameters, workflow, and sub-agent invocations are defined in markdown at bluminal/lumenai/blob/main/plugins/synthex/commands/performance-audit.md.

Last modified:

What it does, end-to-end

performance-audit/synthex:performance-audit has the Performance Engineer agent measure your bottlenecks, compare them to budgets, and rank fixes by impact and effort. Every finding comes with real numbers — "LCP is 4.2s, target is < 2.5s", not "the page is slow".

  1. Loads config for review-loop settings.

  2. Routes to a standing pool, if one is running and standing_pools.enabled is true (see Host notes).

  3. Confirms sandbox-yolo CLIs. If any external CLI in the run is configured with sandbox-yolo permissions, it warns once per CLI and asks Continue audit with sandbox-yolo CLI(s)? [y/N]. The default is no; non-interactive runs abort without prompting. In the default safe configuration this step is skipped.

  4. Resolves scope:

    ScopeWhat's analyzed
    frontendCore Web Vitals, bundle size, rendering, asset optimization
    apiResponse times, payload sizes, N+1 queries, connection pooling
    databaseQuery performance, indexing, connection management, schema efficiency
    full-stackAll of the above

  5. Gathers context — your project instruction file (AGENTS.md, CLAUDE.md, GEMINI.md, or .hermes.md) if the host didn't already load it, package.json, any existing performance budgets or benchmarks, and your deployment target (Vercel, AWS, self-hosted).

  6. Runs the Performance Engineer with the scope, url, project context, and any available data (Lighthouse reports, APM data, slow-query logs).

  7. Optimization loop. If any CRITICAL or HIGH findings exist, it shows them ordered by impact/effort and waits for you to optimize. Then a fresh Performance Engineer re-audits with a one-line summary of each unresolved finding. It stops when none remain or max_cycles is reached. MEDIUM-only findings don't trigger the loop. It never applies fixes itself.

  8. Presents the final audit.

Parameters

ParameterDescriptionDefaultRequired
scopeArea to audit: frontend, api, database, or full-stackfull-stackNo
urlURL to audit for frontend performance (Core Web Vitals)NoneNo
config_pathPath to synthex project config.synthex/config.yamlNo
--profile <tier>Override models.profile (economy, balanced, premium) for this runmodels.profile config (balanced)No

The agent's model resolves in this order: --profile, then models.agents.<name>, then the models.profile delta, then the agent's own frontmatter. A profile change doesn't affect a standing pool — pools never re-spawn their reviewers.

Configuration

KeyDefault
performance_audit.review_loops.max_cyclesInherits review_loops.max_cycles (2)
performance_audit.review_loops.min_severity_to_addressInherits review_loops.min_severity_to_address (high)
models.profilebalanced
standing_pools.enabledfalse
standing_pools.routing_modeprefer-with-fallback
standing_pools.matching_modecovers
lifecycle.submission_timeout_seconds300

Output

The audit is printed to the console (no file is written). It contains an executive summary, a Performance Budget Status table (LCP, INP, CLS, JS bundle size, API p95 against budget, each PASS/FAIL), findings with category, current and target values, estimated impact in concrete units (ms, KB, queries), recommendation, effort (S/M/L), and evidence. Frontend scope adds a Bundle Analysis table; database work adds a Database Analysis table. It ends with an Optimization Priority Matrix (P1–P3) and Caveats that separate lab measurements from field data.

Examples

/synthex:performance-audit
/synthex:performance-audit frontend https://staging.example.com
/synthex:performance-audit api --profile premium

Host notes

Standing-pool routing. When standing_pools.enabled is true in .synthex/config.yaml (the legacy .synthex-plus/config.yaml is still read for one major version, with a deprecation warning), the command looks for a running pool whose roster covers performance-engineer. If one matches, it prints Routing to standing pool '<name>' (multi-model: yes|no)., submits one task, and returns the pool's report with a Review path: standing pool ... line on top — skipping the local audit. With the default prefer-with-fallback routing mode, no match means a normal local audit. With explicit-pool-required, it stops and tells you to start a matching pool with /synthex:start-review-team --reviewers performance-engineer.

No subagent tool. If the host has no Agent, Task, task, spawn_agent, or delegate_task tool, the Performance Engineer role runs inline in your session instead.

Plugin root. On hosts other than Claude Code, the plugin root comes from .synthex/state.json.

See also