codeant-scans-anti-patterns

name	codeant-scans-anti-patterns
description	Fetch the top 10 anti-patterns scan findings on the current branch, validate each against the source, and apply safe minimal fixes

Fetch the top 10 Anti-Patterns findings from the latest scan on the current branch, validate each against the current source code, and apply only safe, minimal fixes.

Instructions

Step 0 — Ensure codeant-cli is up to date

Before doing anything else, check that the codeant CLI is on the latest version:

npm view codeant-cli version

Compare this with the installed version:

codeant --version

If the installed version is older than the latest published version, update it:

npm install -g codeant-cli@latest

If the update fails (e.g., permission error), warn the user and continue — a slightly outdated CLI is better than blocking the entire workflow.

Step 1 — Gather context from git

Get the current branch and repo:

git rev-parse --abbrev-ref HEAD
git remote get-url origin

Parse the remote URL to owner/repo format:

• HTTPS: https://github.com/owner/repo.git → owner/repo
• SSH: [e-mail]:owner/repo.git → owner/repo

If the repo cannot be determined from the remote, ask the user to provide it explicitly as owner/repo.

Use the AskUserQuestion tool to ask the user for the severity filter:

"Which severity levels should I include? Options: critical, high, medium, low, info, unknown, or all (default). You can specify multiple comma-separated values, e.g. critical,high."

Wait for the user's response before continuing. Default to all if the user does not answer.

Step 1b — Track skill invocation

codeant track --event "skill_invoked" --props '{"skill_name": "codeant-scans-anti-patterns", "source": "cursor", "repo": "<REPO>", "branch": "<BRANCH>", "severity": "<SEVERITY>"}'

Step 2 — Fetch scan findings

Run the following command (omit --severity when the user chose "all"):

codeant scans results \
  --repo <owner/repo> \
  --branch <current-branch> \
  --types anti_patterns \
  --limit 10 \
  --filter-dismissed \
  --no-false-positives \
  --quiet \
  --format json

When the user specified a severity, add:

  --severity <user-severity>

Handle exit codes:

• 0 — success; parse the findings array from the JSON output
• 2 — no scans found for this branch; tell the user and stop
• 4 — network error; tell the user and stop
• Other non-zero — surface the error message from stderr and stop

If findings is an empty array after a successful call, tell the user: "No Anti-Patterns findings matching your filters on branch <branch>." and stop.

Step 3 — Categorize findings

Each finding object contains: severity, category, file_path, line_number, check_id, check_name, message.

Group findings by file_path to minimize re-reading. For each finding:

1. Read file_path with 30 lines above and 30 lines below line_number for full context.
2. Read message and check_name carefully to understand:
   • What is the problem? — What anti-pattern was detected.
   • What is the fix? — The idiomatic alternative to the flagged pattern.

Step 4 — Analyze each finding and assign a verdict

For each finding, determine whether it can be safely fixed. Assign one of four verdicts:

ACCEPT — Safe to apply. Assign this when ALL of these are true:

• The anti-pattern described in message is still present at line_number
• The fix is syntactically valid and all variables/imports are in scope
• The change does NOT alter the function's return type, signature, or public API
• The change does NOT remove or weaken existing error handling
• The fix is localized — it replaces only the flagged pattern with the idiomatic equivalent

LIKELY ACCEPT — Looks correct, but verify callers. Assign this when:

• The fix is logically sound and addresses a real pattern issue
• BUT it changes behavior in a subtle way that callers may depend on

DO NOT ACCEPT — Could break things. Assign this when ANY of these are true:

• The fix changes a function's return type or public interface
• The fix restructures control flow beyond what the anti-pattern requires
• The fix is a refactor that goes beyond replacing the specific pattern
• You cannot determine a safe minimal fix from context alone

STALE — Code has changed since the scan. Assign this when:

• The code at line_number no longer matches what the finding describes
• The file has been renamed or deleted

For each ACCEPT or LIKELY ACCEPT finding, draft the minimal fix: replace the anti-pattern with the idiomatic equivalent, touching only the flagged lines.

Step 5 — Present the summary with verdicts

Before making any changes, present a clear summary:

• Repo: owner/repo
• Branch: <branch>
• Scan type: Anti-Patterns
• Total findings fetched: X (up to 10)

Then list every finding grouped by verdict:

ACCEPT — Safe to apply (N): For each, show:

• File path and line number
• Severity and check name
• One-line summary of the anti-pattern
• One-line explanation of why this fix is safe
• The actual code change (before → after)

LIKELY ACCEPT — Verify callers (N): For each, show:

• File path and line number
• Severity and check name
• What the fix changes and why it's probably correct
• What could break: specifically which callers or behaviors to verify
• The actual code change (before → after)

DO NOT ACCEPT — Could break logic (N): For each, show:

• File path and line number
• Severity and check name
• Specific reason why this fix is risky
• What the user should do instead

STALE — Code changed since scan (N): For each, show:

• File path and line number
• What the finding expected to find vs. what's actually there now

Then ask the user: "I will apply the N ACCEPT fixes now. For the LIKELY ACCEPT fixes, I recommend you review the callers first — want me to apply those too, or skip them for now?"

Step 6 — Apply the fixes

After the user confirms:

• Apply all ACCEPT fixes.
• Apply LIKELY ACCEPT fixes only if the user said yes.
• Do NOT apply DO NOT ACCEPT or STALE fixes.
• Make the smallest possible change: replace only the anti-pattern with its idiomatic equivalent.
• If the fix requires adding an import, add it.
• If multiple findings refer to the same file, apply all fixes to that file before moving to the next.

Step 6b — Track results

After applying fixes, report the outcome:

codeant track --event "suggestions_applied" --props '{"skill_name": "codeant-scans-anti-patterns", "source": "cursor", "repo": "<REPO>", "branch": "<BRANCH>", "accept_count": <N>, "likely_accept_count": <N>, "do_not_accept_count": <N>, "stale_count": <N>, "total_findings": <N>}'

Use the actual counts from the verdicts assigned in Step 4. For likely_accept_count, only count ones the user chose to apply.

Step 7 — Report results

Present a final report:

Applied (N findings):

• For each: file, line, one-line summary of what was changed, and the verdict (ACCEPT or LIKELY ACCEPT).

Not applied — DO NOT ACCEPT (N findings):

• For each: file, line, specific reason the fix is risky.

Not applied — STALE (N findings):

• For each: file, line, what changed since the scan.

Step 8 — Offer to commit and push

After presenting the final report, check which files were modified:

git status --short

List the changed files to the user and ask:

"These are the files that were changed:

• <file1>
• <file2>
• ...

Would you like me to commit and push these changes to the current branch? You can also tell me to commit only specific files."

• If the user says yes (or specifies which files to include), stage the selected files, create a commit with a clear message (e.g., "Fix anti-patterns via CodeAnt scan on branch "), and push to the current branch.
• If the user says no or wants to review first, do nothing — leave the changes uncommitted.
• If the user specifies a subset of files, only stage and commit those files.

Important Rules

• Do NOT modify files not referenced in the findings.
• Do NOT apply a fix you cannot verify is safe. It is always better to skip and explain than to break the code.
• Do NOT batch-apply fixes blindly. Validate each one individually.
• Keep fixes minimal. Replace only the anti-pattern — do not restructure, rename, or reorganize anything else.