jpskill.com
📦 その他 コミュニティ

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. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[Skill 名] core-design-principles

コア設計原則(運用チェックリスト)

使用する状況

  • タスクが「過剰に構築しやすい」(新しいヘルパー、新しいレイヤー、新しい抽象化)と感じる場合。
  • コードをどこに配置すべきか不明な場合。
  • 「クイックフィックス」と「正しい境界」のどちらかを選択する必要がある場合。

入力(質問/確認)

  • この変更はどの機能/境界コンテキストが所有していますか?
  • 次のレイヤーが必要とする最小限の安定したインターフェースは何ですか?
  • 副作用はどこにありますか(もしあれば)?

ワークフロー(ツールファースト → アセンブリ)

  1. ツールを特定します:最小限の再利用可能なユニット(純粋関数、ポート、アダプター、ストアメソッド)。
  2. クロスコンテキストのインポートなしで、所有者(機能 / ワークスペース / イベント処理 / 統合)に配置します。
  3. 単方向フローを維持しながら、それを接続するアセンブリ:ファサード/エフェクト/コンポーネントを追加します。
  4. 削除パスを確認します:機能の削除は、ほとんどがコードの削除であり、絡み合いを解くことではありません。

ハードチェック(早期失敗)

  • Presentation → Application → Domain に違反する新しいクロスレイヤーインポートはありません。
  • ドメイン側のフレームワークインポートや副作用はありません。
  • 「神」ユーティリティはありません。小さく、意図を明らかにするAPIを優先します。
  • 状態は一元化されたままです。UIはシグナルにバインドします。

参照

  • .github/instructions/05-design-principles-copilot-instructions.md
  • AGENTS.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)

  1. Identify the tool: the smallest reusable unit (pure function, port, adapter, store method).
  2. Place it in the owner (capability / workspace / eventing / integration) without cross-context imports.
  3. Add the assembly: facade/effect/component that wires it, preserving unidirectional flow.
  4. 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.md
  • AGENTS.md and src/app/**/AGENTS.md