$npx -y skills add PaulRBerg/agent-skills --skill large-file-refactorDiscover large source-file refactor candidates and propose cohesion- and risk-driven split plans using available semantic tooling.
| 1 | # Large File Refactor |
| 2 | |
| 3 | Use LOC thresholds to discover candidates, then decide whether a split is justified by cohesion, coupling, ownership, |
| 4 | and change risk. Test files use a relaxed 2000 LOC discovery threshold. |
| 5 | |
| 6 | ## Arguments |
| 7 | |
| 8 | - `path`: Optional file or directory to scan. Default: current working directory. |
| 9 | - `--include-generated`: Include generated, vendored, dependency, and build-output paths that are skipped by default. |
| 10 | |
| 11 | ## Workflow |
| 12 | |
| 13 | 1. Resolve the skill directory, then run the helper from that directory: |
| 14 | |
| 15 | ```sh |
| 16 | uv run scripts/large-file-refactor.py "$ARGUMENTS" |
| 17 | ``` |
| 18 | |
| 19 | 2. If no arguments were provided, run the default scan: |
| 20 | |
| 21 | ```sh |
| 22 | uv run scripts/large-file-refactor.py |
| 23 | ``` |
| 24 | |
| 25 | 3. Preserve the helper's Markdown table as the exhaustive report. Do not omit matching rows, even when the refactor plan |
| 26 | only covers a subset. |
| 27 | |
| 28 | 4. If the helper reports no threshold matches, stop after the report. A match is a candidate, not proof that the file |
| 29 | should be split. |
| 30 | |
| 31 | 5. Draft a refactor plan for the 3 largest files only, unless the user explicitly requested another count. |
| 32 | |
| 33 | 6. For each candidate, rank split value by mixed responsibilities, change frequency/risk, coupling, and testability. Use |
| 34 | whichever semantic symbol/reference tooling is available; prefer Serena when installed: |
| 35 | |
| 36 | - Inspect symbol overviews, references, imports, and relevant history. |
| 37 | - Use the evidence to choose extraction boundaries, target module names, migration order, and test coverage. |
| 38 | |
| 39 | 7. Do not implement the refactor unless the user separately asks for execution. |
| 40 | |
| 41 | ## Refactor Plan Format |
| 42 | |
| 43 | For each selected file, include: |
| 44 | |
| 45 | - Current role: the file's apparent responsibility and why line count is a symptom. |
| 46 | - Semantic pass: the exact symbol/reference/history inspection to run before moving code. |
| 47 | - Split proposal: 2-5 target modules or files with responsibilities. |
| 48 | - Migration order: small, reviewable steps that preserve public behavior. |
| 49 | - Verification: narrow tests, type checks, builds, or smoke checks that prove the split. |
| 50 | |
| 51 | Lead each plan with one explicit verdict: `### ✂ Split justified`, `### 🧱 Keep intact`, or |
| 52 | `### ⚠️ Generated — change the generator`. Use a compact evidence table for repeated criteria. When proposing a split, |
| 53 | show the source and target modules as a tree only when it clarifies ownership. |
| 54 | |
| 55 | If a selected file is generated or vendored because `--include-generated` was used, plan against the generator, schema, |
| 56 | or upstream source instead of hand-splitting generated output. |
| 57 | |
| 58 | ## Guard Rails |
| 59 | |
| 60 | - Treat the table as source of truth for size ranking only; rank refactor priority separately. |
| 61 | - Keep the plan cohesive; do not split solely to reduce line count. |
| 62 | - Prefer existing project module boundaries and naming conventions. |
| 63 | - Call out when the helper used its portable LOC estimate instead of `tokei`. |
| 64 | |
| 65 | ## Completion |
| 66 | |
| 67 | Complete with the exhaustive threshold report plus evidence-ranked plans only for candidates whose cohesion or change |
| 68 | risk justifies a split. Lead with `### 🔎 Large-file scan — <candidate count>`, state when a large file should remain |
| 69 | intact and why, and surface the portable-LOC fallback as `⚠️ Approximate counts` when used. Keep the helper's exhaustive |
| 70 | table, paths, LOC values, and commands exact and undecorated. |