Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From frontend-skills
Analyzes codebase architecture, identifies tightly-coupled shallow modules, and guides refactoring toward deep modular interfaces for improved testability.
npx claudepluginhub redpanda-data/ui-harness --plugin frontend-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/frontend-skills:improve-codebase-architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Surface architectural friction, improve testability via module-deepening refactors -> GitHub issue RFCs.
Explores codebases to identify architectural friction and opportunities to deepen shallow modules, improving testability, refactoring, and AI navigability.
Analyzes a codebase to surface architectural friction and propose refactoring opportunities that deepen modules, improve testability, and make the code more AI-navigable.
Discovers architectural friction, proposes deep-module refactors with competing interface designs, and creates RFC issues. Use for improving architecture, finding refactoring opportunities, or making code more testable.
Share bugs, ideas, or general feedback.
Surface architectural friction, improve testability via module-deepening refactors -> GitHub issue RFCs.
This skill is informed by the project's domain model. The domain glossary names good seams; ADRs in the area record decisions the skill should not re-litigate. Read both before exploring.
Deep module = small interface, big implementation. More testable, more AI-navigable, test at boundary not inside. See LANGUAGE.md for the canonical vocabulary (module / interface / seam / adapter / depth / leverage / locality + the deletion test).
Read the project's domain glossary and any ADRs in the area first.
Use Agent(subagent_type=Explore). Look for:
Numbered list: cluster of related modules, why coupled, dependency category, test impact. Use LANGUAGE.md vocabulary for architecture and the project's CONTEXT.md vocabulary for the domain. No interfaces yet.
If a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly ("contradicts ADR-0007 -- but worth reopening because..."). Don't list every theoretical refactor an ADR forbids.
Constraints new interface must satisfy. Rough illustrative code sketch.
Spawn 3+ parallel sub-agents, different constraints each. Outputs: signature, usage, what hides, dependency strategy, trade-offs. Give own recommendation.
Refactor RFC. See REFERENCE.md for template and dependency categories.