Menu
Workflow for modifying and benchmarking detection rules
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | rule-optimize |
| description | Workflow for modifying and benchmarking detection rules |
Use after modifying rules in default_rules.yaml (loaded by src/rules/).
cargo test to verify no regressionsRUSTFLAGS="-C target-cpu=native" cargo build --release./target/release/scanner-rs ../linux ../gitleaks ../tigerbeetle ../trufflehog
When adding or modifying rules:
sgp_, hvs., AKIA) over service name keywords[a-fA-F0-9]{40} that match git SHAscargo bench --bench rule_isolation -- <rule_id>.* followed by greedy quantifiersBefore making changes, capture baseline:
# Run 3x and record median throughput
for i in 1 2 3; do
./target/release/scanner-rs ../linux 2>&1 | tail -1
done
After changes, compare:
# Calculate % change
# Acceptable: <2% regression
# Investigate: 2-5% regression
# Block: >5% regression without justification
bench-compare - Criterion benchmark comparisonperf-regression - Full performance regression workflowtest-strategy - Choose testing approach for rule changesWrite-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