Menu
Workflow for modifying and benchmarking detection rules
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 | 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 changes