the agent's codemod added the same eslint-disable comment on every run - the file grows a new comment each pass and...

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:

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