[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HAQ0WCJ63SWNEWK0BA50W":3,"skill-same:01M71HAQ0WCJ63SWNEWK0BA50W":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M71HAQ0WCJ63SWNEWK0BA50W","design-interface",null,"Generate multiple radically different interface designs for a module using parallel sub-agents, then compare trade-offs. Based on \"Design It Twice\" from A Philosophy of Software Design. Use when user wants to design an API, explore interface options, compare module shapes, or mentions \"design it twice\".","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",289,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.codebuddy\u002Fskills\u002Fdesign-interface\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"interface","design interface","design","it","trade","compare","use","module","for","parallel","opus","software","options","generate","philosophy","api","when","explore","trade-offs","design it","2026-11-10 10:12:30",false,"---\nname: design-interface\nmodel: opus\ndescription: \"Generate multiple radically different interface designs for a module using parallel sub-agents, then compare trade-offs. Based on \\\"Design It Twice\\\" from A Philosophy of Software Design. Use when user wants to design an API, explore interface options, compare module shapes, or mentions \\\"design it twice\\\".\"\n---\n\n# Design Interface\n\nBased 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.\n\n> **HARD GATE** — Multiple design options must be explored. Do NOT settle on first idea. Compare trade-offs (UX, complexity, extensibility, performance) before committing.\n\n## Workflow\n\n### 1. Gather Requirements\n\nBefore designing, understand:\n\n- [ ] What problem does this module solve?\n- [ ] Who are the callers? (other modules, external users, tests)\n- [ ] What are the key operations?\n- [ ] Any constraints? (performance, compatibility, existing patterns)\n- [ ] What should be hidden inside vs exposed?\n\nAsk: \"What does this module need to do? Who will use it?\"\n\n### 2. Generate Designs (Parallel Sub-Agents)\n\nSpawn 3+ sub-agents simultaneously using Task tool. Each must produce a **radically different** approach.\n\n```\nPrompt template for each sub-agent:\n\nDesign an interface for: [module description]\n\nRequirements: [gathered requirements]\n\nConstraints for this design: [assign a different constraint to each agent]\n- Agent 1: \"Minimize method count - aim for 1-3 methods max\"\n- Agent 2: \"Maximize flexibility - support many use cases\"\n- Agent 3: \"Optimize for the most common case\"\n- Agent 4: \"Take inspiration from [specific paradigm\u002Flibrary]\"\n\nOutput format:\n1. Interface signature (types\u002Fmethods)\n2. Usage example (how caller uses it)\n3. What this design hides internally\n4. Trade-offs of this approach\n```\n\n### 3. Present Designs\n\nShow each design with:\n\n1. **Interface signature** — types, methods, params\n2. **Usage examples** — how callers actually use it in practice\n3. **What it hides** — complexity kept internal\n\nPresent designs sequentially so user can absorb each approach before comparison.\n\n### 4. Compare Designs\n\nAfter showing all designs, compare them on:\n\n- **Interface simplicity**: fewer methods, simpler params\n- **General-purpose vs specialized**: flexibility vs focus\n- **Implementation efficiency**: does shape allow efficient internals?\n- **Depth**: small interface hiding significant complexity (good) vs large interface with thin implementation (bad)\n- **Ease of correct use** vs **ease of misuse**\n\nDiscuss trade-offs in prose, not tables. Highlight where designs diverge most.\n\n### 5. Synthesize\n\nOften the best design combines insights from multiple options. Ask:\n\n- \"Which design best fits your primary use case?\"\n- \"Any elements from other designs worth incorporating?\"\n\n## Evaluation Criteria\n\nFrom \"A Philosophy of Software Design\":\n\n**Interface simplicity**: Fewer methods, simpler params = easier to learn and use correctly.\n\n**General-purpose**: Can handle future use cases without changes. But beware over-generalization.\n\n**Implementation efficiency**: Does interface shape allow efficient implementation? Or force awkward internals?\n\n**Depth**: Small interface hiding significant complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).\n\n## Anti-Patterns\n\n- Don't let sub-agents produce similar designs — enforce radical difference\n- Don't skip comparison — the value is in contrast\n- Don't implement — this is purely about interface shape\n- Don't evaluate based on implementation effort\n","# Design Interface\n\nBased 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.\n\n> **HARD GATE** — Multiple design options must be explored. Do NOT settle on first idea. Compare trade-offs (UX, complexity, extensibility, performance) before committing.\n\n## Workflow\n\n### 1. Gather Requirements\n\nBefore designing, understand:\n\n- [ ] What problem does this module solve?\n- [ ] Who are the callers? (other modules, external users, tests)\n- [ ] What are the key operations?\n- [ ] Any constraints? (performance, compatibility, existing patterns)\n- [ ] What should be hidden inside vs exposed?\n\nAsk: \"What does this module need to do? Who will use it?\"\n\n### 2. Generate Designs (Parallel Sub-Agents)\n\nSpawn 3+ sub-agents simultaneously using Task tool. Each must produce a **radically different** approach.\n\n```\nPrompt template for each sub-agent:\n\nDesign an interface for: [module description]\n\nRequirements: [gathered requirements]\n\nConstraints for this design: [assign a different constraint to each agent]\n- Agent 1: \"Minimize method count - aim for 1-3 methods max\"\n- Agent 2: \"Maximize flexibility - support many use cases\"\n- Agent 3: \"Optimize for the most common case\"\n- Agent 4: \"Take inspiration from [specific paradigm\u002Flibrary]\"\n\nOutput format:\n1. Interface signature (types\u002Fmethods)\n2. Usage example (how caller uses it)\n3. What this design hides internally\n4. Trade-offs of this approach\n```\n\n### 3. Present Designs\n\nShow each design with:\n\n1. **Interface signature** — types, methods, params\n2. **Usage examples** — how callers actually use it in practice\n3. **What it hides** — complexity kept internal\n\nPresent designs sequentially so user can absorb each approach before comparison.\n\n### 4. Compare Designs\n\nAfter showing all designs, compare them on:\n\n- **Interface simplicity**: fewer methods, simpler params\n- **General-purpose vs specialized**: flexibility vs focus\n- **Implementation efficiency**: does shape allow efficient internals?\n- **Depth**: small interface hiding significant complexity (good) vs large interface with thin implementation (bad)\n- **Ease of correct use** vs **ease of misuse**\n\nDiscuss trade-offs in prose, not tables. Highlight where designs diverge most.\n\n### 5. Synthesize\n\nOften the best design combines insights from multiple options. Ask:\n\n- \"Which design best fits your primary use case?\"\n- \"Any elements from other designs worth incorporating?\"\n\n## Evaluation Criteria\n\nFrom \"A Philosophy of Software Design\":\n\n**Interface simplicity**: Fewer methods, simpler params = easier to learn and use correctly.\n\n**General-purpose**: Can handle future use cases without changes. But beware over-generalization.\n\n**Implementation efficiency**: Does interface shape allow efficient implementation? Or force awkward internals?\n\n**Depth**: Small interface hiding significant complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).\n\n## Anti-Patterns\n\n- Don't let sub-agents produce similar designs — enforce radical difference\n- Don't skip comparison — the value is in contrast\n- Don't implement — this is purely about interface shape\n- Don't evaluate based on implementation effort\n",{"name":5,"model":42,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".codebuddy\u002Fskills\u002Fdesign-interface",24,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add danielvm-git\u002Fbigpowers --skill design-interface",{"tool":72,"command":73},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill design-interface",{"tool":75,"command":76},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill design-interface","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.codebuddy\u002Fskills\u002Fdesign-interface\u002FSKILL.md",true,[],[81,99,106,134,157,178],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":90,"publishedAt":52},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[87],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[91,92,93,94,95,96,97,40,98],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","never",{"skillNo":100,"name":101,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":52},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[105,96],"negative path",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":115,"publishedAt":52},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[112],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[116,117,118,119,120,121,122,123,124,125,38,48,126,127,128,129,130,131,132,133],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","minimal","bold","sonnet","integrity","organize","sync","directory","guides",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":52},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[141,142,143,125,144,38,145,146,147,148,128,149,150,151,152,153,154,48,155,156],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":52},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[164,165,166,167,168,169,170,171,172,173,174,125,175,40,141,128,176,177],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":191,"publishedAt":52},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[184,187,188],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":189,"categoryName":190,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师",[192,193,194,195,196,197,198,199,200,128,201,202,203,204,205,47,206,155,207,208],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","architecture","project status","http api"]