📦 その他 コミュニティ
core-design-principles
複雑な変更要求に対し、Black-Tortoiseデザイン原則(オッカムの剃刀、凝集度と結合度など)を適用し、コード記述前の最終確認を行うSkill。
📜 元の英語説明(参考)
Apply Black-Tortoise design principles (Occam, cohesion/coupling, tool-first assembly, explicit boundaries, deletion-friendly evolution) to a concrete change request; use as a pre-flight checklist before writing code.
🇯🇵 日本人クリエイター向け解説
一言でいうと
複雑な変更要求に対し、Black-Tortoiseデザイン原則(オッカムの剃刀、凝集度と結合度など)を適用し、コード記述前の最終確認を行うSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 この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-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[Skill 名] core-design-principles
コア設計原則(運用チェックリスト)
使用する状況
- タスクが「過剰に構築しやすい」(新しいヘルパー、新しいレイヤー、新しい抽象化)と感じる場合。
- コードをどこに配置すべきか不明な場合。
- 「クイックフィックス」と「正しい境界」のどちらかを選択する必要がある場合。
入力(質問/確認)
- この変更はどの機能/境界コンテキストが所有していますか?
- 次のレイヤーが必要とする最小限の安定したインターフェースは何ですか?
- 副作用はどこにありますか(もしあれば)?
ワークフロー(ツールファースト → アセンブリ)
- ツールを特定します:最小限の再利用可能なユニット(純粋関数、ポート、アダプター、ストアメソッド)。
- クロスコンテキストのインポートなしで、所有者(機能 / ワークスペース / イベント処理 / 統合)に配置します。
- 単方向フローを維持しながら、それを接続するアセンブリ:ファサード/エフェクト/コンポーネントを追加します。
- 削除パスを確認します:機能の削除は、ほとんどがコードの削除であり、絡み合いを解くことではありません。
ハードチェック(早期失敗)
- Presentation → Application → Domain に違反する新しいクロスレイヤーインポートはありません。
- ドメイン側のフレームワークインポートや副作用はありません。
- 「神」ユーティリティはありません。小さく、意図を明らかにするAPIを優先します。
- 状態は一元化されたままです。UIはシグナルにバインドします。
参照
.github/instructions/05-design-principles-copilot-instructions.mdAGENTS.mdおよびsrc/app/**/AGENTS.md
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Core Design Principles (Operational Checklist)
Use when
- A task feels “easy to overbuild” (new helpers, new layers, new abstractions).
- You’re not sure where code should live.
- You need to choose between “quick fix” vs “correct boundary”.
Inputs (ask/confirm)
- What capability/bounded context owns this change?
- What is the smallest stable interface needed by the next layer?
- Where are the side effects (if any)?
Workflow (tool-first → assembly)
- Identify the tool: the smallest reusable unit (pure function, port, adapter, store method).
- Place it in the owner (capability / workspace / eventing / integration) without cross-context imports.
- Add the assembly: facade/effect/component that wires it, preserving unidirectional flow.
- Verify deletion path: removing the feature should be mostly deleting code, not untangling.
Hard checks (fail fast)
- No new cross-layer imports that violate Presentation → Application → Domain.
- No domain-side framework imports or side effects.
- No “god” utilities; prefer small, intention-revealing APIs.
- State stays centralized; UI binds to signals.
References
.github/instructions/05-design-principles-copilot-instructions.mdAGENTS.mdandsrc/app/**/AGENTS.md