mcpField
A
abstraction-concrete-examples

abstraction-concrete-examples

github.com/lyndonkl生産性18792 回インストール9 週間前に更新
リポジトリ

abstraction-concrete-examples について

abstraction-concrete-examplesは、抽象的な原則から具体的な詳細までを段階的に整理するスキルです。説明、設計、コミュニケーションに使う階層を構築し、検証して提示する手順を案内します。

主な機能

  1. 013～5段階の抽象度の階段を作成
  2. 02トップダウン・ボトムアップ・中間から展開
  3. 03エッジケースと段階間のつながりを確認
  4. 04評価基準で品質を検証

活用シーン

  1. 01対象に応じて同じテーマを説明
  2. 02原則を実装の詳細に落とし込む
  3. 03設計と上位目標の整合性を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lyndonkl/claude --skill abstraction-concrete-examples

インストール後、Claude Code で/abstraction-concrete-examplesを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

resources/
methodology.md
template.md
resources/evaluators/
rubric_abstraction_concrete_examples.json
resources/examples/
api-design.md
hiring-process.md

詳細

抽象化の階梯フレームワーク

目次

この階梯では、普遍的な原則と具体的な詳細を結ぶ3～5段階のレベルを用います。例：

  • L1：「ソフトウェアは保守しやすいものであるべき」
  • L2：「モジュール型アーキテクチャを使用する」
  • L3：「依存性注入を適用する」
  • L4：「UserService が IUserRepository を注入する」
  • L5：constructor(private repo: IUserRepository) {}

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Abstraction Ladder Progress:
- [ ] Step 1: Gather requirements
- [ ] Step 2: Choose approach
- [ ] Step 3: Build the ladder
- [ ] Step 4: Validate quality
- [ ] Step 5: Deliver and explain

ステップ1：要件を収集する

トピック、目的、対象読者、範囲（4レベルを提案）、開始地点（トップダウン、ボトムアップ、ミドルアウト）をユーザーに確認してください。これにより、階梯がユーザーの実際のニーズに応えるものになります。

ステップ2：アプローチを選択する

トピックが明確で、単純なケースの場合 → resources/template.md を使用します。複数の並行する階梯や通常とは異なる制約がある複雑なケースの場合 → resources/methodology.md を確認します。例を見る場合 → resources/examples/（api-design.md、hiring-process.md）をユーザーに提示します。

ステップ3：階梯を構築する

トピック、3～5段階の異なる抽象度のレベル、レベル間のつながり、2～3個のエッジケースを含む abstraction-concrete-examples.md を作成します。最上位のレベルは普遍的にし、最下位のレベルには測定可能な具体的情報を含め、各レベル間の移行が論理的になるようにしてください。方向の選択肢：トップダウン（原則 → 例）、ボトムアップ（観察結果 → 原則）、ミドルアウト（なじみのある内容から両方向へ）。

ステップ4：品質を検証する

resources/evaluators/rubric_abstraction_concrete_examples.json を使用して自己評価してください。各レベルが明確に異なること、レベル間の移行が明瞭であること、最上位のレベルが普遍的であること、最下位のレベルが具体的であること、エッジケースから洞察が得られること、前提が明記されていること、トピックが逸脱していないこと、明示された目的に沿っていることを確認します。最低基準：平均スコアが3.5以上であること。いずれかの基準が3未満の場合は、提示する前に修正してください。

ステップ5：提示して説明する

完成した abstraction-concrete-examples.md ファイルを提示します。階梯から得られた重要な洞察を強調し、見つかった興味深いエッジケースや緊張関係に触れ、当初の目的に基づく活用方法を提案してください。

よくあるパターン

レベル間の情報共有：

  • 経営幹部には L1～L2（戦略／原則）を共有する
  • マネージャーには L2～L3（アプローチ／手法）を共有する
  • 実装担当者には L3～L5（詳細／具体的内容）を共有する

検証：

  • L5 の実態が L1 の原則に合致しているかを確認する
  • 隣接するレベル間のギャップを特定する
  • 原則が機能しなくなる箇所を見つける

設計：

  • 意思決定の指針として L1～L2 を使用する
  • 要件の詳細化に L3～L4 を使用する
  • 実際の実装に L5 を使用する

ガードレール

行うこと：

  • 各レベルで前提を明示する
  • 原則に疑問を投げかけるエッジケースを検証する
  • 具体的なレベルは本当に具体的にする（数値、測定値、詳細情報を含める）
  • 抽象的なレベルは幅広く適用できるようにする（特定の分野に限定しない）
  • 各レベルが、その一つ前のレベルを踏まえて理解できるようにする

行わないこと：

  • 用語を定義せずに、曖昧な表現（「良い」「より良い」「適切」）を使う
  • レベル間に大きな概念上の飛躍を生じさせる
  • レベルごとに異なるトピックへ逸脱させる
  • 検証のステップを省略する（ルーブリックによる確認で品質を確保します）
  • 専門知識を最初から前提にする。対象読者に合わせて明確に説明する

クイックリファレンス

  • 標準的なケース向けテンプレート：resources/template.md
  • 複雑なケース向けの手法：resources/methodology.md
  • 参考にする例：resources/examples/api-design.md、resources/examples/hiring-process.md
  • 品質ルーブリック：resources/evaluators/rubric_abstraction_concrete_examples.json

コメント

Markdown 対応