Skip to content
Back to skills

Scan Generated Files For Artifacts

ASecurity

Use when reviewing or signing off on a file an agent produced with a write tool — a doc, README, config, data file, or any non-code output. Passing tests prove nothing about stray harness framing: a leaked closing tag, an XML/markdown-fence fragment, or content past the intended EOF compiles and tests clean, then ships as visible garbage. Grep every agent-written file's head and tail for tool residue before you approve it. Triggers on "review my changes", "code review", "generated file", "wro...

  • 4 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 6, 2026
ai-agentsgit

Works with

  • cli

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add iamakbarsha1/whetstone --skill scan-generated-files-for-artifacts --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Scan Generated Files For Artifacts?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Scan Generated Files For Artifacts
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/iamakbarsha1-scan-generated-files-for-artifacts/badge)](https://www.skillsdirectory.com/skills/iamakbarsha1-scan-generated-files-for-artifacts)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: scan-generated-files-for-artifacts
description: >
  Use when reviewing or signing off on a file an agent produced with a write
  tool — a doc, README, config, data file, or any non-code output. Passing
  tests prove nothing about stray harness framing: a leaked closing tag, an
  XML/markdown-fence fragment, or content past the intended EOF compiles and
  tests clean, then ships as visible garbage. Grep every agent-written file's
  head and tail for tool residue before you approve it. Triggers on "review my
  changes", "code review", "generated file", "wrote a doc", "wrote a README",
  "tool artifact", "stray tag", "harness residue", "content past EOF".
---

# Scan Generated Files for Artifacts

**Type:** Open-source — client-agnostic methodology, no project-specific detail.

**Created by akbarsha — https://github.com/iamakbarsha1**

Distilled from a review that approved a generated markdown file which compiled
and tested clean — its tail carried a leaked tool-call closing tag and shipped
as visible garbage.

**Licence:** Released under CC BY 4.0 — share and adapt for any purpose with
credit. Full text: `LICENSE` at the repository root.

**Feedback & Support:** If a rule here proves wrong or needs sharpening, open an
issue on the repository or contact the author at the profile link above. If the
problem is the agent not following a rule below rather than the rule itself,
that's an execution failure — acknowledge and correct it.

## The core rule

Tests exercise code behaviour; they say nothing about the bytes of a non-code
file. When an agent writes a file through a tool, the harness framing around
that write — a closing `</content>` or invoke/function tag, a stray markdown
fence, content past the point the spec said the file should end — can leak into
the file itself. It parses fine, compiles fine, tests green, and ships as
visible garbage a reader sees on the first or last screen. A review that runs
only the test suite misses this whole class. So for every file an agent produced
with a write tool, spend one cheap grep on its head and tail before sign-off,
and confirm it ends exactly where it should.

## Checks

- **Grep the head and tail of every agent-written file for harness residue.**
  Search the changed non-code files — especially the first and last few lines —
  for tool/harness tag fragments: `</content>`, closing invoke/function tags,
  orphaned markdown fences, or any framing that belongs to the write mechanism,
  not the content. A trivial `grep` catches what the test suite structurally
  cannot. *(A review approved a generated markdown doc that compiled and tested
  clean; its tail carried a leaked tool-call closing tag and shipped as visible
  garbage.)*
- **Confirm the file ends where the spec says it ends.** Content past the
  intended EOF — a duplicated section, a trailing fragment, a second copy of the
  closing block — reads as garbage but breaks no test. Check the last lines
  against what the file was supposed to contain, not just that it is non-empty.
  *(Illustrative: an agent-generated config had the intended body followed by a
  repeated tail block; every parser accepted it and the duplicate silently
  overrode the real values.)*
- **Never let a green test suite stand in for a byte-level check on non-code
  output.** Docs, configs, fixtures, and data files pass tests they were never
  the subject of. Treat "tests pass" and "the file is clean" as two separate
  claims, and prove the second one directly for anything an agent wrote.
  *(Illustrative: a README shipped with an XML fence fragment in its last
  paragraph; CI was green because no test reads the README.)*

## Pre-flight check — before you approve a review that includes generated files

- [ ] Every file an agent produced via a write tool was grepped at head and tail
      for harness/tool-framing residue (`</content>`, closing invoke/function
      tags, stray fences).
- [ ] Each such file ends exactly where its spec says it should — no content
      past the intended EOF, no duplicated tail block.
- [ ] "Tests pass" was not treated as proof the file's bytes are clean; the
      byte-level check was run separately for non-code output.

If any box is unchecked, a generated file may carry invisible artifacts that
test clean and ship as garbage — run the scan before approving.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.