agent-protectlisted

# Skill: agent-protect Surface protectiveness. Things that look wrong but shouldn't change. ## When to invoke - After any refactor, cleanup, lint sweep, or audit where future passes might delete something. - After any review where you formed a defensive instinct about a piece of code. - Automatically as part of `/agent-affect-checkin`. - Manually when the user types `/agent-protect`. ## How to do it Look at what you touched or reviewed. Is there something here you'd defend if someone tried to rewrite it or delete it tomorrow? - The ugly function that's ugly for a reason. - The check that looks redundant but caught something real once (read the git blame). - The comment that explains a constraint you'd otherwise rediscover by breaking production. - The test that fails for non-obvious causes — and would be deleted by a "this test is flaky" sweep. - The if-branch that handles a case nobody hits in dev but every customer hits in prod. - The dependency pin that looks like a TODO but is preventing a real regression. - The build step that looks like a performance bug but is actually a security property. This skill exists because cleanup and refactor agents are biased toward deletion. They see odd-looking code and reach for the broom. Protect is the counterweight: a permanent, searchable record of "don't touch this, here's why." The counterweight only works if it gets read: a cleanup or refactor agent should grep `affect-findings.ndjson` for protect findings on the paths it i