codebase-design

Design module interfaces, test seams, and architecture boundaries to reduce coupling.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill codebase-design-maicongambini
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: codebase-design
Source: https://github.com/MaiconGambini/opencode-harness-guide/tree/main/skills/codebase-design
Command: npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill codebase-design-maicongambini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It helps you design or refactor modules so that substantial behavior sits behind a small, stable interface, reducing coupling and improving testability across a codebase. ## Core Features & Use Cases - Interface Design: Define the smallest caller-facing interface that hides implementation complexity, including invariants and failure modes. - Seam Evaluation: Identify the highest useful test seam and apply the deletion test to decide whether a module earns its place. - Speculation Control: Avoid speculative abstractions by requiring two real adapters before justifying a new seam. - Use Case: When a service class has grown tangled with its callers, use this Skill to propose a deep module with one real seam that both callers and tests can cross. ## Quick Start Ask the agent to review a module's interface and propose a smaller, more testable boundary using the codebase design method.

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 module interface that reduces coupling?

Identify the caller-facing behavior, then propose the smallest interface that hides the implementation complexity, including invariants and failure modes. Callers and tests should cross the same seam so behavior can change without editing callers.

What is a test seam in software architecture?

A seam is a point where behavior can change without editing the caller, and an adapter is the concrete implementation at that seam. Choosing the highest useful seam lets tests substitute adapters while callers remain unchanged.

When should I create an abstraction versus avoid one?

Prefer one real seam over hypothetical abstractions. One adapter is usually speculation; two real adapters justify the seam. Apply the deletion test: if deleting the module only moves complexity to callers, it earns its place.

What is the deletion test for module design?

The deletion test asks whether removing a module merely pushes its complexity onto callers. If it does, the module earns its place; if not, the module is likely a shallow wrapper that only forwards calls or exposes implementation structure.

When is this design method not appropriate?

Avoid it for trivial modules where an interface would only forward calls or mirror implementation structure. Significant changes should also be routed through the PREVC workflow before editing, so it is not a substitute for planning.