ia-verification-before-completion

• Outcome: Pass
• Latest audit: Sep 20, 2026 · 5:31 PM UTC
• Version: 4.6.1

Overview

This skill is a transparent engineering checklist that pushes the agent to verify claims before saying work is complete.

Install this if you want the agent to be stricter about proving work before claiming it is done. Expect it to ask for or run relevant project checks and to be more cautious about broad scope, dirty worktrees, and failed verification.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Memory Poisoning: Persistent Context Injection, Context Window Stuffing, Memory Manipulation
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (4)

Hidden Instructions

High

• Category: Prompt Injection

Content

Out of scope:
- Acting as the runtime instructions themselves (those live in `SKILL.md`).
- Trigger phrasings already covered by adjacent `ia-*` skills (`validate-plugin` flags >70% description overlap as DUPLICATE_TRIGGER).
- <!-- to fill in: domain-specific exclusions when the skill drifts -->

## Trigger Context

• Confidence: 70% confidence
• Finding: Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

A falling lint count is fully compatible with a corrupted file: most linters report only the *first* parse failure per file, so six broken literals surface as one error, six runs in a row, each looking like the last. A width-based rewriter has no parser -- it splits string literals into syntax errors and breaks comments mid-clause -- and a formatter run afterwards happily reformats prose that no longer says what the author wrote. In-place writes also replace a symlink with a regular file; check `git status --short` for a `T` (typechange) entry after any scripted edit.

**"Successfully rebased" is not proof the commit survived intact.** A three-way merge can resolve a pure insertion toward the new base when the surrounding lines were rewritten upstream -- no conflict, no warning, the hunk simply gone from the commit. After any rebase, cherry-pick, or history rewrite, diff the commit's touched-file list across the operation (`git show --stat --name-only HEAD@{1}` against `HEAD`) and confirm the expected content is still present. Do this whenever the base moved since the branch was cut, not only when conflicts appeared: a clean run is not the evidence. A second mechanism drops a hunk just as quietly: `.gitattributes` can bind a path to a merge driver that keeps one side (`driver = true`, `driver = touch %A`) and records a successful merge of a file it never merged, and during a rebase "ours" is the new base, so the incoming edit is the one discarded. Ask before the operation (`git check-attr merge -- <path>`, `git config --get merge.<name>.driver`); `git merge-file` does not consult `.gitattributes`.

**Self-review against the base, not HEAD.** `git diff` and `git diff HEAD` hide anything already committed on the branch. When HEAD holds an earlier attempt at the same fix, the superseded code is part of the base and never appears as an add or a remove -- the patch is unreviewable that way, and layering a second approach on top of a half-reverted first one is how a doubl
...[truncated 25 chars]

• Confidence: 80% confidence
• Finding: Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.

Memory Manipulation

High

• Category: Memory Poisoning

Content

- **Boundary value**: 0, -1, empty string, empty array, `null`, `undefined`, `MAX_INT`, 1-char unicode combining mark
- **Concurrency**: two parallel requests with the same identifier (for state changes, races, double-spend classes)
- **Idempotency**: run the same mutation twice; the second should either no-op or error cleanly, not corrupt state
- **Orphan op**: delete/update/get a nonexistent ID — does it 404/return-null as expected, or throw an internal error?
- **Implementation shape**: vary what callers supply to an I/O path or an extension point -- a plugin with and without each optional method, a destination that exists and one that does not, a symlink, a read-only parent. A green suite, a clean sanitizer, and a differential API sweep share one blind spot: the signature is unchanged while the capability is gone, because an identical `false` for a different reason reads as no change. State the capability verified, not the aggregate.

• Confidence: 90% confidence
• Finding: Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

## Pre-Commit Hook Failures

A failing pre-commit hook is a verification checkpoint, not an obstacle to route around. **`git commit --no-verify` is forbidden when the current session's changes caused the failure -- fix the root cause.** Permitted only when: (1) the failure reproduces on the base branch (show it), and (2) the user saw the failure first. A `--no-verify` the user never saw is a defeated check -- the same failure mode as claiming completion without evidence.

## Rationalization Prevention

• Confidence: 75% 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).

Static analysis

No suspicious patterns detected.