codebase-design

Designs deep modules with small interfaces placed at clean, testable seams.

1|Updated Jul 2, 2026
One-click install
npx skills add https://github.com/filippolmt/skills --skill codebase-design-filippolmt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: codebase-design
Source: https://github.com/filippolmt/skills/tree/main/skills/codebase-design
Command: npx skills add https://github.com/filippolmt/skills --skill codebase-design-filippolmt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate shallow modules whose interfaces are nearly as complex as their implementations, making code hard to test, navigate, and change. This Skill provides a shared vocabulary and design principles for creating deep modules that hide complexity behind small interfaces. ## Core Features & Use Cases - Deep-module vocabulary: Precise definitions of module, interface, seam, adapter, depth, leverage, and locality so teams and AI agents name things consistently. - Dependency-aware deepening: Classifies dependencies (in-process, local-substitutable, remote-owned, true external) and prescribes ports-and-adapters strategies for each, with replace-don't-layer testing guidance. - Design It Twice workflow: Spawns parallel sub-agents to produce radically different interface designs for a candidate module, then compares them on depth, locality, and seam placement. - Use Case: When refactoring a cluster of shallow service classes, use this Skill to identify the right seam, define a minimal interface, and generate competing interface designs before committing to one. ## Quick Start Ask the AI to review a module in your codebase and propose a deeper interface using the codebase-design vocabulary.

Frequently Asked Questions about codebase-design

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

FAQPage Schema
How do I design a deep module interface?

Start by minimizing the number of methods and simplifying parameters while hiding more complexity inside the implementation. A deep module gives callers high leverage: lots of behavior behind a small interface that also serves as the test surface.

What is the difference between a seam and an interface?

A seam is the location where a module's interface lives and where behavior can be altered without editing in place. The interface is everything a caller must know to use the module, including invariants, ordering, and error modes.

When should I introduce a port and adapter?

Introduce a port only when at least two adapters are justified, typically a production adapter and a test adapter. A single-adapter seam is just indirection; one adapter means a hypothetical seam, two means a real one.

How do I test a deepened module without mocking everything?

Write tests at the deepened module's interface and delete old unit tests on the shallow modules it absorbed. Use local stand-ins like PGLite or in-memory adapters for substitutable dependencies, and mocks only for true external services.

When should I not deepen a module?

Avoid deepening when the module is a genuine pass-through that fails the deletion test, or when merging would force a seam with only one adapter. Also avoid exposing internal seams through the public interface just because tests use them.