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

Skills เพิ่มเติมจาก 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 vault ด้วย wikilinks และ index notes ใช้เมื่อผู้ใช้ต้องการค้นหา สร้าง หรือจัดระเบียบโน้ตใน Obsidian
productivitydocument
edit-article
mattpocock
แก้ไขและปรับปรุงบทความโดยการจัดโครงสร้างส่วนต่างๆ เพิ่มความชัดเจน และกระชับข้อความ ใช้เมื่อผู้ใช้ต้องการแก้ไข ปรับปรุง หรือพัฒนาร่างบทความ
documentcreative
writing-great-skills
mattpocock
ข้อมูลอ้างอิงสำหรับการเขียนและแก้ไขสกิลอย่างมีประสิทธิภาพ — คำศัพท์และหลักการที่ทำให้สกิลสามารถคาดเดาได้
documentdevelopment