Security audit
Security checks for vulnerabilities and agentic risk
This skill gives cautious refactoring instructions and does not include hidden code, credential access, persistence, or unrelated behavior.
Install this if you want an agent to refactor code conservatively with tests and verification. Be aware that vague requests like "clean this up" may route to this workflow, so use explicit wording when you want a bug fix or feature change instead of a behavior-preserving refactor.
The trigger phrase "clean this up" is broad and can cause the skill to activate for vague requests that may not clearly mean a behavior-preserving refactor. In an agent system, over-broad activation can route tasks into the wrong workflow, causing unintended code changes or bypassing more appropriate skills that would ask for clarification first.
The phrase "do it" is context-dependent and insufficiently specific to safely trigger a refactor skill on its own. If an upstream architecture or planning step suggested multiple possible actions, this could cause the agent to execute code changes without confirming exactly which proposal the user approved.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
6. **Renames are grep-verified, not assumed.** After renaming or moving a symbol, grep for the old name repo-wide — including strings, configs, reflection sites, docs, and serialized names (JSON keys, DB column mappings, API routes). Zero hits or each remaining hit justified in one line. Dynamic-dispatch and reflection usages don't break the build; the grep is the only net they have.
- ❌ "Renamed `getUser` to `fetchUser`; build is green, done." — the build can't see the `"getUser"` string in the route table.
- ✅ "Renamed; repo grep for `getUser` returns 2 hits: a CHANGELOG entry (historical, left) and `routes.json:14` (updated)."
7. **The assertion-change tripwire.** If any step makes an existing test fail and the "fix" would be changing that test's assertion, expected value, or setup — **stop**. That is the definition of a behavior change wearing a refactor's clothes. Surface it: quote the old and new behavior, ask whether the change is intended. Only test changes allowed without asking: mechanical renames mirroring step 6, and import/path updates.
- ❌ Silently updating `expect(total).toBe(107.10)` to `109.31` mid-refactor because "the new rounding is more correct."
- ✅ "Step 4 changes the rounding point, which alters totals on multi-line invoices (old: 107.10, new: 109.31). That's a behavior change, not a refactor — proceed with old behavior preserved, or split this into a follow-up?"
8. **Final proof.** Full suite + build, summaries quoted. Then re-read the complete diff once, adversarially, hunting for the behavior change you smuggled in without noticing — reordered side effects, a dropped `await`, a widened catch, changed default parameter, iteration-order dependence, log lines something might parse. Report: contract (each item → covering test), steps taken, grep results for renames, and anything intentionally left un-refactored with a one-line why.
No suspicious patterns detected.