Skip to content
FunCoding

Search

Search docs, Skills and MCP

improve-architecture

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.

代码质量与审查2.9kskills/improve-architecture/SKILL.md

Install

Send this to Claude Code, Codex or Cursor. The agent checks the Skill for safety first and installs it only after you confirm.

读取 https://funcoding.ai/skills/rohitg00/pro-workflow/improve-architecture/install.md ,按里面的步骤帮我安装这个 Skill。

SKILL.md

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

  1. 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.
  2. 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).
  3. 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.
  4. 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).
  5. 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.

Similar Skills

claude-api
anthropics/skills180k

claude-api

Reference for the Claude API / Anthropic SDK — model ids, pricing, params, streaming, tool use, MCP, agents, caching, token counting, model migration. TRIGGER — read BEFORE opening the target file; don't skip because it "looks like a one-liner" — whenever: the prompt names Claude/Anthropic in any form (Claude, Anthropic, Fable, Opus, Sonnet, Haiku, `anthropic`, `@anthropic-ai`, `claude-*`, `us.anthropic.*`, `[1m]`); the user asks about an LLM (pricing/model choice/limits/caching) — never answer from memory; OR the task is LLM-shaped with provider unstated (agent/MCP/tool-definition/multi-agent/RAG/LLM-judge/computer-use; generate/summarize/extract/classify/rewrite/converse over NL; debugging refusals/cutoffs/streaming/tool-calls/tokens). SKIP only when another provider is being worked on (overrides all triggers): OpenAI/GPT/Gemini/Llama/Mistral/Cohere/Ollama named in the query; OR `grep -rE 'openai|langchain_openai|google.generativeai|genai|mistralai|cohere|ollama'` over the project hits (run this grep FIRST if no provider named — don't Read the file).

Code quality & review

ponytail-review
DietrichGebert/ponytail158k

ponytail-review

Quality review of a change: is the logic right, is it safe, does it hold under real load, is risky code tested, is it fast enough, and is every line needed. Reads the connected code, not only the diff. Each finding is explained in plain English. Use for "review this", "code review", "review the last commit", "review my PR", "is this over-engineered", /ponytail-review.

Code quality & review

code-review-and-quality
addyosmani/agent-skills103k

code-review-and-quality

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. Use when asked to review a diff or a pull request, even when the diff is pasted inline.

Code quality & review

documentation-and-adrs
addyosmani/agent-skills103k

documentation-and-adrs

Records decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

Code quality & review

code-simplification
addyosmani/agent-skills103k

code-simplification

Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

Code quality & review

understand
Egonex-AI/Understand-Anything86k

understand

Analyze a codebase to produce an interactive knowledge graph for understanding architecture, components, and relationships

Code quality & review