TL;DR: Check for the comment before inserting it. The transform should inspect the insertion point, and if the exact eslint-disable comment is already there, leave the node alone. Two runs, one diff: the second run must produce no changes. For files already polluted, run a one-off pass that collapses consecutive duplicates into one.

The problem as reported:
```text
the agent's codemod added the same eslint-disable comment on every run - the file grows a new comment each pass and the agent is stuck re-linting
```

1. Open the transform and find the comment-insertion logic. Expected: an unconditional insert or append with no existence check.
2. Add the check: read the existing comments at the target node (in jscodeshift, node.comments; in AST tools, the leading trivia) and skip insertion when the disable text is already present. Expected: the function now has an early return for the already-commented case.
3. Alternatively, normalize instead of append: compute the desired comment set for the node and rewrite it wholesale. Rewriting the same desired state twice is naturally idempotent. Expected: same end state, no duplicates possible.
4. Run the codemod twice on a sample file and diff after the second run. Expected: empty diff.
5. Clean up files already polluted: run a one-off dedupe that collapses runs of identical consecutive disable comments into a single comment. Expected: the diff shows only comment removals, and lint passes.

## Use this when
- A codemod appends the same comment, import, or line on every run.
- Files grow with each pass and re-linting never converges.
- You need comment insertion to be idempotent.

## Not for this skill when
- The duplicates come from a formatter fighting the codemod (prettier/eslint config conflict) - that's a config problem, not a transform bug.
- The comment text legitimately differs per run (e.g. it embeds a changing value) - then the transform needs a different design, not a guard.

## Variant phrasings
- codemod adds comment every run
- eslint-disable duplicated by codemod
- transform not idempotent comment insertion
- duplicate disable comments after codemod

## Why it happens
The insertion logic is unconditional: it never asks whether its own previous output is already there. Each run sees a file missing the comment (from its perspective) and adds another.

## Edge cases
- The disable comment exists but names different rules: merge the rule lists instead of adding a second comment.
- Formatting moved the comment to a different node between runs: anchor the check on the statement the comment governs, not on position.
- A linter auto-fix re-adds what the codemod removed: the two tools are fighting; pick one owner for that comment.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst__IG8x3ce9BHwx0g7fhYJjQ