Skill

interface-design

Designing minimal, cohesive, role-based interfaces that respect Interface Segregation Principle.

Install

Run in your terminal

npx claudepluginhub sethdford/claude-skills --plugin engineer-code-quality

Tool Access

This skill uses the workspace's default tool permissions.

Skill Content

Similar Skills

agent-harness-construction

Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.

ecc

140.7k

agent-payment-x402

Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.

ecc

140.7k

agent-eval

Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.

ecc

140.7k

Stats

Parent Repo Stars3

Parent Repo Forks0

Last CommitMar 11, 2026

Actions

View Source View Plugin View on GitHub View README

Domain Context

Role-Based: An interface should represent one role; avoid "fat" interfaces

Minimal: Include only methods the client actually calls; every method is a burden

Cohesive: All methods serve the same purpose; unrelated methods signal bad design

Explicit Contracts: Clients know what to expect and what can fail

Change Isolation: Changes to implementation don't ripple to clients

Instructions

Identify Clients: Who uses this interface? What do they actually need?

List Required Methods: Only methods clients call; omit implementation details

Check Cohesion: Do all methods work toward the same goal? If not, split the interface

Verify Minimal: Can you remove any method without breaking clients? If yes, remove it

Document Contracts: What do methods guarantee? What can fail? Use structured comments

Check Mutability: Should some methods be on a separate "mutator" interface?

Review Generics: Do generic parameters complicate the contract? If yes, simplify

Plan Evolution: How will this interface change? Make room for extension without breaking

Anti-Patterns

Creating "fat" interfaces with 20 methods; forces clients to implement/mock unused methods (Interface Segregation violation)

Mixing concerns (data access + transformation) in one interface; clients should pick the pieces they need

Exposing implementation details in interface signatures (getInternalState() exposes architecture)

Ignoring variadic or default arguments; they complicate the contract and hide complexity

Not versioning interfaces; breaking changes ripple to all clients without warning

Assuming interface will never change; design for extension, not rigidity