the agent's ast-grep rewrite rule kept appending the same import line in a loop because the pattern matched its own...

TL;DR: The rule must not match its own output. Anchor the pattern on the old construct only, so once the rewrite fires there's nothing left for a second run to match. If the rule also inserts the import, gate that on the old code's presence too - never let an always-firing rule append the import. Verify with two scans: the second must report zero matches.

The problem as reported:

the agent's ast-grep rewrite rule kept appending the same import line in a loop because the pattern matched its own insertion

1. Reproduce the loop: run ast-grep scan --rule rule.yml src twice. Expected: the import count in matching files grows with every run.
2. Read the rule and find the overly broad pattern - usually it matches a common node (every call, every file) while the fix appends the import unconditionally. Expected: you can see the pattern is still true after the fix runs.
3. Narrow the pattern to the old construct only, e.g.:

rule:
  pattern: oldHelper($$$)
fix: newHelper($$$)

Expected: the pattern is false for the rewritten code, so re-runs are no-ops by construction.

4. Handle the import separately: use a scan-only rule to find files that still need it, and add the import in the same fix that rewrites the old call - never as a standalone always-firing rule:

rule:
  kind: program
  not:
    has:
      kind: import_statement
      regex: my-new-lib

Run ast-grep scan --rule needs-import.yml src. Expected: lists exactly the files missing the import, and the list shrinks to zero as the rewrite rule does its job.

5. Final check: run the full scan twice. Expected: the first run rewrites, the second run reports no matches.

Use this when

• An ast-grep rule appends or duplicates its own insertion on every run.
• A scan with update-all grows the file each pass.
• A rewrite rule's pattern matches the code its fix produces.

Not for this skill when

• The duplicates come from several overlapping rules in a rules directory - that's rule composition; deduplicate the rules instead.
• The looping tool isn't ast-grep - the same principle applies, but the syntax here is ast-grep-specific.

Variant phrasings

• ast-grep fix runs in loop
• ast-grep appends import every run
• ast-grep rule matches its own output
• ast-grep rewrite not idempotent

Why it happens

The pattern describes a shape the fix itself produces. Each run's output satisfies the next run's pattern, so the rule keeps firing on its own insertions.

Edge cases

• A regex in the rule matching more imports than intended: anchor it to the exact module name.
• The inserted import lands in the wrong position and breaks import sorting: let the linter's sort fix it, or insert after the last existing import.
• Multiple rules in one directory where the rewrite rule and the import rule fire in the same pass: order them or combine the guards.

Provenance

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

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

Thread query: the agent's ast-grep rewrite rule kept appending the same import line in a loop because the pattern matched its own insertion

TL;DR: