codebase-design

Designs deep modules with small interfaces placed at clean seams.

Updated Aug 11, 2026
One-click install
npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill codebase-design-kunj-sharma03
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: codebase-design
Source: https://github.com/Kunj-Sharma03/agent-contextify/tree/main/skills-main/skills/engineering/codebase-design
Command: npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill codebase-design-kunj-sharma03

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases often accumulate shallow modules with large interfaces and thin implementations, making code hard to test, navigate, and maintain. 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: Defines precise terms (module, interface, seam, adapter, depth, leverage, locality) so teams and AI agents discuss architecture consistently. - Dependency-Aware Deepening: Classifies dependencies (in-process, local-substitutable, remote-owned, true external) and prescribes ports-and-adapters strategies for each, via DEEPENING.md. - Parallel Interface Exploration: Uses a Design-It-Twice pattern that spawns multiple sub-agents to propose radically different interfaces, then compares them on depth, locality, and seam placement. - Use Case: When refactoring a cluster of shallow service classes, use this Skill to merge them into one deep module, define a port at the seam, and rewrite tests against the new interface. ## Quick Start Ask the agent to review a module in your codebase and suggest how to deepen its 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
What is a deep module in software design?

A deep module hides a large amount of behavior behind a small interface, giving callers high leverage per unit of interface they must learn. A shallow module is the opposite: an interface nearly as complex as its implementation, which should be avoided.

How do I make a module more testable?

Accept dependencies as parameters instead of constructing them internally, return results instead of producing side effects, and keep the interface surface small. Tests should target the module's interface as the test surface, not internal state.

When should I introduce a port and adapter at a seam?

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 adapters mean a real one.

How do I handle third-party dependencies when deepening modules?

Treat true external services like Stripe or Twilio as injected ports, with tests providing mock adapters. For remote services you own, define a port at the seam with an HTTP adapter for production and an in-memory adapter for tests.

Should I keep old unit tests after merging shallow modules?

No. Once tests exist at the deepened module's interface, old unit tests on the shallow modules become waste and should be deleted. New tests assert observable outcomes through the interface and survive internal refactors.