← ClaudeAtlas

chameleon-explainlisted

Use when the user explicitly invokes /chameleon-explain to drill down on one enforcement rule (its calibration, would-block frequency, inline-override rate), to replay what chameleon knew and did the last time a file was edited (post-incident gap analysis), or to look up one shelved review finding by match_key
crisnahine/chameleon · ★ 9 · AI & Automation · score 74
Install: claude install-skill crisnahine/chameleon
# /chameleon-explain Three drill-downs share this command, dispatched on the argument shape: - `/chameleon-explain <rule>` — explain one enforcement rule: why it's active or demoted, how often it would have blocked real edits, how often the team overrode it. The drill-down behind the `/chameleon-status` enforcement summary. - `/chameleon-explain <file>` — replay what chameleon knew and did the last time that file was edited, and classify why the gate stayed silent. The recovery loop for a postmortem. - `/chameleon-explain <match_key>` - drill into one shelved review finding by its match_key (the 64-hex digest listed under `/chameleon-status`'s "Shelved findings" item). The recovery loop for guidance chameleon noticed but never delivered. A 64-character lowercase hex argument is a shelved-finding match_key, not a rule or a file: run the **shelved finding** flow. Dispatch: if the argument names an existing file (or looks like a path - has a `/`, a known source extension, or matches a file in the repo), run the **file** flow. Otherwise treat it as a rule name and run the **rule** flow. With no argument, explain every rule that has activity (rule flow). --- # Rule flow: `/chameleon-explain <rule>` Explain a single enforcement rule for the active repo: why it's active or demoted, how often it would have blocked real edits, and how often the team overrode it with inline `chameleon-ignore`. Usage: `/chameleon-explain <rule>` (e.g. `/chameleon-explain import-preference-violati