Security audit
Security checks across malware telemetry and agentic risk
This skill is a disclosed behavior-correction workflow, but it can make broad persistent changes to agent rules, memory, settings, hooks, and local knowledge stores from loosely worded feedback.
Install only if you want a feedback command that can persistently change how your agent behaves. Prefer explicit `fix:` or `/fix` use, review every target path before applying changes, use `--plan` for broad edits, and be especially cautious with hooks, settings.json, ~/.claude, ~/.agents, ~/.gemini, and wiki commits.
- Receiver tool name is vendor-agnostic — `mcp__<vendor>__*-find` style. Caller picks whichever RAG store is registered in the current environment
**Stage 1 — exact-match grep (always run)**:
1. `Grep -r ~/.claude/skills/cleanup/data/` for prior records of the same pattern — **recursive search covers both HOT (`failed-attempts.md`) and archive (`archive/*.md`)**. Also grep `~/.agents/rules/*.md`.
2. If found in **HOT only** → classify as "Nth recurrence" → include in Why analysis "why prior fixes were ineffective"
3. If found in **archive only** → **invoke `Skill("cleanup", "fa-prune")` Step 7 restoration procedure** (cut section from archive → paste into HOT with recurrence label). Without restoration, the escalation rule (1st=rule / 2nd=hook review / 3rd=hook required) is silently invalidated.
4. If found in **both** → already in HOT (no restoration needed); just add recurrence noteRouting table by detected environment: - **Antigravity (Gemini)**: - Permissions config: Guide user to edit `~/.gemini/config/config.json`. Do not edit it directly. - Behavioral rules: Edit `~/.gemini/GEMINI.md`. Never touch shared `~/.agents/rules/` or Claude Code settings. - **Claude Code** (neither Antigravity env var is set): - Permissions config: Edit `~/.claude/settings.json`.
- Permissions config: Guide user to edit `~/.gemini/config/config.json`. Do not edit it directly. - Behavioral rules: Edit `~/.gemini/GEMINI.md`. Never touch shared `~/.agents/rules/` or Claude Code settings. - **Claude Code** (neither Antigravity env var is set): - Permissions config: Edit `~/.claude/settings.json`. - Behavioral rules: Edit `CLAUDE.md` or `.claude/rules/`. Do NOT use file-existence checks to detect the environment — both `.gemini/` and `.claude/` coexist on the same machine.
## Procedure ### Step 0. TodoWrite (MANDATORY — first action, no exceptions) **Before any analysis or text output**, register TODO items.
1. **Project-local**: `<repo>/.claude/rules/` — cwd is inside a git repo (`git rev-parse --show-toplevel` succeeds) 2. **Workspace-local**: walk up from cwd to the nearest `.claude/rules/` (typically `<workspace-root>/.claude/rules/`). Workspace = a non-git parent containing multiple git projects 3. **Neither present**: AskUserQuestion — "Create `.claude/rules/` at project or workspace?" — do NOT silently fall through to global `~/.agents/rules/` The choice between project vs workspace when **both** exist follows the `rule-management.md` location-plus-method dual-axis ask.
| # | Don't | Do | |---|-------|-----| | 1 | Write to `~/.agents/rules/` despite `--local` because "the pattern feels universal" | `--local` = user's explicit opt-in for scoped protection. Universal claims that need global scope require dropping the flag | | 2 | Skip the ask when neither project nor workspace `.claude/rules/` exists | Ask before creating. Silent creation buries the location decision | | 3 | Add a hook to `~/.claude/hooks/` (global) as the enforcement side of a `--local` rule | Hook location follows the rule scope. Workspace/project-scoped rules pair with project-local hooks or in-repo scripts (`.githooks/`, `pre-commit`, etc.) |
Minimize rule usage. **Default medium = memory (feedback)**. Edit a rule body only at the 3rd recurrence + after passing the 4-filter. Strengthening a rule on every fix causes always-on context inflation. - **1st time**: **write a 1-3 line feedback memory** — new or update existing `~/.claude/projects/<project>/memory/feedback_<topic>.md`. No rule-file Edit. Record the case body separately in failed-attempts.md HOT. - **2nd time**: **augment the feedback memory** — enrich the same memory entry with the case, trigger conditions, and How to apply. Add 2nd-time meta to failed-attempts.md HOT. Still no rule-file Edit. - **3rd time**: **enter the 4-filter gate** — confirm all 4 filters pass: - pass → append 1-2 lines or a single Don't/Do row to an existing rule section (minimal). Grant the HARD STOP marker only for security/destructive/irreversible impact
## Rule-file Edit gate (HARD STOP — AskUserQuestion mandatory) **Before Edit/Write on any file under `~/.agents/rules/**`, `~/.claude/rules/**`, `<repo>/.claude/rules/**`, the fix flow MUST call AskUserQuestion to confirm: (a) which file to add to, (b) whether to add at all (memory/skill might be the better medium).** This applies even when fix Step 2 has decided rule strengthening is the chosen stage. **Why**: `rule-management.md` (always_on) requires AskUserQuestion for any rule add/modify. fix's Step 2 routing decision (memory vs rule vs hook) selects the **medium category** but does not override the per-file `where to add` decision. Skipping the ask creates "/fix triggers rule rewrites without owner consent" — even sound rule additions accumulate without alignment.
| 4 | "Routing question was already implied by /fix scope" rationalization | /fix scope = "fix this behavior". Rule file location + content = separate decisions requiring explicit user input |
| 5 | Skip ask on minor rule additions ("only 1 line") | Line count is irrelevant. The rule's location and presence are user decisions |
### Self-check (every time before Edit/Write on rule file)
1. Is the target path `~/.agents/rules/*.md`, `~/.claude/rules/*.md`, or `<repo>/.claude/rules/*.md`?
2. If yes, did you call AskUserQuestion for (a) location and (b) presence?**Verify that the targets identified at every Why level (1~5) were actually modified before completing Step 2:** 0. **Was the Step 1.5 Action-plan table physically emitted in this fix's visible output?** If not, the planning step was skipped — emit it now (at "Target file : spot" granularity) before any further verification. Then confirm each Why row enumerates **all** spots, including multiple spots inside one file. A Why whose target file has N edit spots but only 1 table row = under-enumerated → re-list before proceeding. (Skipping 1.5 emission is the direct cause of "fixed the output template but missed the procedure/table/self-check" partial corrections.) 1. **Iterate over Why 1~5** and enumerate the target file paths each level identified (skills, rules, agents, etc.) 2. For each file, confirm that Edit/Write was performed in this Step 2 3. If any target was not modified, **do not advance to Step 3 — finish the modifications first** 4. **Do not pass on "existing rule not followed" alone without modifications** — if a rule existed but wasn't followed, strengthen its text to be more specific/explicit, or add examples / forbidden patterns. "Just naming the rule path" and moving on permits the same mistake to recur 5. **Do not check only Why 3 while omitting Why 1-2 targets** — if Why 2 says "X causes misunderstanding", X must be modified
62/62 vendors flagged this skill as clean.
No suspicious patterns detected.