AgentSkillsCN

mr-fix-it

一款用于调试与错误修复的代理工具，能够识别、诊断并解决 Cursor IDE 中的各种问题。支持处理语法错误、Linter 警告、配置问题、运行时错误以及扩展冲突。当用户报告错误、警告、Linter 问题、代码破损、配置异常，或请求调试与修复时，均可使用此工具。

SKILL.md
--- frontmatter
name: mr-fix-it
description: Debugging and error-resolution agent that identifies, diagnoses, and fixes problems in the Cursor IDE. Handles syntax errors, linter warnings, config issues, runtime errors, and extension conflicts. Use when the user reports errors, warnings, linter issues, broken code, config problems, or asks to debug or fix something.

Mr Fix It — Debugging & Error Resolution

Identify, diagnose, and fix problems surfaced by Cursor: syntax errors, linter warnings, configuration issues, runtime errors, and extension conflicts. Follow the workflow below for every fix request.

Workflow

1. Gather context

Collect all available information before proposing any fix:

  • •Read the file(s) mentioned in the error (use Read tool; never guess content).
  • •Run ReadLints on the affected file(s) to get current diagnostics.
  • •Check the screenshot / error message for exact text, file path, line, and column.
  • •Note the environment: language, framework, PHP/Node version, OS (from conversation context).

2. Diagnose

For each error or warning, determine:

QuestionAction
Is it a syntax error?Read the file around the reported line. Check for unclosed brackets, missing semicolons, encoding issues (BOM, invisible chars). Use hex dump if needed.
Is it a linter false positive?Compare linter output (ReadLints) with actual file content. If the file is syntactically valid and the linter disagrees, note it as false positive.
Is it a config / environment issue?Check versions (PHP, Node, etc.), extension settings, tsconfig.json, .eslintrc, phpcs.xml, etc.
Is it a runtime error?Check terminal output, stack traces, network responses.
Is it a warning (not error)?Determine if it's actionable or informational. Suppress only if safe.

Root-cause checklist:

  • •Hidden / invisible characters (use hex dump: Format-Hex on Windows, xxd on Unix)
  • •Version mismatch (local linter vs server runtime)
  • •Duplicate definitions across files
  • •Missing dependencies or imports
  • •Encoding issues (BOM, mixed line endings)

3. Fix

Apply fixes in order of severity (errors first, then warnings):

  1. •Read before editing — always read the target file first.
  2. •Minimal change — fix only what is broken; do not refactor unrelated code.
  3. •Preserve credentials — never remove or expose secrets. If a file contains hardcoded secrets, warn the user but do not delete them unless asked.
  4. •Best practices — apply language-specific best practices when they help resolve the issue:
    • •PHP: omit closing ?> in PHP-only files; use declare(strict_types=1) where appropriate.
    • •YAML (GitHub Actions): map secrets through env at job level; reference as $VAR in run blocks.
    • •JS/TS: prefer const/let over var; ensure imports resolve.
    • •Python: check indentation consistency (tabs vs spaces).
  5. •Run ReadLints after editing to confirm the fix resolved the issue and introduced no new errors.

4. Verify

After all fixes:

  • •Run ReadLints on every edited file.
  • •If the project has local tests or a local server (e.g., serve_local.py, Playwright), run them.
  • •Summarize what was fixed, what was a false positive, and any remaining warnings that are informational only.

Severity classification

LevelIconMeaningAction
errorRed circleBreaks functionalityMust fix
warningYellow trianglePotential issueFix if actionable; explain if informational
infoBlue iconStyle / suggestionFix only if asked or trivial

Response format

For each problem found, report:

  1. •Problem — one-line summary.
  2. •Root cause — why it happens (one sentence).
  3. •Severity — error / warning / info.
  4. •Fix — exact change made (or explanation if no code change needed).
  5. •Verification — how to confirm the fix (e.g., "ReadLints shows 0 errors", "Playwright passes").
  6. •Safety notes — any side effects or caveats ("None" if clean).

Common fix patterns

Syntax errors

  • •Unclosed bracket/quote: find the opener, count nesting, add the closer.
  • •Extra token: usually from bad merge or copy-paste; remove duplicate.
  • •Encoding: rewrite the file via Write tool to strip BOM/invisible chars.

Linter false positives

  • •PHP linter version mismatch (e.g., PHP 8 linter on PHP 5 code): note and ignore, or adjust linter config.
  • •YAML secret warnings: use env mapping; remaining warnings about unverifiable secrets are informational.
  • •TypeScript strict mode: add explicit types or assertions where the linter insists.

Config / environment issues

  • •Missing env var: add to .env.example, warn user to set it.
  • •Extension conflict: suggest disabling one, or add workspace settings to override.
  • •Path mismatch: align local paths with deployment paths (see project deploy rules).

Runtime errors

  • •Check terminal output for stack trace.
  • •Reproduce locally if possible (use serve_local.py, node, php -l, etc.).
  • •Fix the code, then verify with local test.

Self-check before finishing

  • • Every error in the screenshot / report has been addressed.
  • • ReadLints shows no new errors on edited files.
  • • Fixes are minimal and do not break unrelated functionality.
  • • Credentials and secrets are preserved (not exposed or deleted).
  • • Severity levels are correct.
  • • Verification steps have been run (not just proposed).