Menu
Performance regression testing workflow for hot path changes
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Write-then-verify documentation pipeline. Use when a user asks to improve comments or docs, explain algorithms or design choices, write or upgrade docstrings, or raise documentation quality for a codebase (especially Rust crates). Writes docs, then automatically verifies every claim against code reality using a fresh agent to eliminate confirmation bias.
Use when you have code review findings, PR comments, or review reports that need to be systematically addressed — especially when there are multiple findings across different files and severities
Use when creating any beads task — auto-researches the codebase, links related tasks, and produces a rich self-contained description from a structured template. Accepts minimal intent and outputs a complete task ready for agent implementation.
Use when you have code review findings, PR comments, or review reports that need to be systematically addressed — especially when there are multiple findings across different files and severities
Use when a task needs an implementation plan that is iteratively created and stress-tested through review-and-revise cycles before implementation begins — catches blind spots, incorrect codebase assumptions, unnecessary complexity, and performance pitfalls while changes are still cheap
Use when a markdown plan file exists and needs validation before implementation — catches design flaws, logic holes, footguns, unnecessary complexity, and performance concerns while changes are still cheap
| name | perf-regression |
| description | Performance regression testing workflow for hot path changes |
IMPORTANT: Follow this workflow before merging any feature that touches hot paths (src/engine/, regex changes, validation logic).
Invoke this skill when modifying:
src/engine/ modules (scratch.rs, stream_decode.rs, work_items.rs)src/stdx/default_rules.yaml or src/rules/git stash push -m "feature-name"
RUSTFLAGS="-C target-cpu=native" cargo build --release
for i in 1 2 3; do
./target/release/scanner-rs ../gitleaks 2>&1 | tail -1
./target/release/scanner-rs ../linux 2>&1 | tail -1
./target/release/scanner-rs ../tigerbeetle 2>&1 | tail -1
done
Record average throughput for each repository.
cargo bench --bench scanner_throughput -- --save-baseline before
cargo bench --bench vectorscan_overhead -- --save-baseline before
git stash pop
RUSTFLAGS="-C target-cpu=native" cargo build --release
# Same scan loop as step 2
for i in 1 2 3; do
./target/release/scanner-rs ../gitleaks 2>&1 | tail -1
./target/release/scanner-rs ../linux 2>&1 | tail -1
./target/release/scanner-rs ../tigerbeetle 2>&1 | tail -1
done
# Compare against baseline
cargo bench --bench scanner_throughput -- --baseline before
cargo bench --bench vectorscan_overhead -- --baseline before
Calculate average throughput delta per repository:
% change = (after_throughput - baseline_throughput) / baseline_throughput * 100
| Regression Level | Action |
|---|---|
| None (<2%) | Ship as-is |
| Minor (2-5%) | Document reason, acceptable for correctness |
| Moderate (5-10%) | Requires compelling justification |
| Major (>10%) | Must investigate and optimize |
Include in PR description:
Report results as:
## Performance Regression Results
### Scan Throughput
| Repository | Baseline | After | Delta |
|------------|----------|-------|-------|
| gitleaks | X MB/s | Y MB/s | +/-Z% |
| linux | X MB/s | Y MB/s | +/-Z% |
| tigerbeetle | X MB/s | Y MB/s | +/-Z% |
### Criterion Benchmarks
[Paste relevant benchmark comparison output]
### Verdict
[None/Minor/Moderate/Major] regression - [justification if >2%]