| name | dsl-definition |
| description | システムを「発注」するためのドメイン固有記法（DSL）を定義する。 フィーチャーの選択とパラメータ指定を宣言的に記述できる形式を設計する。 「仕様の記述形式を決めたい」「DSLを定義したい」「AIへの指示形式を 設計したい」といった要求があった場合に使用する。アーキテクチャ設計の 成果物が存在することが前提。ジェネレーティブプログラミングの ドメイン設計活動。
|
ドメイン固有記法の定義
システムの構成を宣言的に「発注」するための記法を定義するスキル。
AIがこの記法を読み取ってコードを生成・変更する前提で設計する。
ジェネレーティブプログラミングのドメイン設計活動。
前提確認
docs/architecture/architecture.md と docs/architecture/components.md が存在するか確認する- 存在しない場合、先にアーキテクチャ設計（
/architecture-design）を行うことを推奨するが、必要に応じてこの活動から始めてもよい
手順
ステップ1: 記法の目的と利用場面の確認
- この記法を誰が書くかを確認する（開発者、プロダクトオーナー、AI自身など）
- どの場面で使うかを確認する（新規生成、フィーチャー変更、構成切り替えなど）
- 記法に求める表現力のレベルを決める（フィーチャー選択のみ、パラメータ込み、振る舞い記述込みなど）
ステップ2: 記法の形式の設計
フィーチャーモデルの可変ポイントを宣言的に指定できる記法を設計する。
- 記法のフォーマットを選定する（YAML、TOML、Markdown、独自DSLなど）
- フィーチャーモデルの各フィーチャーに対応する記述項目を定義する
- 各可変ポイントの選択肢と既定値を定義する
- パラメータの型と制約を定義する
ステップ3: 記法の構文と意味の定義
- 記法の構文ルールを定義する
- 各記述項目の**意味（セマンティクス）**を明確にする: この項目を変えるとシステムのどこが変わるか
- フィーチャーモデルの制約（requires / excludes）が記法上でどう表現されるかを定義する
- サンプル仕様書を1つ以上作成し、記法が意図通りに機能するか確認する
ステップ4: 成果物の出力
以下のファイルを出力する:
docs/dsl/notation.md — 記法の定義。テンプレート: templates/notation-template.mddocs/dsl/examples/ — サンプル仕様書
ステップ5: 次のステップの案内
次の活動として「構成の知識の定義」（/configuration-knowledge）が推奨されるが、必要に応じて他の活動に進んだり、以前の活動に戻って成果物を更新してもよい。
