Anti-Pattern Czar

Detect and fix TypeScript error handling anti-patterns with state persistence and approval workflows. Use when scanning a codebase for silent error failures,...

Security Scan

The skill's purpose and runtime instructions mostly align with a code-fixing tool, but there are unexplained/incoherent pieces (notably invoking an external bunx command with no declared binary/install) that warrant caution before installing or running autonomously.

Purpose & Capability

The name/description (detect and fix TypeScript error-handling anti-patterns, with state and approval workflows) matches the SKILL.md workflows: scanning, review, auto-fix, state persistence, and reporting. However, the SKILL.md expects an external runtime command (`bunx antipattern-czar`) but the skill declares no required binaries or install spec — this mismatch is unexpected and should be clarified.

Instruction Scope

Instructions explicitly direct the agent to read project source, parse code contexts, propose and apply edits, and read/write a state file at the project root. Those actions are consistent with the stated purpose (code scanning and in-place fixes). There are no instructions to read unrelated system files, access secrets, or transmit code to external endpoints in the provided content.

Install Mechanism

This is an instruction-only skill (no install spec). Yet SKILL.md tells the agent to run `bunx antipattern-czar`. That implies either (a) a binary/package must already exist in the environment, or (b) bunx will fetch and run code from a registry at runtime. The skill provides no declaration of this dependency or source for `antipattern-czar`, which is an installation/ supply-chain ambiguity and a potential execution-of-untrusted-code risk.

Credentials

The skill requests no environment variables, credentials, or config paths beyond a project-local `.anti-pattern-state.json`. That is proportionate for a code-modifying linter/repair tool. No unrelated secrets or broad system config access is requested.

Persistence & Privilege

The skill persists state to a project-local `.anti-pattern-state.json` and writes edits to source files as part of normal operation. It is not force-installed (always:false). The combination of write-edit capability plus autonomous invocation (platform default) means users should be careful about allowing the skill to run in auto/fix-all modes — the skill can modify repository files, which is intended but potentially impactful if misconfigured.

What to consider before installing

This skill appears to be a coherent code-scanning/fix assistant, but there are a couple of important unknowns you should resolve before installing or running it on important repositories: - Clarify the `bunx antipattern-czar` dependency. The SKILL.md expects an external command but the skill declares no required binary or install. Ask the author: where does `antipattern-czar` come from (npm package name, GitHub repo, release URL)? Will bunx fetch code at runtime? If so, you are granting the agent the ability to execute remote package code — inspect that package first. - Prefer Review mode initially. Use the REVIEW mode (interactive, one fix at a time) rather than AUTO, so you can inspect each proposed edit and avoid mass automated changes. - Backup and limit scope. Run the tool on a branch or a copy of the repo and ensure you have VCS backups before allowing fixes. The skill writes edits and a `.anti-pattern-state.json` file to the project root; be prepared to revert. - Ask for provenance. The package/source is listed as unknown with no homepage. Lack of origin is a supply-chain risk — request a homepage, source repo, or published package details. - Check environment readiness. Ensure bun (bunx) is present and that your environment's policy for executing fetched packages is acceptable. If you prefer avoiding network fetches, ask the maintainer for a packaged release or include the detector logic in the skill bundle. If the author provides a trustworthy source for `antipattern-czar` (e.g., a well-known repository or published package) and documents how bunx will be used, this skill becomes largely coherent and its remaining behaviors are appropriate for its purpose.

Autonomous agent that systematically identifies and fixes TypeScript error handling anti-patterns.

Detector

Run with Bun (no install required):

bunx antipattern-czar
bunx antipattern-czar --src lib
bunx antipattern-czar --config my-config.json

Config via .antipatternrc.json:

{
  "srcDir": "src",
  "criticalPaths": ["DatabaseService.ts", "AuthHandler.ts"],
  "skipDirectories": ["node_modules", "dist", ".git"]
}

Mode Selection

Parse user intent to pick mode:

User Says	Mode	Action
"scan", "detect", "find"	SCAN	Run detector, save state
"review", "fix", "help me fix"	REVIEW	Interactive fix session
"auto", "fix all", "autonomous"	AUTO	Batch fix with guardrails
"resume", "continue"	RESUME	Load state, continue
"report", "status", "progress"	REPORT	Show current state

State File

Always check .anti-pattern-state.json at the project root. On first SCAN, ask if resuming when it exists.

{
  "session_id": "<uuid>",
  "started_at": "<ISO>",
  "target_path": "<path>",
  "issues": [],
  "history": []
}

Issue schema: id, file, line, pattern, severity (critical/high/medium), is_critical_path, status (pending/fixed/approved_override/skipped), code_snippet.

Workflow by Mode

See workflows.md for full per-mode workflows. Summary:

• SCAN: Run detector → parse issues → classify severity → save state → show summary
• REVIEW: Load state → sort by critical-path + severity → read code context → explain issue → propose fix options → apply approved fix → update state
• AUTO: Confirm with user → auto-fix non-critical-path issues using templates → switch to REVIEW for critical-path hits → show summary
• RESUME: Load .anti-pattern-state.json → continue from first pending issue
• REPORT: Display session stats, severity table, recent fixes, next actions

Approved Overrides

Only suggest APPROVED_OVERRIDE when ALL are true:

1. Error is expected and frequent
2. Logging would create excessive noise
3. There is explicit recovery/fallback logic
4. Reason is specific and technical

NEVER approve overrides on critical paths without exceptional user confirmation.

Format:

} catch {
  // [APPROVED_OVERRIDE] <specific technical reason>
  // Fallback: <what happens instead>
}

Fix Templates

See patterns.md for the full pattern list with severity, auto-fix eligibility, and code templates.

Progress Output Format

After each fix:

✅ Fixed: src/services/example.ts:42
   Pattern: NO_LOGGING_IN_CATCH
   Solution: Added logger.error() with context

Progress: 4/28 issues remaining ━━━━━━━ 14%