Architecture review
My personal Agent Skills for coding agents: engineering workflows plus a few personal-use tools. Personalized forks, with every upstream author credited.
npx -y skills add martonpaulo/skills --skill architecture-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Review an existing codebase for high-value architectural improvements, using concrete code evidence to identify weak boundaries, shallow modules, duplication, coupling, scattered responsibilities, and unstable seams.
SKILL.md
2.3 KB, as published. Nobody here has run it
Architecture Review
Perform a broad, evidence-based assessment only when the user invokes this skill. This skill produces recommendations; it does not refactor the codebase.
For an explicitly requested broad reuse or replacement audit, use dont-reinvent-the-wheel for individual candidate decisions while this skill retains ownership of broader architectural findings.
Workflow
- Establish the requested scope and read repository guidance plus relevant architecture documentation. Documentation is useful when present but is never a prerequisite.
- Inspect source code, tests, call sites, dependency direction, and recent change patterns where history is relevant.
- Apply
module-designcriteria to boundaries, interfaces, dependency direction, ownership, test seams, cohesion, and coupling. - Use
domain-modelonly when inconsistent terminology, business rules, or domain boundaries materially affect the architecture. - Identify concrete findings. Each finding must cite files and symbols and explain the observed cost rather than relying on a generic preference.
- Rank findings by impact, confidence, effort, implementation risk, and expected payoff. Prefer a few high-value findings over an exhaustive catalog.
- Write a concise Markdown report in the conversation unless the user requests a file or repository guidance specifies a review location.
Report shape
For each finding include:
- evidence: files, symbols, and behavior;
- problem and practical consequence;
- recommended boundary or responsibility change;
- impact, confidence, effort, risk, and payoff;
- validation needed before implementation.
End with the strongest recommendation and why it should come first. Apply grilling only when a material architectural decision cannot be resolved from code or existing guidance.
Safety and completion
Do not implement a recommendation until the user explicitly selects it. The review is complete when every recommendation is evidence-backed, ranked, and scoped, and uncertainty is visible.