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
claude-code · codex
Implementation note
Rotation itself stays human-owned: the loop replaces and flags but never sees rotation flows. The never-print rule keeps credentials out of the transcript.
More security loops
Cadence: weekly. you are my expectation-gap auditor. read…
Community loop loop for security, sourced from submission. Verified exit condition, evaluator-gated.
/loop cadence: weekly. you are my expectation-gap auditor. read expectation-gap-STATE.md: gaps found, pages fixed, tickets already processed. pull the week's support tickets and refund reasons [Zendesk MCP / your support export]. each round, take ONE "i thought" moment where the customer expected something the product doesn't do; find the sentence on my site that planted the expectation and log both side by side. for the pain that cost the most (refunds, angriest tickets), draft the page fix (exact promise) or flag me if the product should change instead. append pairs, sources and the drafted fix to expectation-gap-STATE.md; never edit shipped pages yourself, draft only. verification: a round is valid only when the pair and drafted fix are appended and readable in expectation-gap-STATE.md. stop after 15 iterations, or until every new gap this week is logged, whichever comes first; if the support source is unreachable, BLOCK and say so.
Burn down CVEs by reachability
Rank dependency CVEs by reachability and exposure, apply one bounded fix, and verify the whole project before moving on.
Scan the dependencies of [authorized project or current repository] for known CVEs using current advisory sources. If you cannot access the dependency graph, repository, or current advisories, report the blocker and stop. For each high or critical finding, identify the affected direct or transitive dependency, determine whether the vulnerable code is reachable, and check whether the exploit conditions exist in this project. Rank findings by severity, reachability, exposure, and available remediation. Patch or upgrade the highest-risk reachable dependency using the smallest credible change. Run the build, tests, and security scan again. Keep the change only if verification passes and no unacceptable regression appears. Repeat until no exploitable high or critical CVE remains, or every remaining finding has an evidence-backed reachability assessment and an approved risk decision. Ask before major or breaking upgrades, production changes, or accepting risk. Finish with the CVE inventory, reachability evidence, fixes, verification results, and remaining risks.
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.