Agent Skills › rohitg00/pro-workflow › improve-architecture

improve-architecture

GitHub

审计代码库架构，识别耦合、重复和循环依赖等问题。通过最小化重构步骤提出改进计划，而非直接重写。输出优先级排序的重构方案及决策记录，需用户批准后方可执行，旨在逐步优化系统结构。

skills/improve-architecture/SKILL.md rohitg00/pro-workflow

Trigger Scenarios

代码库变得混乱或难以维护需要改善或重构架构遇到模块边界模糊或逻辑重复

Install

npx skills add rohitg00/pro-workflow --skill improve-architecture -g -y

More Options

Use without installing

npx skills use rohitg00/pro-workflow@improve-architecture

指定 Agent (Claude Code)

npx skills add rohitg00/pro-workflow --skill improve-architecture -a claude-code -g -y

安装 repo 全部 skill

npx skills add rohitg00/pro-workflow --all -g -y

预览 repo 内 skill

npx skills add rohitg00/pro-workflow --list

SKILL.md

Frontmatter

{
    "name": "improve-architecture",
    "description": "Audit an area of the codebase and propose the smallest structural moves that improve it - untangle boundaries, kill duplication, fix seams, break cycles. Produces a prioritized plan and decision records, not a rewrite. Use when a codebase feels tangled, hard to change, or is becoming a ball of mud, or when asked to improve or refactor architecture.",
    "user-invocable": true
}

improve-architecture

Invest in the shape of the system a little at a time rather than paying for a rewrite later. This skill diagnoses and proposes; it does not rewrite on its own.

Method

Map first. Get the current shape before judging it - entry points, modules, data flow, who calls whom. Reuse module-map for the one-screen view; do not skip to opinions.
Find the strain. Look for the load-bearing problems, not style nits:
- God modules that everything imports and nothing can change safely.
- Leaky boundaries - a module reaching into another's internals instead of its surface.
- Duplicated logic that drifts (the same rule implemented three ways).
- Wrong seams - the code is split where it does not bend and fused where it does.
- Cyclic dependencies.
- A shape that fights the domain (see domain-modeling - boundaries in code should track boundaries in the language).
Propose the smallest move. For each problem, the least change that relieves it: extract a boundary, collapse a duplicate, invert a dependency, move a seam. Prefer a sequence of safe steps over one big cut.
Rank by leverage. Order the moves by pain relieved over effort. Say which are safe now and which need a test net first (pair with tdd).
Record the big calls. For a structural change a future reader would question, write a decision record in docs/decisions/NNNN-slug.md: context, choice, alternatives rejected, why.

Guardrails

Diagnose, do not rewrite. The deliverable is a plan the user approves before any code moves.
No churn for taste. A move must relieve a named strain; "cleaner" is not a reason.
Three similar lines beat a premature abstraction - do not trade duplication for indirection unless the duplication actually drifts.
Keep behavior fixed. Structural moves are refactors; land them behind green tests.

Output

A prioritized list: each item is the problem, the smallest move, the risk, and whether it needs a test net first. Plus decision records for the big moves. No code changes until the user picks what to do.