codebase-design

Designs deep modules with small interfaces, clean seams, and testable adapters.

Updated May 9, 2024
One-click install
npx skills add https://github.com/AceCodePt/dotfiles --skill codebase-design-acecodept
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: codebase-design
Source: https://github.com/AceCodePt/dotfiles/tree/main/.config/opencode/skills/codebase-design
Command: npx skills add https://github.com/AceCodePt/dotfiles --skill codebase-design-acecodept

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 decision framework for designing deep modules so interfaces stay small while behaviour concentrates behind clean seams. ## Core Features & Use Cases - Deep-module vocabulary: Precise definitions of module, interface, seam, adapter, depth, leverage, and locality, with rejected framings explicitly called out so teams and AI agents use consistent language. - Dependency-aware deepening: Classifies dependencies as in-process, local-substitutable, remote-but-owned, or true external, and prescribes ports-and-adapters or mock strategies per category (see DEEPENING.md). - Parallel interface exploration: Spawns multiple sub-agents to design radically different interfaces for a candidate module, then compares them on depth, locality, and seam placement (see DESIGN-IT-TWICE.md). - Use Case: When refactoring a cluster of shallow service classes, use this Skill to identify the right seam, merge the cluster into one deep module, and rewrite tests against the new interface instead of the old internals. ## Quick Start Ask the assistant to review a module or package in your repo 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?▼

A deep module puts a large amount of behaviour behind a small interface. Reduce the number of methods, simplify parameters, and hide complexity inside the implementation. Judge depth by leverage: how much behaviour a caller gets per unit of interface they must learn.

What is the difference between a seam and an interface?▼

An interface is everything a caller must know to use a module, including invariants, ordering, and error modes. A seam is the location where that interface lives, a place where behaviour can be altered without editing at that point. Seam placement is its own design decision.

When should I introduce a port and adapter?▼

Introduce a port only when at least two adapters justify the seam, typically a production adapter plus a test adapter. One adapter means a hypothetical seam and is just indirection. This applies to remote-owned and true external dependencies.

How do I test a deepened module without mocking everything?▼

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

What are the limitations of the deep-module approach?▼

Depth measured as implementation-lines to interface-lines is explicitly rejected because it rewards padding. The approach also warns against exposing internal seams through the public interface just because tests use them, and against merging modules whose dependencies lack test stand-ins.