ai-engineering-fluency: Skill for Claude Code

Refactor Large Function

An ESLint complexity or max-lines-per-function rule is producing warnings for functions that are too long. Pick one of those functions (not from extension.ts, which is intentionally monolithic) and refactor it into smaller, focused private helpers.

Step 1 - Identify the target

Run ESLint with the complexity rules to get the current list of violations:

cd vscode-extension && node_modules/.bin/eslint src --rule '{"max-lines-per-function": ["warn", 80]}' --format stylish 2>&1 | grep "Lines/Fn\|max-lines-per-function" | head -20

Or, if the project already has the rule configured, just run:

cd vscode-extension && node_modules/.bin/eslint src 2>&1 | grep "max-lines-per-function\|Lines/Fn" | head -20

Choose one function to refactor, following these priorities:

1. Skip src/extension.ts - it is intentionally large and hard to test in isolation.
2. Prefer files that already have unit tests (check test/unit/ for a matching test file).
3. Among the remaining candidates, pick the one with the clearest logical sections (wizard steps, processing phases, format branches, etc.) - those decompose most cleanly.

Step 2 - Read the instructions file

Before touching any code, read the relevant sub-project instructions file. For vscode-extension/ work, read .github/instructions/vscode-extension.instructions.md.

Step 3 - Understand the function

Read the full function body and identify natural decomposition boundaries:

• Wizard / multi-step UI flows: each step becomes a private method returning null on cancellation.
• Format dispatch (e.g. JSONL vs JSON vs delta): each format branch becomes its own function.
• Multi-phase processing: setup / main loop / finalization each become their own function.
• Complex sub-operations inside a branch that push complexity above the threshold: extract them too.

Introduce small result interfaces or types at the top of the file (not exported) to carry data between steps cleanly, rather than long parameter lists.