メニュー
ドメインスコープからフィーチャーモデルと概念モデルを作成する。 共通性・可変性分析を行い、フィーチャーツリー、概念モデル（エンティティ・ ユースケース・ビジネスルール）、フィーチャー間の制約を構造化する。 「フィーチャーを整理したい」「何が変わりうるか分析したい」 「概念モデルを作りたい」「依存関係を定義したい」といった要求があった 場合に使用する。ドメインスコーピングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン分析活動。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
フィーチャーモデルと概念モデルから共通アーキテクチャを設計し、 実装コンポーネントを確定する。「アーキテクチャを設計したい」 「実装コンポーネントを決めたい」「変化に強い構造を設計したい」 といった要求があった場合に使用する。フィーチャーモデリングの 成果物が存在することが前提。ジェネレーティブプログラミングの ドメイン設計活動。
アーキテクチャ設計に基づいて実装コンポーネントを実装する。 共通コンポーネントと可変コンポーネントの両方を、構成の知識に 従ってコードとして実装する。「コンポーネントを実装したい」 「実装を始めたい」といった要求があった場合に使用する。 構成の知識の定義が存在することが前提。 ジェネレーティブプログラミングのドメイン実装活動。
フィーチャーの選択から実装コンポーネントへのマッピングルールを定義する。 「構成の知識を定義したい」「フィーチャーと実装の対応を整理したい」 「何を選んだら何が生成されるかを決めたい」といった要求があった場合に 使用する。DSL定義の成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン設計活動。
システムの目的・利用者・範囲を明確にし、ドメインの境界を定義する。 新しいプロジェクトの立ち上げ時、「何を作るか整理したい」 「スコープを決めたい」「対象ドメインを明確にしたい」といった要求が あった場合に使用する。ジェネレーティブプログラミングのドメイン分析活動。
システムを「発注」するためのドメイン固有記法（DSL）を定義する。 フィーチャーの選択とパラメータ指定を宣言的に記述できる形式を設計する。 「仕様の記述形式を決めたい」「DSLを定義したい」「AIへの指示形式を 設計したい」といった要求があった場合に使用する。アーキテクチャ設計の 成果物が存在することが前提。ジェネレーティブプログラミングの ドメイン設計活動。
定義したドメイン固有記法を実際に使える形に実装する。 仕様書のパース、バリデーション、構成オブジェクトへの変換を実装する。 「DSLを実装したい」「仕様書を読み取れるようにしたい」といった 要求があった場合に使用する。DSL定義と構成の知識が存在することが前提。 ジェネレーティブプログラミングのドメイン実装活動。
| name | feature-modeling |
| description | ドメインスコープからフィーチャーモデルと概念モデルを作成する。 共通性・可変性分析を行い、フィーチャーツリー、概念モデル（エンティティ・ ユースケース・ビジネスルール）、フィーチャー間の制約を構造化する。 「フィーチャーを整理したい」「何が変わりうるか分析したい」 「概念モデルを作りたい」「依存関係を定義したい」といった要求があった 場合に使用する。ドメインスコーピングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン分析活動。 |
ドメインスコープに基づき、共通性・可変性分析を行いながらフィーチャーモデルと概念モデルを作成するスキル。 ジェネレーティブプログラミングのドメイン分析活動。
docs/domain/domain-scope.md が存在するか確認する/domain-scoping）を行うことを推奨するが、必要に応じてこの活動から始めてもよいドメインの構成要素を洗い出しながら、各要素が共通（安定）か可変（変化しうる）かを同時に判定する。「何があるか」と「それは変わるか」を対比しながら分析するのが核心。
以下の4つの観点で、要素を洗い出すたびに共通/可変を判定する。
可変と判定した要素については、以下を追記する:
ステップ1の分析結果からフィーチャーを抽出し、ツリー構造に組織化する。
フィーチャー間の依存関係を洗い出す:
変更波及パスを記録する: あるフィーチャーを変更したとき、影響が波及するフィーチャーの連鎖。各関係の理由も記録する。
以下のファイルを出力する:
docs/domain/feature-model.md — フィーチャーモデル。テンプレート: templates/feature-model-template.mddocs/domain/concept-model.md — 概念モデル（エンティティ・ユースケース・ビジネスルール・境界の共通性/可変性分析結果）。テンプレート: templates/concept-model-template.mddocs/domain/constraints.md — フィーチャー間制約と影響関係。制約パターンは references/constraint-patterns.md を参照フィーチャーモデルに矛盾がないか検証する:
問題があればユーザーに報告し、修正を提案する。
次の活動として「共通アーキテクチャの設計」（/architecture-design）が推奨されるが、必要に応じて他の活動に進んだり、ドメインスコーピングに戻って成果物を更新してもよい。