Agent skill

Refactoring Audit

by epam in epam/ai-dial-chat

Deep codebase refactoring audit for AI DIAL Chat. An agent skill from epam/ai-dial-chat.

Apache-2.0Auto-check passedDevelopment

Install Refactoring Audit

skills CLI
$ npx skills add epam/ai-dial-chat --skill refactoring-audit -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install epam/ai-dial-chat refactoring-audit --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/epam/ai-dial-chat.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/refactoring-audit .claude/skills/refactoring-audit && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
refactoring-audit
GitHub stars
504
Token cost
~4.3k tokens
SKILL.md length
1,643 words
Files
7 (incl. scripts)
Skills in repo
18
Repo updated
First seen
Licence
Apache-2.0

At a glance

Deep codebase refactoring audit for AI DIAL Chat. An agent skill from epam/ai-dial-chat.

  • Works in 8 steps: Collect metrics → Compare with prior audit → Deep dive (metrics-driven) → …
  • The user asks for a refactoring plan
  • SKILL.md covers Stability rule — no pinned…, Outputs (never commit), When to use and Prerequisites, plus 4 more sections
  • Runs Shell and JavaScript scripts from its folder; calls npm, git and bash

What it does

Refactoring Audit is an agent skill from epam/ai-dial-chat. Deep codebase refactoring audit for AI DIAL Chat. Collects metrics, compares with prior local plans, detects dead-code candidates, and writes or updates refactoring-backend.md, refactoring-frontend.md, and refactoring.md index docs (git-excluded). Use when the user asks for a refactoring plan, tech-debt review, god-module analysis, dead/unused-code analysis, architecture audit, or updated refactoring documents.

Its SKILL.md is about 4.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including scripts (for example `knip-audit.json`, `repo-rules-checklist.md` and `scripts/collect-dead-code.sh`).

It sits in Development, covering Refactoring and Technical debt. It works with Git. The repository describes itself as: A default UI for AI DIAL. The licence is Apache-2.0.

When your agent uses it

  • The user asks for a refactoring plan
  • Tech-debt review
  • God-module analysis
  • Dead/unused-code analysis

Example prompts

  • “/refactoring-audit”

Requirements

  • Node.js
  • A Bash shell

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Collect metrics
  2. Compare with prior audit
  3. Deep dive (metrics-driven)
  4. Score phases honestly
  5. Write documents
  6. Git exclude maintenance
  7. Optional OpenSpec prompt
  8. User summary

What it can do on your machine

Read from SKILL.md and the folder at commit 2d66a8d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 3 files in scripts/ (Shell and JavaScript), which the agent can run.

    Shell commands in SKILL.md call:

    • npm
    • git
    • bash
    • rg
    • jq

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Refactoring Audit loads about 4.3k tokens when it runs. Until then it costs about 108 tokens; SKILL.md has 1,643 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~108
When it runs · the whole SKILL.md, loaded when a task matches
~4.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from epam/ai-dial-chat at commit 2d66a8d, republished under its Apache-2.0 licence (© epam). 1,643 words, ~4,302 tokens.

Download SKILL.mdSave it as .claude/skills/refactoring-audit/SKILL.md (or your agent's skills folder). This skill also uses 6 other files; get the full folder from GitHub.
name
refactoring-audit
description
Deep codebase refactoring audit for AI DIAL Chat. Collects metrics, compares with prior local plans, detects dead-code candidates, and writes or updates refactoring-backend.md, refactoring-frontend.md, and refactoring.md index docs (git-excluded). Use when the user asks for a refactoring plan, tech-debt review, god-module analysis, dead/unused-code analysis, architecture audit, or updated refactoring documents.
context
fork

Refactoring audit

Produce local-only refactoring plans for this monorepo. Output is planning material for humans — not code changes unless the user explicitly asks to implement something.

Language: All audit outputs MUST be written in English.

Stability rule — no pinned source paths in skill docs

This skill, its templates, and repo-rules-checklist.md describe patterns, thresholds, and grep commands — not specific source file paths. File paths move, split, and get deleted; hardcoded paths in instructions go stale.

  • Skill artifacts → patterns + metrics only.
  • Audit output docs (refactoring*.md) → list paths discovered during the current run (from collect-metrics.sh + reads). Regenerate tables each audit; do not copy example paths from templates.
  • Phase milestones → verify with grep/counts (see Step 4), not memorized filenames.

Outputs (never commit)

FileScope
refactoring.mdIndex + scorecard
refactoring-backend.mdapps/chat-api
refactoring-frontend.mdapps/chat + hand-authored libs/*
docs/{change}-openspec-prompt.mdOnly if user wants next OpenSpec prompt

Git rule: These files MUST stay out of git. After writing, ensure each path is listed in .git/info/exclude. Run git check-ignore -v <file> and confirm git ls-files does not list them. Never git add refactoring docs. Do not add them to .gitignore unless the user explicitly wants team-wide ignore rules in the repo.

When to use

  • User asks for refactoring plan, tech-debt review, or codebase analysis
  • User asks to refresh refactoring docs after major merges/archives
  • User wants backend vs frontend debt split
  • Periodic audit (compare with previous refactoring*.md date and Δ line counts)

Prerequisites

Read before analyzing:

  • openspec/config.yaml — stack, architecture, lib isolation
  • AGENTS.md — skill routing, RTL, Nx conventions
  • Previous local docs if they exist (refactoring.md, refactoring-backend.md, refactoring-frontend.md)
  • Archived OpenSpec for completed refactors: openspec/changes/archive/*split-*, *dial-core*, *dedupe*

Invoke ./.agents/skills/nx-workspace/SKILL.md if unsure about project names or targets.

Workflow

Copy this checklist and track progress:

Refactoring audit:
- [ ] 1. Collect metrics
- [ ] 2. Read prior docs + OpenSpec archives
- [ ] 3. Deep dive (top entries from metrics — not a fixed file list)
- [ ] 3b. Structural smells pass (else-if ladders, key dispatch, large switches, nested ternaries)
- [ ] 3c. Convention violations pass (AGENTS.md / RTL / lib isolation / imports)
- [ ] 3d. Dead-code pass (unused files, exports/types, dependencies, orphan projects)
- [ ] 4. Verify completed phases from code (grep/counts, not memory)
- [ ] 5. Write/update three docs (English) — paths from this run only
- [ ] 6. Ensure .git/info/exclude
- [ ] 7. Optional: next OpenSpec prompt
- [ ] 8. Summarize for user
Step 1 — Collect metrics

Run:

bash
bash .claude/skills/refactoring-audit/scripts/collect-metrics.sh

This is the primary source of truth for which files to inspect. Treat every ranked list, smell, violation, and dead-code section as the candidate set for Steps 3–3d.

Run the dedicated dead-code collector separately because it may be slower and requires a local Knip installation for full coverage:

bash
bash .claude/skills/refactoring-audit/scripts/collect-dead-code.sh

Optionally run verification (note result in docs if WIP branch):

bash
npm exec nx test chat-api
npm exec nx test chat

Supplement with targeted greps (see repo-rules-checklist.md):

bash
npm exec nx show projects --type=lib
ls openspec/changes | rg -v '^archive$'
rg "extends AppService|MUST stay in sync" apps/chat-api apps/chat --glob "*.{ts,tsx}"
Step 2 — Compare with prior audit

If previous docs exist:

  • Carry forward completed items with OpenSpec archive evidence
  • Compute Δ line counts for god modules that appear in both audits (match by path from prior doc + current metrics)
  • Close items that landed (e.g. archived split-files-service, split-use-dial-file-manager)
  • Do not revert completed checkboxes without code proof
  • Drop prior-doc rows for files that no longer appear in metrics (refactored away)

If no prior docs: establish baseline; skip Δ column.

Step 3 — Deep dive (metrics-driven)

Do not use a fixed checklist of filenames. Instead, for each area, read the top N from Step 1 plus any smell/violation hits:

AreaSource in metrics outputRead depth
Backend services"Backend services (top 20)"Top 5 + any >400 lines not yet split
Backend tests"Backend test specs (top 15)"Specs >1000 lines tied to unsplit services
Frontend app"Frontend app sources (top 25)"Top 5 components/hooks/contexts
Frontend tests"Frontend test specs (top 15)"Specs >1000 lines
Libs"Libs total LOC" + "Lib largest files"Libs >5000 LOC or files >400 lines
Structural smellsAll smell sectionsEvery prod hit (exclude *.spec.* when prioritizing)
Convention violationsAll violation sectionsEvery non-zero category; sample-read hits
Dead codeDead-code collectorEvery production hit; sample default-mode-only hits

While reading, classify patterns (god service, facade already split, dispatch ladder, etc.) — not whether a file matches a historical name.

OpenSpec: active changes + recent archives since last audit date.

Step 3b — Structural smells pass (mandatory)

Uses metrics script output (see repo-rules-checklist.md for thresholds). For each hit, read the file and classify by pattern type:

PatternSmellTypical fix
for (…) { if (def.key === 'a') … else if (def.key === 'b') … }Stringly-typed registry dispatchHandler map / resolver table co-located with config definitions
else if chain on enum/string (≥8 per file)Open/closed violationLookup object, strategy map, or polymorphism
switch (x) { case … } with ≥10 casesSameDiscriminated union + handler record
Duplicate branch bodies (typeof x === 'string' ? x : null)Copy-paste dispatchShared coerce helpers keyed by type
a ? b : c ? d : e on one lineNested ternaryif/else, early return, named intermediate, helper function

Document in Structural smells sections. Columns: path (from this run), pattern type, branch/count, suggested fix, priority (usually P2 unless actively growing). Do not skip small files when metrics flagged them.

Step 3c — Convention violations pass (mandatory)

Cross-check against AGENTS.md, openspec/config.yaml, eslint.config.mjs, RTL rules. Full grep mapping: repo-rules-checklist.md.

Use metrics script violation sections + anti-patterns grep. For each non-zero category, sample-read hits and document in Convention violations (path from this run, rule violated, detail, fix, priority).

Do not treat every grep hit as debt — confirm context (tests, generated code, documented exceptions). Do flag patterns that contradict documented architecture.

Step 3d — Dead-code pass (mandatory)

Use three complementary signals; no single signal is sufficient:

  1. Run TypeScript checks across every configured project to catch unused local declarations and imports (noUnusedLocals is enabled in the workspace):

    bash
    npm exec -- nx run-many --target=typecheck
  2. Run scripts/collect-dead-code.sh. It performs both comprehensive and production Knip passes when a local Knip binary is available. The production pass identifies code kept alive only by tests/tooling; the comprehensive pass also covers unused test and tooling code.

  3. Inspect the Nx project graph for projects with no in-repo dependents:

    bash
    npm exec -- nx graph --print \
      | jq -r '.graph as $g | ($g.nodes | keys[]) as $name | select([ $g.dependencies[]?[]? | select(.target == $name) ] | length == 0) | $name'

Classify every production Knip hit, and sample-read default-mode-only hits, as one of:

  • Confirmed dead — no runtime, configuration, public API, or external-consumer reachability.
  • Reachability/config gap — Knip is missing an entry, plugin, generated artifact, dynamic import, or path mapping.
  • Intentional public API — exported for consumers outside this repository.
  • False positive / framework-managed — loaded by NestJS metadata/DI, Vite/Webpack, Nx targets, scripts, or another convention that static imports do not expose.
  • Needs owner confirmation — evidence is insufficient for safe deletion.

Review candidates in cascade order: unused production files first, then their exports/types/members, then dependencies. One unreachable file can cause all downstream symbols and dependencies to appear unused.

Coverage rules:

  • Mark Full only when typecheck and both Knip passes complete, configuration hints and unresolved imports are investigated, and production hits are manually classified.
  • Mark Partial when Knip is unavailable/fails, typecheck cannot complete, or reachability/configuration gaps remain. List the missing signal explicitly; never report “no dead code” from partial coverage.
  • If Knip is not installed, do not download or add it automatically. Continue with TypeScript/Nx signals, mark coverage Partial, and ask before changing package.json/the lockfile when full analysis is required.
  • An Nx project with zero inbound edges is only a candidate: applications are graph roots, and publishable libraries may have external consumers.
  • Exclude generated chat-api-client findings. Do not hand-edit or recommend deleting generated client code.
  • Never run knip --fix, delete files, or remove dependencies during an audit. Produce planning findings only unless the user separately authorizes implementation.

Document dead-code findings in a dedicated Dead code section. Include: path/package, candidate kind, source signal and mode, classification, evidence/consumer check, suggested action, and priority. Keep confirmed findings separate from unverified candidates.

Show full SKILL.md (502 more words)Show less
Step 4 — Score phases honestly

Use the phase checklist in templates.md. Mark ✅ only with grep/count evidence from this run:

MilestoneHow to verify (no fixed paths)
DialCoreModuleextends AppService count = 0; DialClientService present under chat-api
Files splitFiles domain facade service <250 lines in metrics; multiple sub-services under same domain
FM hook splitComposer hook for file manager <300 lines; sibling sub-hooks in same folder
Phase 1.6 openInline file-manager open state in conversation view without shared hook — grep isDialFileManagerOpen vs useDialFileManagerState in conversation view area
Step 5 — Write documents

Follow section structure in templates.md. English only. Populate tables from Step 1 output only — templates show column shapes, not real paths.

Quality bar:

  • Every god-module row includes line count from metrics
  • Every audit states dead-code coverage (Full or Partial) and the signals that ran
  • Every confirmed dead-code row includes manual reachability evidence; tool output alone is not confirmation
  • Priorities P0–P3 with concrete next OpenSpec change names
  • Separate backend vs frontend debt
  • Name archived OpenSpec changes with dates when marking complete
  • Include verification note if tests were not green
Step 6 — Git exclude maintenance

Append to .git/info/exclude if missing:

refactoring.md
refactoring-backend.md
refactoring-frontend.md
docs/split-*-openspec-prompt.md
docs/*-openspec-prompt.md

Do not commit .git/info/exclude changes (it is local by design).

Step 7 — Optional OpenSpec prompt

When user wants the next refactoring step or P0 item needs OpenSpec:

  • Create docs/{kebab-case-change}-openspec-prompt.md (English)
  • Use the prompt template in templates.md
  • Add path to .git/info/exclude
Step 8 — User summary

Reply in English with:

  • Audit date
  • Top 3 backend + top 3 frontend debts (from current metrics)
  • Top structural smell + convention categories (with counts; name paths only from this run)
  • Dead-code coverage, confirmed counts, and unverified candidate counts by kind
  • What closed since last audit
  • Recommended next 2–3 actions (OpenSpec names)
  • Confirm docs are git-excluded

Analysis heuristics

God module candidates: service/hook/component >400 lines, or spec >1000 lines (from metrics).

Structural smell candidates: metrics smell sections — else-if ≥8, def.key === dispatch ≥3, switch ≥10 cases, nested ternary on same line.

Convention violation candidates: metrics violation sections + repo-rules-checklist greps.

Dead-code candidates: TypeScript unused-local diagnostics; Knip unused files, exports, types/members, and dependencies; Nx projects with zero in-repo dependents. Treat all as candidates until reachability and external-consumer checks are complete.

Backend smells: Express types in services, duplicate DTO enums, route sync comments, monolithic controller specs, config registry dispatch in service instead of handler map.

Frontend smells: hooks with many server-api imports, god contexts, hardcoded user-facing strings in utils, duplicated inline state when a hook exists, large switch/else-if in components.

Lib smells: libs importing app/server-api/i18n; lib total LOC >8000 without split plan; spec larger than implementation; mega-switch (≥10 cases).

Do not recommend: drive-by refactors unrelated to ranked debt; rewriting generated chat-api-client; deleting code directly from unverified static-analysis output; committing planning docs.

Incremental vs full audit

User requestScope
"Update refactoring plan" / full auditAll three docs
"Backend only"refactoring-backend.md + index backend columns
"Frontend + libs only"refactoring-frontend.md + index
"Prepare OpenSpec prompt for X"Prompt file only + index pointer

Additional resources

© epam, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 6 other files (scripts) in .claude/skills/refactoring-audit of epam/ai-dial-chat.

  • SKILL.md
  • knip-audit.json
  • repo-rules-checklist.md
  • scripts/collect-dead-code.sh
  • scripts/collect-metrics.sh
  • scripts/summarize-knip.mjs
  • templates.md

Open the folder on GitHubat commit 2d66a8d

Compare with similar skills

Refactoring Audit next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Refactoring Audit compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Refactoring Audit this skillepam/ai-dial-chat504—~4.3kAutomated safety check: PassApache-2.0
Code RefinerMathews-Tom/armory328—~3.1kAutomated safety check: PassMIT
Systematic Code Refactoringluongnv89/claude-howto42k—~3kAutomated safety check: PassMIT
Codexskills-directory/skill-codex1.5k3 repos~1.8kAutomated safety check: PassMIT
Code Simplification for ego-litecitrolabs/ego-lite17k—~1.2kAutomated safety check: PassMIT
Code Refactoring Workflowluongnv89/claude-howto42k—~3.1kAutomated safety check: PassMIT

Similar skills

  • Code Refiner

    Mathews-Tom/armory

    Deep code simplification and refactoring preserving behavior across Python, Go, TypeScript, Rust.

    328 GitHub stars~3.1k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated 8 days ago
    DevelopmentAuto-check passed
  • Codex

    skills-directory/skill-codex

    A skill your agent uses when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing

    1.5k GitHub starsUsed in 3 repos~1.8k tokens
    DevelopmentAuto-check passed
  • Finds and implements evidence-backed simplifications in the ego-lite repository, such as dead code, duplicated state and speculative abstractions, without hiding behavior changes.

    17k GitHub stars~1.2k tokensUpdated 15 days ago
    DevelopmentAuto-check passed
  • Code Refactoring Workflow

    luongnv89/claude-howto

    Guides systematic, test-backed refactoring in the style of Martin Fowler, moving through research, planning and small incremental changes with your approval at each phase.

    42k GitHub stars~3.1k tokensUpdated 8 days ago
    DevelopmentAuto-check passed
  • Tech Debt Analyzer

    ailabs-393/ai-labs-claude-skills

    This skill should be used when analyzing technical debt in a codebase, documenting code quality issues, creating technical debt registers, or assessing code maintainability.

    454 GitHub starsUsed in 2 repos~3.9k tokens
    DevelopmentAuto-check passed

More from epam/ai-dial-chat

All 18 skills in this repo
  • Read unresolved GitHub code review threads for the pull request associated with the current branch, classify each comment, and implement and verify required code fixes.

    504 GitHub stars~1.7k tokensUpdated yesterday
    Auto-check passed
  • Create Ticket

    epam/ai-dial-chat

    Interactively create OR update GitHub issues (Bug, Feature, Task) for the current repository.

    504 GitHub stars~4.6k tokensUpdated yesterday
    Auto-check passed
  • Dep Scan

    epam/ai-dial-chat

    Runs Trivy filesystem scan against the repo root and emits structured vulnerability findings (CVE, package, versions) in the SDLC reviewer schema.

    504 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed
  • Figma

    epam/ai-dial-chat

    Design-to-code workflow for Figma designs. An agent skill from epam/ai-dial-chat.

    504 GitHub stars~997 tokensUpdated yesterday
    Auto-check passed
  • Git Ship

    epam/ai-dial-chat

    A skill your agent uses whenever the user wants to commit, push, or ship changes in a git repository.

    504 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed
  • Responsive Design

    epam/ai-dial-chat

    Responsive (mobile + desktop) layout workflow. An agent skill from epam/ai-dial-chat.

    504 GitHub stars~2.7k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Refactoring Audit

What does Refactoring Audit do?

Deep codebase refactoring audit for AI DIAL Chat. An agent skill from epam/ai-dial-chat. Refactoring Audit is an agent skill from epam/ai-dial-chat. Deep codebase refactoring audit for AI DIAL Chat.

When should I use Refactoring Audit?

Refactoring Audit fits situations like: the user asks for a refactoring plan; tech-debt review; god-module analysis; dead/unused-code analysis.

How do I install Refactoring Audit in Claude Code?

Run `npx skills add epam/ai-dial-chat --skill refactoring-audit -a claude-code`. Or copy the skill folder (.claude/skills/refactoring-audit in epam/ai-dial-chat) into .claude/skills/refactoring-audit in your project. Claude Code loads it when a task matches its description.

How do I install Refactoring Audit in Codex?

Run `npx skills add epam/ai-dial-chat --skill refactoring-audit -a codex`. Or copy the skill folder (.claude/skills/refactoring-audit in epam/ai-dial-chat) into .agents/skills/refactoring-audit in your project. Codex loads it when a task matches its description.

Can I use Refactoring Audit in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add epam/ai-dial-chat --skill refactoring-audit -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/refactoring-audit, .gemini/skills/refactoring-audit, .github/skills/refactoring-audit and .opencode/skills/refactoring-audit in your project.

What does Refactoring Audit need to run?

Going by SKILL.md and its folder, Refactoring Audit needs a shell and JavaScript for the scripts in its folder and the command-line tools its instructions call (npm, git, bash, rg and jq). Our summary lists: Node.js; A Bash shell.

Does Refactoring Audit access the network?

SKILL.md contains no URLs. Its commands use npm and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Refactoring Audit safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Refactoring Audit use?

Refactoring Audit is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Refactoring Audit use?

About 4.3k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Refactoring Audit?

Skills that share tags, products or a category with Refactoring Audit: Code Refiner (Mathews-Tom/armory, 328 stars), Systematic Code Refactoring (luongnv89/claude-howto, 42k stars), Codex (skills-directory/skill-codex, 1.5k stars) and Code Simplification for ego-lite (citrolabs/ego-lite, 17k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Refactoring Audit?

epam (a GitHub organization) maintains it in epam/ai-dial-chat, which has 504 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on October 7, 2026.

Source: epam/ai-dial-chat on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.