Performance Optimization Workflow

Strong dependencies (frontmatter): clarifying-question-discipline (one question per turn), known-issue-research (known performance-pattern quick search at the locate stage). If any is missing, abort and print: npx skills add FuDesign2008/open-skills -g --skill '*' --yes.

Runtime strong dependency (environment, not frontmatter): a loop-runner capability for the Stages 5-6 iteration loop — probed at Stage 5 entry; missing means optimization execution stops (see "Iteration loop").

Scope

This workflow owns the full performance optimization paradigm: build a reproducible benchmark, gate every conclusion through evidence-validity checks, attribute the bottleneck along the full chain, optimize one target per iteration, verify by A/B cross-run statistics, and sediment results in a benchmark log — the optimize↔verify cycle running on an environment-provided iteration loop (honest stop when absent). Its per-project deliverables: the benchmark log + harness, and two evolving project-level skills (code-insight for attribution, code-optimizer for optimization) that carry the stack/project knowledge and improve with every campaign.

It answers: who triggers what expensive operation, under which conditions, on which devices — and then eliminates it measurably. Shipping/rollout decisions belong to the project, not this workflow.

Paradigm provenance: distilled from two complete campaigns on different stacks (a native C++ toolchain: 29.4s → 6.7s workload, -77%, byte-identical outputs; a large web rich-text editor: -27% commit time / -31% render volume / -34% memory, plus a multi-year user-jank attribution closed in four paths). The stages below are the stack-agnostic skeleton both campaigns followed.

Layered architecture