Burn down critical security findings
Run your static analyzer on the security ruleset, fix one high-severity finding at a time, re-verify, and loop until zero remain or 10 turns pass.
/loop run the repo's static analyzer (semgrep, CodeQL, or whatever is already configured) with the security ruleset; take ONE finding — highest severity first — and fix it minimally, then re-run the analyzer to verify the finding is gone and run the test suite. Never suppress or downgrade a rule to make a finding disappear; anything that needs a design change gets flagged for human review instead. Continue until the analyzer reports zero findings at high severity — stop after 10 turns and propose the fixes as one PR.
claude-code
Source: looprepograded A · 100/100 — how grades work →
More security loops
Secrets scan until clean
Run a secrets scanner over the working tree and drive the findings to zero: real secrets get flagged for rotation, false positives get baselined.
/goal `gitleaks detect --no-git` reports zero findings — for each finding, tell me whether it looks like a real credential (flag it for rotation and replace it with an env var lookup) or a false positive (add it to the baseline with a comment); never print the secret value itself; stop after 8 turns
Audit the system from evidence
Read-only pass that verifies architecture, security, platform behavior, ops, and business logic from current evidence, not assumptions.
Audit [project] from its actual code and configuration, not framework assumptions. For architecture, platform compatibility, security, privileged areas, performance, deployment, jobs, business logic, and code quality, record proved, no issue, weak, or N/A with direct evidence; verify external limits from current primary sources and calculate numbers. Ask before changing code. Stop when every area is logged with severity, or return unverified areas as blocked. Finish with a plain-language overview and area-to-evidence table.
Weekly dependency vulnerability audit
Every Monday morning, run the dependency vulnerability audit, open one PR fixing what auto-fix can handle safely, and file issues for the rest.
/schedule every Monday at 8am, run `npm audit`, open a single PR applying only non-breaking fixes with tests passing, and file one issue per remaining high or critical advisory with its CVE link and affected paths