メニュー
フィーチャーモデルから共通アーキテクチャを設計し、 実装コンポーネントを確定した上で、構成の知識（フィーチャー選択から 実装へのマッピングルール）を定義する。 「アーキテクチャを設計したい」「構成の知識を定義したい」 「フィーチャーと実装の対応を決めたい」といった要求があった場合に使用。 フィーチャーモデリングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン設計活動。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
システムを「発注」するためのドメイン固有記法（DSL）を定義する。 フィーチャーの選択とパラメータ指定を宣言的に記述できる形式を設計する。 「仕様の記述形式を決めたい」「DSLを定義したい」「AIへの指示形式を 設計したい」といった要求があった場合に使用する。アーキテクチャ設計の 成果物が存在することが前提。ジェネレーティブプログラミングの ドメイン設計活動。
ドメインスコープからフィーチャーモデルを作成する。 重要概念の洗い出しと共通性・可変性分析を行い、 フィーチャーツリーとフィーチャー間の制約を構造化する。 「フィーチャーを整理したい」「何が変わりうるか分析したい」 「依存関係を定義したい」といった要求があった場合に使用する。 ドメインスコーピングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン分析活動。
DSL仕様書と構成の知識に基づき、指定言語でリストコンテナのコードを生成する。 DSLバリデータの実装もこのスキルで行う。 「コードを生成して」「実装して」「この仕様で作って」といった要求に使用。 構成の知識が存在することが前提。
生成コードの正しさを検証するプロパティベーステストを生成・実行する。 構成の知識に定義された代数的性質と構成固有の性質をテストコードとして出力する。 「テストを生成して」「生成コードを検証して」といった要求に使用。 構成の知識と生成コードが存在することが前提。
システムの目的・利用者・範囲を明確にし、ドメインの境界を定義する。 新しいプロジェクトの立ち上げ時、「何を作るか整理したい」 「スコープを決めたい」「対象ドメインを明確にしたい」といった要求が あった場合に使用する。ジェネレーティブプログラミングのドメイン分析活動。
| name | domain-design |
| description | フィーチャーモデルから共通アーキテクチャを設計し、 実装コンポーネントを確定した上で、構成の知識（フィーチャー選択から 実装へのマッピングルール）を定義する。 「アーキテクチャを設計したい」「構成の知識を定義したい」 「フィーチャーと実装の対応を決めたい」といった要求があった場合に使用。 フィーチャーモデリングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン設計活動。 |
| user_invocable | true |
フィーチャーモデルの可変ポイントをアーキテクチャレベルでどう吸収するかを設計し、 実装コンポーネントを確定した上で、フィーチャー選択から実装へのマッピングルールを定義する。 ジェネレーティブプログラミングのドメイン設計活動。
docs/gp/02-feature-model.md と docs/gp/04-constraints.md が存在するか確認する/feature-modeling）を行うことを推奨する各変化のタイプに対する方式を決定する:
DSLの各記述項目が実装にどう影響するかのルールを定義する:
代表的な変更シナリオでルールが正しく機能するか検証する:
以下のファイルを出力する:
docs/gp/05-architecture.md — アーキテクチャ設計。テンプレート: templates/architecture-template.mddocs/gp/06-components.md — 実装コンポーネント一覧。テンプレート: templates/components-template.mddocs/gp/09-configuration-knowledge.md — 構成の知識。テンプレート: templates/configuration-knowledge-template.md次の活動として以下が推奨される:
/dsl-definition）— まだDSLを定義していない場合/implement）— DSLも定義済みの場合、コード生成に進む