improve-codebase-architecture

Identify shallow modules and generate HTML reports with before/after refactor diagrams.

2|Updated Mar 8, 2026
One-click install
npx skills add https://github.com/UniFormTS/UniForm --skill improve-codebase-architecture-uniformts
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: improve-codebase-architecture
Source: https://github.com/UniFormTS/UniForm/tree/main/.agents/skills/improve-codebase-architecture
Command: npx skills add https://github.com/UniFormTS/UniForm --skill improve-codebase-architecture-uniformts

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the problem of architectural friction in codebases caused by shallow modules, tight coupling, and poorly defined seams that make maintenance difficult, testing unreliable, and AI-assisted coding error-prone.

Core Features & Use Cases

  • Deepening Opportunity Identification: Scans the codebase to find shallow modules where the interface is nearly as complex as the implementation, and assesses deepening feasibility based on dependency categories (in-process, local-substitutable, ports & adapters, external mocks).
  • Domain-Aligned Recommendations: Uses project-specific domain language from CONTEXT.md and respects existing architectural decision records (ADRs) to avoid re-litigating settled choices unless real friction warrants revisiting them.
  • Visual HTML Reports: Generates self-contained, interactive reports with before/after diagrams (call graphs, mass diagrams, cross-sections) of proposed refactors, using Tailwind and Mermaid via CDN for clear, editorial visuals.
  • Use Case: For a growing codebase with dozens of small, tightly-coupled utility modules, use this Skill to identify which modules can be consolidated into deep, testable units with clear interfaces, reducing code duplication and improving test coverage.

Quick Start

Use the improve-codebase-architecture skill to analyze your project's codebase and generate a visual report of refactoring opportunities to deepen shallow modules and improve testability.

Frequently Asked Questions about improve-codebase-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I identify shallow modules in my codebase to improve maintainability?

Shallow modules are identified by analyzing codebases for architectural friction where the interface complexity nearly matches the implementation. This process assesses deepening feasibility by classifying dependencies into in-process, local-substitutable, ports & adapters, and external mocks categories.

What is the best way to propose refactoring opportunities without re-litigating settled architecture?

The best way to propose refactoring without re-litigating settled architecture is to align recommendations with existing architectural decision records (ADRs) and project domain language from CONTEXT.md. This ensures proposed refactors respect team decisions unless real friction warrants revisiting them.

How do I generate visual reports of proposed codebase refactors?

You generate visual reports of proposed refactors by creating self-contained HTML files with before and after diagrams. These reports use Tailwind and Mermaid via CDN to display call graphs, mass diagrams, and cross-sections for clear editorial visuals of the refactoring opportunities.

Does architecture review work with tightly-coupled utility modules in growing codebases?

Architecture review works with tightly-coupled utility modules in growing codebases by identifying which modules can be consolidated into deep, testable units with clear interfaces. This reduces code duplication and improves test coverage by applying the deletion test and interface-as-test-surface principles.

When should I not use module deepening for refactoring?

You should not use module deepening for refactoring when the dependency classification reveals external mocks or tightly coupled external dependencies that make interface isolation impractical. Deepening is also avoided if existing ADRs settle the architectural choice and no real friction warrants revisiting.