design-an-interface

작성자: mattpocock

모듈에 대해 병렬 하위 에이전트를 사용하여 근본적으로 다른 여러 인터페이스 디자인을 생성합니다. 사용자가 API를 디자인하거나, 인터페이스 옵션을 탐색하거나, 모듈 형태를 비교하거나, "두 번 디자인하라"고 언급할 때 사용하세요.

npx skills add https://github.com/mattpocock/skills --skill design-an-interface

Design an Interface

Based on "Design It Twice" from "A Philosophy of Software Design": your first idea is unlikely to be the best. Generate multiple radically different designs, then compare.

Workflow

1. Gather Requirements

Before designing, understand:

  • What problem does this module solve?
  • Who are the callers? (other modules, external users, tests)
  • What are the key operations?
  • Any constraints? (performance, compatibility, existing patterns)
  • What should be hidden inside vs exposed?

Ask: "What does this module need to do? Who will use it?"

2. Generate Designs (Parallel Sub-Agents)

Spawn 3+ sub-agents simultaneously using Task tool. Each must produce a radically different approach.

Prompt template for each sub-agent:

Design an interface for: [module description]

Requirements: [gathered requirements]

Constraints for this design: [assign a different constraint to each agent]
- Agent 1: "Minimize method count - aim for 1-3 methods max"
- Agent 2: "Maximize flexibility - support many use cases"
- Agent 3: "Optimize for the most common case"
- Agent 4: "Take inspiration from [specific paradigm/library]"

Output format:
1. Interface signature (types/methods)
2. Usage example (how caller uses it)
3. What this design hides internally
4. Trade-offs of this approach

3. Present Designs

Show each design with:

  1. Interface signature - types, methods, params
  2. Usage examples - how callers actually use it in practice
  3. What it hides - complexity kept internal

Present designs sequentially so user can absorb each approach before comparison.

4. Compare Designs

After showing all designs, compare them on:

  • Interface simplicity: fewer methods, simpler params
  • General-purpose vs specialized: flexibility vs focus
  • Implementation efficiency: does shape allow efficient internals?
  • Depth: small interface hiding significant complexity (good) vs large interface with thin implementation (bad)
  • Ease of correct use vs ease of misuse

Discuss trade-offs in prose, not tables. Highlight where designs diverge most.

5. Synthesize

Often the best design combines insights from multiple options. Ask:

  • "Which design best fits your primary use case?"
  • "Any elements from other designs worth incorporating?"

Evaluation Criteria

From "A Philosophy of Software Design":

Interface simplicity: Fewer methods, simpler params = easier to learn and use correctly.

General-purpose: Can handle future use cases without changes. But beware over-generalization.

Implementation efficiency: Does interface shape allow efficient implementation? Or force awkward internals?

Depth: Small interface hiding significant complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).

Anti-Patterns

  • Don't let sub-agents produce similar designs - enforce radical difference
  • Don't skip comparison - the value is in contrast
  • Don't implement - this is purely about interface shape
  • Don't evaluate based on implementation effort

mattpocock의 다른 스킬

improve-codebase-architecture
mattpocock
코드베이스에서 심화 개선 기회를 찾되, CONTEXT.md의 도메인 언어와 docs/adr/의 결정 사항을 참고합니다. 사용자가 아키텍처를 개선하거나, 리팩토링 기회를 찾거나, 강하게 결합된 모듈을 통합하거나, 코드베이스를 더 테스트 가능하고 AI가 탐색하기 쉽게 만들고자 할 때 사용합니다.
developmentcode-reviewapi
tdd
mattpocock
레드-그린-리팩터 루프를 사용한 테스트 주도 개발. 사용자가 TDD로 기능을 구축하거나 버그를 수정하려 할 때, "레드-그린-리팩터"를 언급할 때, 통합 테스트를 원할 때, 또는 테스트 우선 개발을 요청할 때 사용합니다.
developmenttesting
handoff
mattpocock
현재 대화를 다른 에이전트가 이어받을 수 있도록 핸드오프 문서로 압축합니다.
communicationproject-managementdocument
prototype
mattpocock
디자인을 확정하기 전에 일회용 프로토타입을 만들어 검토합니다. 상태나 비즈니스 로직을 확인할 수 있는 실행 가능한 터미널 앱과, 하나의 경로에서 전환 가능한 여러 개의 완전히 다른 UI 변형이라는 두 가지 분기로 나뉩니다. 사용자가 프로토타입을 만들고, 데이터 모델이나 상태 머신을 검증하며, UI를 목업하고, 디자인 옵션을 탐색하려 하거나, "이걸 프로토타입으로 만들어 봐", "한번 가지고 놀게 해줘", "몇 가지 디자인을 시도해 봐"라고 말할 때 사용합니다.
developmentdesigncreative
triage
mattpocock
트라이지 역할에 의해 구동되는 상태 머신을 통해 이슈를 분류합니다. 사용자가 이슈를 생성하거나, 이슈를 분류하고, 들어오는 버그나 기능 요청을 검토하고, AFK 에이전트를 위해 이슈를 준비하거나, 이슈 워크플로를 관리하려는 경우 사용합니다.
developmentproject-managementcommunication
obsidian-vault
mattpocock
Obsidian 볼트에서 위키링크와 인덱스 노트를 사용하여 노트를 검색, 생성 및 관리합니다. 사용자가 Obsidian에서 노트를 찾거나, 생성하거나, 정리하려 할 때 사용하세요.
productivitydocument
edit-article
mattpocock
기사 초안의 섹션을 재구성하고, 명확성을 높이며, 문장을 간결하게 다듬어 편집하고 개선합니다. 사용자가 기사 초안을 편집, 수정 또는 개선하려 할 때 사용하세요.
documentcreative
writing-great-skills
mattpocock
스킬을 잘 작성하고 편집하기 위한 참고 자료 — 스킬을 예측 가능하게 만드는 어휘와 원칙.
documentdevelopment