القائمة
Performance regression testing workflow for hot path changes
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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%]