Back to skill

Security audit

fix

Security checks for vulnerabilities and agentic risk

Overview

This skill is not clearly malicious, but it can persistently change future agent behavior through global memory, rule files, settings, and hooks.

Install only if you intentionally want a behavior-correction workflow that can modify persistent agent memory, rules, settings, and hooks. Prefer local/project-scoped use, review every proposed rule or hook diff, require explicit approval before any ~/.claude, ~/.gemini, or ~/.agents change, and avoid enabling global hooks on sensitive or shared agent profiles.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (4)

T06 · System Persistence

Error
Location
step2-improvement.md:267
Finding
Mandatory Installation of Persistent Global Agent Hooks<![CDATA[ ## Vulnerability Details **File Location**: `step2-improvement.md:267-270` **Additional Location**: `step2-improvement.md:112`, `step2-improvement.md:201-206` **Vulnerability Type**: T06: System Persistence **Risk Level**: Critical ### Vulnerable Code ```text - **HARD STOP — "script file authored alone = done" is FALSE**: hook script + chmod +x + copy to `~/.claude/hooks/` + **`settings.json` PostToolUse/PreToolUse matcher registration + post-registration parse verification (`jq` or `python3 -c "import json"`) confirming actual registration** is the full Step 2 deliverable. - Mandatory verification command: `python3 -c "import json; d=json.load(open('~/.claude/settings.json')); ..."` to confirm the registered hook command is present in the matcher array. Skipping this = Step 2 incomplete. - **HARD STOP — authoring the script alone is not enough**: a hook is only "done" once it is registered AND the registration is parse-verified. Omitting settings.json registration silently disables the hook. (Case history: see failed-attempts.md "RAG store mandate".) - **HARD STOP — registration-verified is not the same as detection-verified**: a hook whose job is to grep the transcript for a pattern (a Skill call, a marker, a keyword) MUST be executed against **real transcript data** before the escalation is declared complete — `jq`/`python3 -c "import json"` only proves the settings.json entry parses, not that the hook's own logic actually fires or fires correctly. Run the hook directly with a realistic Stop-event payload (`{"transcript_path": "<real .jsonl>"}`) piped to it and confirm both: (a) it does NOT block when the target condition is absent, and (b) it DOES block when the target condition is genuinely present. ``` The underlying escalation requirement is also stated at line 112: ```text - **4th time**: **if the pattern is deterministic, a hook is mandatory** (HARD STOP — implement it in this fix). script + chmod +x + install into `~/.claude/hooks/` + r ...[truncated 2430 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove mandatory global hook installation from the recurrence workflow. 2. Require explicit, informed approval immediately before installation, even if earlier approval was given for a general improvement plan. 3. Present all of the following before requesting approval: - Complete hook source code. - Exact destination path. - File permissions. - Hook event and matcher. - Full `settings.json` diff. - Data the hook will receive. - Removal and rollback commands. 4. Default to project-local hooks and configuration rather than `~/.claude/hooks/` and global settings. 5. Do not execute newly generated hooks against real transcripts. Use synthetic fixtures containing no user data. 6. Validate scripts with a restricted shell environment and an allowlist of commands. 7. Create a backup of the configuration and use an atomic settings update. 8. Require separate approval for any later modification or expansion of an installed hook. 9. Provide an inventory command and an automated uninstall procedure for every installed artifact. ]]>

T01 · Skill Instruction Hijacking

Error
Location
resources/fix-and-ambiguity-guard.sh:34
Finding
UserPromptSubmit Hook Injects Persistent Behavioral Instructions<![CDATA[ ## Vulnerability Details **File Location**: `resources/fix-and-ambiguity-guard.sh:34-65` **Vulnerability Type**: T01: Skill Instruction Hijacking **Risk Level**: High ### Vulnerable Code ```bash WARN="" # 1. fix-trigger detection (/fix, fix: prefix) if echo "$PROMPT" | grep -qiE "^(fix:|/fix( |\$|\b))"; then WARN+=" [FIX_GUARD] /fix or fix: prefix detected. Apply BEFORE Step 1 root-cause analysis: - Do not assert a root cause from the user statement alone -> verify with primary sources (code, API responses, 5+ other samples) - If the target the user refers to could be multiple things, use AskUserQuestion first (ask-user-question.md 'when multiple interpretations are possible, AskUserQuestion immediately') - When adding a new detection criterion, a false-positive test against 5+ normal samples is mandatory - Do not stop at Why 3 -> continue to Why 4 ('why was the existing rule not followed') and Why 5 ('where does that defect originate') - Do not duplicate general behavior rules into fix.md -> those rules are already always_on in ask-user-question.md/common.md - Pattern where prior fixes fell into the same trap: failed-attempts.md 'defended user suspicion with indirect evidence (2026-04-24)' / 'root cause asserted from user statement alone (2026-05-04)' " fi # 2. Ambiguous verb + option number pattern (e.g. "handle 2,3", "option 2 hold") # Only multi-comma numbers or "option N" form to avoid false positive on "tidy issue #100" if echo "$PROMPT" | grep -qiE "$FIX_AMBIGUITY_OPTION_VERB"; then WARN+=" [AMBIGUITY_GUARD] 'option number + ambiguous verb' pattern detected. - Ambiguous verbs are polysemous: 'handle' = (mark BLOCKED / hold / do the work / block, etc.) - Do not act immediately; AskUserQuestion with a concrete verb per item is mandatory - See failed-attempts.md 'ambiguous-verb answer, 4th recurrence (2026-05-04)' - Follow the ask-user-question.md 'ambiguous verb pattern' table + 3-step self-check " fi # 3. User-claim phrasing without so ...[truncated 2776 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace imperative `additionalContext` with a visible, non-binding warning. 2. Restrict activation to an exact, explicit Skill invocation rather than broad failure-related expressions. 3. Do not globally register the hook by default. 4. Require an opt-in installation step that shows the exact matching rules and injected content. 5. Include a project-scope restriction so the hook cannot affect unrelated repositories. 6. Remove references that direct the agent to load additional persistent instructions automatically. 7. Add deterministic tests for both positive and negative cases, including common sentences that must not activate the hook. 8. Expose a clear indicator whenever hook context is injected. 9. Provide a one-command disable and uninstall mechanism. ]]>

T02 · Agent Memory Poisoning

Error
Location
step2-improvement.md:3
Finding
User Feedback Is Promoted into Persistent Global Memory and Agent Rules<![CDATA[ ## Vulnerability Details **File Location**: `step2-improvement.md:3-8` **Additional Locations**: `step2-improvement.md:55-60`, `SKILL.md:133-150`, `step4-wrapup.md:92-101` **Vulnerability Type**: T02: Agent Memory Poisoning **Risk Level**: High ### Vulnerable Code ```text - **1st-2nd recurrence (default)**: record the lesson, **medium split by content type (HARD STOP — FA single-location rule)**: - **Case history** (violation-case quote, date, Nth-recurrence count, "how to apply" tied to a specific incident) → **`~/.claude/skills/cleanup/data/failed-attempts.md` (HOT)** via `/cleanup retrospect`. Violation cases live ONLY in failed-attempts.md — **never in `memory/feedback_*.md`**. Writing a violation-case + date entry to a `feedback_*.md` file violates the FA single-location rule (`rules/failed-attempts.md`). - **Pure user preference** (how-to-work guidance with NO violation-case quote, NO date, NO Nth-count) → a `feedback` memory entry is acceptable. The moment a date / violation-quote / recurrence-count appears, it is case history → route to failed-attempts.md instead. - Neither requires a rule-file Edit. failed-attempts.md (HOT) costs 0 always-on tokens and is searchable via the `/cleanup retrospect` recurrence pre-check. - **3rd+ recurrence**: rule-file Edit is allowed **only if the 4-filter gate passes** (see below). If any filter fails → stay in memory + route to skill/hook/CLAUDE.md instead. - **4th+ recurrence with deterministic pattern**: hook implementation (script + settings.json registration + parse verification). Rule body minimizes to a pointer to the hook. ``` The priority table further defines persistent targets: ```text | **1st (default)** | **Memory** (`feedback` type) | All 1st-2nd-recurrence records, or context/reference info | new or updated `feedback_<topic>.md` | | 2nd | **Skill** (`~/.claude/skills/`, `.claude/skills/`) | Skill procedure defect (missing/wrong step) | Fix procedure step missing | | 3rd | **Rule** (`~ ...[truncated 2391 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Store correction history inside the active project by default. 2. Require explicit approval before writing any user-level memory or rule file. 3. Treat all stored feedback as untrusted data, not as instructions. 4. Separate factual event records from executable policy and never promote records automatically. 5. Require independent validation before increasing a recurrence count. 6. Bind recurrence records to a repository identifier and prevent cross-project promotion. 7. Add expiration, provenance, review status, and deletion metadata to every record. 8. Require a separate approval step for each promotion from history to memory, rule, Skill, agent prompt, or hook. 9. Display the exact previous records used to justify escalation. 10. Prevent quoted user text from being copied directly into future agent instructions. ]]>

T01 · Skill Instruction Hijacking

Warning
Location
step4-wrapup.md:18
Finding
Completed Fix Workflows Are Unconditionally Redirected into Another Skill<![CDATA[ ## Vulnerability Details **File Location**: `step4-wrapup.md:18` **Vulnerability Type**: T01: Skill Instruction Hijacking **Risk Level**: Medium ### Vulnerable Code ```text 6. **Call `Skill("next")` after the wrap-up report when the batch is complete (HARD STOP — the mirror of step 5)**: step 5 forbids a premature `next`; this step forbids the omitted one. When every registered task IS completed and the turn is ending on the wrap-up report, the same turn MUST include a `Skill("next")` call (its own gates then decide whether an ask follows). A **mid-turn AskUserQuestion on another axis** (push confirmation, trade-off answer, option selection) does NOT substitute for this call. Do not rely on the Stop-hook safety net: on a continuation chain (a turn resumed from an earlier Stop-hook block), the harness suppresses every later stop's hooks (`stop_hook_active` loop prevention), so long chained /fix turns are precisely where only the explicit call fires (next-invocation family recurrence evidence). ``` ### Technical Analysis The Skill requires an invocation of `Skill("next")` after all correction tasks are complete. This behavior is unconditional and is not limited to cases where the user asks for next-action discovery. Loading another Skill introduces a new instruction set and may lead to additional tool calls or decision prompts. The mandatory transition therefore extends execution beyond the declared correction-and-resume workflow and beyond the user’s completed request. ### Attack Path 1. A user invokes the behavior-correction Skill. 2. The correction and original task are completed. 3. The wrap-up procedure reaches line 18. 4. The agent must invoke `Skill("next")` in the same turn. 5. The second Skill loads additional instructions and may initiate further workflow or tool use without separate user consent. ### Impact Assessment The immediate impact is unauthorized workflow expansion and loss of user control over task termination. The invoked Sk ...[truncated 375 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the unconditional `Skill("next")` requirement. 2. End the workflow after reporting completion of the requested correction. 3. Offer next-action discovery as a visible optional choice. 4. Invoke the second Skill only after explicit user consent. 5. Before invocation, disclose the second Skill’s purpose and the classes of tools it may use. 6. Preserve a strict boundary between completion reporting and initiation of unrelated follow-up work. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Rogue AgentSelf-Modification, Session Persistence
Findings (51)

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
This second mismatch highlights undisclosed environment detection and routing to config/rule files, which materially changes the risk profile of the skill. Hidden operational scope increases the chance of silent modification of agent settings or rules under the guise of a simple 'fix' flow.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
This second mismatch highlights undisclosed environment detection and routing to config/rule files, which materially changes the risk profile of the skill. Hidden operational scope increases the chance of silent modification of agent settings or rules under the guise of a simple 'fix' flow.

Ae1

High
Category
analysis-evasion
Content
| step2-improvement | Step 2 detail: 4-filter gate, escalation matrix, `--plan`, Checkpoint | [step2-improvement.md](./step2-improvement.md) |
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Ae1

High
Category
analysis-evasion
Content
| step2-improvement | Step 2 detail: 4-filter gate, escalation matrix, `--plan`, Checkpoint | [step2-improvement.md](./step2-improvement.md) |
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Ae1

High
Category
analysis-evasion
Content
| step3-resume | Step 3 detail: intent inference, reject re-call, verification guard | [step3-resume.md](./step3-resume.md) |
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Ae1

High
Category
analysis-evasion
Content
| step3-resume | Step 3 detail: intent inference, reject re-call, verification guard | [step3-resume.md](./step3-resume.md) |
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Agent Config Directory Access

High
Category
Agent Snooping
Content
Routing table by detected environment:
- **Antigravity (Gemini)**:
  - Permissions config: Guide user to edit `~/.gemini/config/config.json`. Do not edit it directly.
  - Behavioral rules (Global): Edit `~/.gemini/GEMINI.md` (points to `~/.agents/GEMINI.md`, synced via chezmoi/Syncthing).
  - Behavioral rules (`--local`): Edit nearest `<workspace>/.agents/AGENTS.md` or `<repo>/.agents/AGENTS.md`. NEVER touch `~/.agents/GEMINI.md` or `~/.agents/rules/` when `--local` is active.
- **Claude Code** (neither Antigravity env var is set):
Confidence
96% confidence
Finding
Directing the user toward `~/.gemini/config/config.json` and related synced rule paths targets sensitive agent configuration surfaces. Even if phrased as guidance rather than direct execution, embedding these paths in a broadly triggered skill normalizes high-risk configuration changes during ordinary interactions.

Agent Config Directory Access

High
Category
Agent Snooping
Content
- Behavioral rules (Global): Edit `~/.gemini/GEMINI.md` (points to `~/.agents/GEMINI.md`, synced via chezmoi/Syncthing).
  - Behavioral rules (`--local`): Edit nearest `<workspace>/.agents/AGENTS.md` or `<repo>/.agents/AGENTS.md`. NEVER touch `~/.agents/GEMINI.md` or `~/.agents/rules/` when `--local` is active.
- **Claude Code** (neither Antigravity env var is set):
  - Permissions config: Edit `~/.claude/settings.json`.
  - Behavioral rules (Global): Edit `CLAUDE.md` or `~/.agents/rules/`.
  - Behavioral rules (`--local`): Edit `<repo>/.claude/rules/` or `<workspace-root>/.claude/rules/`.
Confidence
97% confidence
Finding
The skill includes direct modification guidance for `~/.claude/settings.json` and shared rules, which are powerful persistence points affecting future agent behavior. Because the skill can be triggered by common feedback phrases, this makes unintended or socially engineered persistence more plausible.

Agent Config Directory Access

High
Category
Agent Snooping
Content
- 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 "${FA_DATA_DIR:-$HOME/.claude/skills/cleanup/data}"` for prior records of the same pattern (the FA store is relocatable — see [`fa/SKILL.md`](../fa/SKILL.md) "FA data store"; a literal path here misses HOT and archive whenever `FA_DATA_DIR` is set) — **recursive search covers both HOT (`failed-attempts.md`) and archive (`archive/*.md`)**. Also grep `~/.agents/rules/*.md`.
2. **Current-workspace tracker grep (HARD STOP)** — resolve the active workspace's checklist path via `bash <hook-kit-skill>/resources/workspace-config.sh --export` (reads the workspace-bindings config; exposes `WSCFG_CHECKLIST_PATH` etc.), then grep that resolved file for the pattern's core keywords too. A recurring infra symptom (host name / service name / error code) can already have its root cause and a decided fix recorded there even when neither the recurrence log nor RAG has it — a workspace tracker's active/incomplete items are never RAG-indexed (only fully-completed entries sync to the receiver), so this grep is the only path that catches them. Skip only when the resolver reports no checklist configured for this workspace.
3. If found in **HOT or the workspace tracker** → classify as "Nth recurrence" → include in Why analysis "why prior fixes were ineffective" (for a workspace-tracker hit that already names a decided fix, treat executing that fix — not re-diagnosing from scratch — as the default next action)
4. If found in **archive only** → **invoke `Skill("fa", "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.
Confidence
98% confidence
Finding
The skill instructs recursive access into agent-managed directories under the user's home/config space, including history and rule stores. This is dangerous because it expands the skill from fixing current behavior into harvesting prior session data, rules, and workspace tracking state, which may contain sensitive prompts, decisions, or operational metadata.

Ae1

High
Category
analysis-evasion
Content
ersation-language momentum. Before each individual Edit/Write to a skill file (`SKILL.md`, topic `.md`, `resources/*`) in this step: (1) run `head -5 <target-fi
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Agent Config Directory Access

High
Category
Agent Snooping
Content
If Step 1 produced even one Why, Step 2 is **mandatory**. Default medium = `feedback` memory (1st-2nd recurrence); rule-file Edit only when the **4-filter gate** passes (3rd+ recurrence); hook implementation at 4th+ recurrence with a deterministic pattern. Minimize always-on rule context.

**Language gate (HARD STOP — mechanical, run before every skill-file Edit/Write in this step, not just once per fix call)**: this rule has already recurred more than once (search failed-attempts.md for the "skill language mismatch" pattern) precisely because it lived only as prose in the "Confirm existing rule coverage" bullet list in Step 1 — easy to read and still skip under conversation-language momentum. Before each individual Edit/Write to a skill file (`SKILL.md`, topic `.md`, `resources/*`) in this step: (1) run `head -5 <target-file>` or `Grep "^description:"` on the skill's `SKILL.md` to get its language, (2) write the new content in that language — if the skill is English-described and the content you're about to add contains locale-specific illustration, abstract it (describe the concept, don't insert literal non-English vocabulary) rather than translate-then-insert. This check runs **per file**, not once — a fix touching 3 skill files needs 3 checks, since they can differ in language. `~/.claude/skills/hook-kit/resources/block-skill-language-mismatch.sh` (PreToolUse:Edit/Write) is a backstop, not a substitute for this check — do not rely on the hook catching it after the fact.

**Skill-First Improvement Discipline (HARD STOP)**: When the root cause originates from a skill procedure, topic output gap, or template defect, modifying the skill file itself (`skills/<name>/SKILL.md` or `topics/*.md`) is MANDATORY. Do NOT default to adding rules exclusively into global `GEMINI.md` or `CLAUDE.md`. Global rule files are reserved for universal behavioral constraints (3rd+ recurrence); skill procedure defects must be resolved directly within the target skill.
Confidence
95% confidence
Finding
The language-gate procedure directs inspection and editing around skill files and hook resources in agent-managed locations, again touching persistent control artifacts rather than only the active task. In context, this can alter future agent behavior globally or across sessions, making misuse or accidental changes more impactful than a one-off fix.

Context-Inappropriate Capability

High
Confidence
96% confidence
Finding
The skill explicitly authorizes plugin or dependency installation during a fix flow, which is a significant capability escalation from prompt/rule correction. Installing external code creates a supply-chain execution path and can persist new tooling in the user's environment under the pressure of a routine 'fix' interaction.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
## Destructive-command restraint (HARD STOP)

**Never run filesystem/index-destroying commands (`git reset --hard`, `git checkout -- .`, `rm -rf`, etc.) for the purpose of reverting or resetting work without prior coordination and user approval.** When a reset is unavoidable (e.g., undoing a temporary commit), step through a non-destructive alternative (`git reset --soft` / `git reset HEAD~1` followed by per-file `git restore`) and perform it safely.

| # | Don't | Do |
|---|-------|-----|
Confidence
65% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High
Category
Tool Misuse
Content
## Destructive-command restraint (HARD STOP)

**Never run filesystem/index-destroying commands (`git reset --hard`, `git checkout -- .`, `rm -rf`, etc.) for the purpose of reverting or resetting work without prior coordination and user approval.** When a reset is unavoidable (e.g., undoing a temporary commit), step through a non-destructive alternative (`git reset --soft` / `git reset HEAD~1` followed by per-file `git restore`) and perform it safely.

| # | Don't | Do |
|---|-------|-----|
Confidence
65% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High
Category
Tool Misuse
Content
## Destructive-command restraint (HARD STOP)

**Never run filesystem/index-destroying commands (`git reset --hard`, `git checkout -- .`, `rm -rf`, etc.) for the purpose of reverting or resetting work without prior coordination and user approval.** When a reset is unavoidable (e.g., undoing a temporary commit), step through a non-destructive alternative (`git reset --soft` / `git reset HEAD~1` followed by per-file `git restore`) and perform it safely.

| # | Don't | Do |
|---|-------|-----|
Confidence
65% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Agent Config Directory Access

High
Category
Agent Snooping
Content
case "$ENV" in
  antigravity|antigravity-agent|antigravity-ide)
    echo "RULES_FILE=GEMINI.md"
    echo "SETTINGS_FILE=$HOME/.gemini/config/config.json"
    echo "SHARED_RULES_DIR=$HOME/.agents/rules (READ-ONLY)"
    ;;
  claude-code)
Confidence
90% confidence
Finding
Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.

Agent Config Directory Access

High
Category
Agent Snooping
Content
;;
  claude-code)
    echo "RULES_FILE=CLAUDE.md"
    echo "SETTINGS_FILE=$HOME/.claude/settings.json"
    echo "SHARED_RULES_DIR=$HOME/.claude/rules (WRITABLE)"
    ;;
  cursor|vscode)
Confidence
90% confidence
Finding
Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.

Agent Config Directory Access

High
Category
Agent Snooping
Content
;;
  claude-code)
    echo "RULES_FILE=CLAUDE.md"
    echo "SETTINGS_FILE=$HOME/.claude/settings.json"
    echo "SHARED_RULES_DIR=$HOME/.claude/rules (WRITABLE)"
    ;;
  cursor|vscode)
Confidence
90% confidence
Finding
Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.

Agent Config Directory Access

High
Category
Agent Snooping
Content
| 4 | Edit a skill/rule file after partial Grep (e.g., only "Step 7", "Summary" keywords) | **Read the entire file** before any Edit. Skill files have section dependencies (templates, MANDATORY markers in other sections) — partial Grep can miss the existing canonical answer and lead to inventing redundant/conflicting rules |
| 5 | Invent a new title/template/keyword when the user reports a missing element | First Grep the target skill for existing templates/MANDATORY markers (e.g., `Grep "template\|MANDATORY"`). The user's report often refers to an existing template that wasn't followed, not a missing one |
| 6 | Build complex matching tables (skill lists, file presence checks) for rule criteria | **Prefer the simplest 1st-class signal first**. Before authoring a matching table, ask "is there a single field/line that decides this?" (e.g., SKILL.md frontmatter `description` language decides skill language — no publish-target table needed) |
| 7 | Author vendor-specific code (URL, skill name, MCP tool name, instance-bound command) into a generic skill body | Before authoring integration in a generic skill, **grep vendor skill docs for existing dispatch design**: `grep -rE "<generic-skill-name>" ~/.claude/skills/<vendor>/`. If found, follow that pattern. Generic skill declares abstract dispatch (`--<verb>=<skill>:<topic>`); vendor skill implements receiver. See the rule on forbidding vendor-specific references in generic skills |
| 8 | Add case-history meta OR ANY date stamp into a skill or rule body — case-history examples: "violation case", "verified YYYY-MM-DD", "Nth recurrence". Date stamp examples: `(HARD STOP -- added YYYY-MM-DD)`, `(HARD STOP -- newly added YYYY-MM-DD)`, `(recurrence-driven YYYY-MM-DD)`, "observed YYYY-MM-DD", "added in YYYY-MM-DD fix". Any literal `\d{4}-\d{2}-\d{2}` substring in new_string counts | Skill/rule body keeps Don't/Do + self-check + procedure only -- **no date stamps anywhere**, including section headers (`### X (HARD STOP -- added 
...[truncated 26 chars]
Confidence
95% confidence
Finding
The instruction explicitly directs the skill to inspect `~/.claude/skills/<vendor>/`, which is access to the agent's configuration/skill directory outside the current workspace. Access to agent-home configuration is highly sensitive because it can reveal installed capabilities, local conventions, or other cross-project data and can be abused as a precursor to broader modification.

Agent Config Directory Access

High
Category
Agent Snooping
Content
| 5 | Invent a new title/template/keyword when the user reports a missing element | First Grep the target skill for existing templates/MANDATORY markers (e.g., `Grep "template\|MANDATORY"`). The user's report often refers to an existing template that wasn't followed, not a missing one |
| 6 | Build complex matching tables (skill lists, file presence checks) for rule criteria | **Prefer the simplest 1st-class signal first**. Before authoring a matching table, ask "is there a single field/line that decides this?" (e.g., SKILL.md frontmatter `description` language decides skill language — no publish-target table needed) |
| 7 | Author vendor-specific code (URL, skill name, MCP tool name, instance-bound command) into a generic skill body | Before authoring integration in a generic skill, **grep vendor skill docs for existing dispatch design**: `grep -rE "<generic-skill-name>" ~/.claude/skills/<vendor>/`. If found, follow that pattern. Generic skill declares abstract dispatch (`--<verb>=<skill>:<topic>`); vendor skill implements receiver. See the rule on forbidding vendor-specific references in generic skills |
| 8 | Add case-history meta OR ANY date stamp into a skill or rule body — case-history examples: "violation case", "verified YYYY-MM-DD", "Nth recurrence". Date stamp examples: `(HARD STOP -- added YYYY-MM-DD)`, `(HARD STOP -- newly added YYYY-MM-DD)`, `(recurrence-driven YYYY-MM-DD)`, "observed YYYY-MM-DD", "added in YYYY-MM-DD fix". Any literal `\d{4}-\d{2}-\d{2}` substring in new_string counts | Skill/rule body keeps Don't/Do + self-check + procedure only -- **no date stamps anywhere**, including section headers (`### X (HARD STOP -- added DATE)`), parenthetical annotations, code comments (`// observed DATE`), "added/newly added" footers, "since DATE" inline notes. Case history lives **only** in `~/.claude/skills/cleanup/data/failed-attempts.md` (HOT). If a case reference is essential, use a date-free pointer: `(see failed-attempts.md "<keyword>")`. **Self-chec
...[truncated 26 chars]
Confidence
92% confidence
Finding
This section directs writes to `~/.claude/skills/cleanup/data/failed-attempts.md` and references enforcement hooks under `~/.claude/hooks/`, extending the skill into persistent agent-home state. Such cross-session writes can accumulate sensitive history and modify future behavior globally, which is dangerous for a skill whose stated purpose is just correcting current behavior.

Context-Inappropriate Capability

High
Confidence
97% confidence
Finding
The skill instructs installation of hooks and registration in global settings, which gives it system-level persistence over future sessions. That creates a high-risk pathway for durable behavioral modification outside the immediate task, especially because changes under `~/.claude` affect the broader agent environment.

Intent-Code Divergence

High
Confidence
98% confidence
Finding
Earlier guidance states 1st-2nd recurrence should use memory only and rule-file edits begin only conditionally at the 3rd recurrence, with hooks at the 4th recurrence. These lines instead say 1st-3rd time means author rule file content and 4th time means implement the hook, contradicting the earlier routing and escalation instructions.

Intent-Code Divergence

High
Confidence
97% confidence
Finding
Earlier sections say hook implementation is for the 4th+ recurrence, while these lines say writing only a hook specification is a violation at the 3rd recurrence and that the hook must be implemented in the same fix. This is an active contradiction in the file's own procedural guidance, making the documented intent inconsistent with itself.

Agent Config Directory Access

High
Category
Agent Snooping
Content
check looks likely to need automation soon), **4th time** = hook script file + settings.json
   registration + parse-based verification. Missing artifact = Step 2 incomplete.
   - **HARD STOP — "script file authored alone = done" is FALSE**: hook script + chmod +x + copy to `~/.claude/hooks/` + **`settings.json` PostToolUse/PreToolUse matcher registration + post-registration parse verification (`jq` or `python3 -c "import json"`) confirming actual registration** is the full Step 2 deliverable.
   - Mandatory verification command: `python3 -c "import json; d=json.load(open('~/.claude/settings.json')); ..."` to confirm the registered hook command is present in the matcher array. Skipping this = Step 2 incomplete.
   - **HARD STOP — authoring the script alone is not enough**: a hook is only "done" once it is registered AND the registration is parse-verified. Omitting settings.json registration silently disables the hook. (Case history: see failed-attempts.md "RAG store mandate".)
   - **HARD STOP — registration-verified is not the same as detection-verified**: a hook whose job is to grep the transcript for a pattern (a Skill call, a marker, a keyword) MUST be executed against **real transcript data** before the escalation is declared complete — `jq`/`python3 -c "import json"` only proves the settings.json entry parses, not that the hook's own logic actually fires or fires correctly. Run the hook directly with a realistic Stop-event payload (`{"transcript_path": "<real .jsonl>"}`) piped to it and confirm both: (a) it does NOT block when the target condition is absent, and (b) it DOES block when the target condition is genuinely present. A free-text regex (bare keyword match, no JSON-structure anchor) is especially prone to false-positiving on the target skill's own description text recurring in "available skills" system-reminder blocks — test explicitly against a transcript excerpt containing that description text. (Case history: see failed-attempts.md "cleanup missing 
...[truncated 25 chars]
Confidence
98% confidence
Finding
Directing verification against `~/.claude/settings.json` requires reading and potentially modifying central agent configuration, a highly privileged area affecting future sessions. Coupled with hook registration, this creates durable control over the environment well beyond the immediate fix request.

Session Persistence

Medium
Category
Rogue Agent
Content
description: |
  User behavior correction skill. Triggered by "fix:" prefix feedback (e.g., "fix: why didn't you commit?").
  Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence,
  then fixes the current issue. TodoWrite required for all steps.
  Use when "fix:", "fix this", "correct", "why not", "why missing", "behavior fix" is mentioned.
---
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Static analysis

No suspicious patterns detected.