design-an-interface
複数のサブエージェントを並行稼働させ、モジュールのAPI設計、インターフェースの選択肢検討、モジュール形状の比較など、多様なインターフェースデザインを生成するSkill。
📜 元の英語説明(参考)
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when: user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
🇯🇵 日本人クリエイター向け解説
複数のサブエージェントを並行稼働させ、モジュールのAPI設計、インターフェースの選択肢検討、モジュール形状の比較など、多様なインターフェースデザインを生成するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o design-an-interface.zip https://jpskill.com/download/14830.zip && unzip -o design-an-interface.zip && rm design-an-interface.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/14830.zip -OutFile "$d\design-an-interface.zip"; Expand-Archive "$d\design-an-interface.zip" -DestinationPath $d -Force; ri "$d\design-an-interface.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
design-an-interface.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
design-an-interfaceフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
インターフェースの設計
"A Philosophy of Software Design" の "Design It Twice" に基づきます。最初のアイデアが最良である可能性は低いでしょう。根本的に異なる複数の設計を生成し、比較してください。
ワークフロー
1. 要件の収集
設計する前に、以下を理解してください。
- [ ] このモジュールはどのような問題を解決しますか?
- [ ] 呼び出し元は誰ですか? (他のモジュール、外部ユーザー、テスト)
- [ ] 主要な操作は何ですか?
- [ ] 何か制約はありますか? (パフォーマンス、互換性、既存のパターン)
- [ ] 何を内部に隠し、何を公開すべきですか?
「このモジュールは何をする必要があるのか?誰がそれを使うのか?」と自問してください。
2. 設計の生成 (並列サブエージェント)
Task ツールを使用して、3つ以上のサブエージェントを同時に生成します。それぞれが根本的に異なるアプローチを生み出す必要があります。
各サブエージェントのプロンプトテンプレート:
以下のインターフェースを設計してください: [モジュールの説明]
要件: [収集された要件]
この設計の制約: [各エージェントに異なる制約を割り当てます]
- エージェント 1: "メソッド数を最小限に抑える - 最大1〜3個のメソッドを目指す"
- エージェント 2: "柔軟性を最大化する - 多くのユースケースをサポートする"
- エージェント 3: "最も一般的なケースに最適化する"
- エージェント 4: "[特定のパラダイム/ライブラリ]からインスピレーションを得る"
出力形式:
1. インターフェースシグネチャ (型/メソッド)
2. 使用例 (呼び出し元がどのように使用するか)
3. この設計が内部に隠すもの
4. このアプローチのトレードオフ
3. 設計の提示
各設計を以下とともに示します。
- インターフェースシグネチャ - 型、メソッド、パラメータ
- 使用例 - 呼び出し元が実際にどのように使用するか
- 隠蔽するもの - 内部に保持される複雑さ
ユーザーが比較する前に各アプローチを理解できるように、設計を順番に提示します。
4. 設計の比較
すべての設計を示した後、以下について比較します。
- インターフェースのシンプルさ: メソッド数が少なく、パラメータが単純
- 汎用 vs 特化: 柔軟性 vs 焦点
- 実装効率: 形状は効率的な内部処理を可能にするか?
- 深さ: 重要な複雑さを隠す小さなインターフェース (良い) vs 薄い実装を持つ大きなインターフェース (悪い)
- 正しく使用しやすい vs 誤用しやすい
トレードオフについて、表ではなく文章で議論します。設計が最も異なる点を強調します。
5. 統合
多くの場合、最良の設計は複数のオプションからの洞察を組み合わせたものです。以下を自問してください。
- 「どの設計があなたの主要なユースケースに最も適していますか?」
- 「組み込む価値のある他の設計からの要素はありますか?」
評価基準
"A Philosophy of Software Design" より:
インターフェースのシンプルさ: メソッド数が少なく、パラメータが単純 = 学習しやすく、正しく使用しやすい。
汎用性: 変更なしで将来のユースケースに対応できます。ただし、過度の一般化には注意してください。
実装効率: インターフェースの形状は効率的な実装を可能にしますか?それとも扱いにくい内部処理を強制しますか?
深さ: 重要な複雑さを隠す小さなインターフェース = 深いモジュール (良い)。薄い実装を持つ大きなインターフェース = 浅いモジュール (避ける)。
アンチパターン
- サブエージェントに類似の設計を作成させない - 根本的な違いを強制する
- 比較をスキップしない - 価値は対比にある
- 実装しない - これは純粋にインターフェースの形状に関するもの
- 実装の労力に基づいて評価しない
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
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:
- Interface signature - types, methods, params
- Usage examples - how callers actually use it in practice
- 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