dsl-definition

name	dsl-definition
description	システムを「発注」するためのドメイン固有記法（DSL）を定義する。 フィーチャーの選択とパラメータ指定を宣言的に記述できる形式を設計する。 「仕様の記述形式を決めたい」「DSLを定義したい」「AIへの指示形式を 設計したい」といった要求があった場合に使用する。アーキテクチャ設計の 成果物が存在することが前提。ジェネレーティブプログラミングの ドメイン設計活動。

ドメイン固有記法の定義

システムの構成を宣言的に「発注」するための記法を定義するスキル。 AIがこの記法を読み取ってコードを生成・変更する前提で設計する。 ジェネレーティブプログラミングのドメイン設計活動。

前提確認

• docs/gp/05-architecture.md と docs/gp/06-components.md が存在するか確認する
• 存在しない場合、先にアーキテクチャ設計（/architecture-design）を行うことを推奨するが、必要に応じてこの活動から始めてもよい

手順

ステップ1: 記法の目的と利用場面の確認

• この記法を誰が書くかを確認する（開発者、プロダクトオーナー、AI自身など）
• どの場面で使うかを確認する（新規生成、フィーチャー変更、構成切り替えなど）
• 記法に求める表現力のレベルを決める（フィーチャー選択のみ、パラメータ込み、振る舞い記述込みなど）

ステップ2: 記法の形式の設計

フィーチャーモデルの可変ポイントを宣言的に指定できる記法を設計する。

• 記法のフォーマットを選定する（YAML、TOML、Markdown、独自DSLなど）
• フィーチャーモデルの各フィーチャーに対応する記述項目を定義する
• 各可変ポイントの選択肢と既定値を定義する
• パラメータの型と制約を定義する

ステップ3: 記法の構文と意味の定義

• 記法の構文ルールを定義する
• 各記述項目の**意味（セマンティクス）**を明確にする: この項目を変えるとシステムのどこが変わるか
• フィーチャーモデルの制約（requires / excludes）が記法上でどう表現されるかを定義する
• サンプル仕様書を1つ以上作成し、記法が意図通りに機能するか確認する

ステップ4: 成果物の出力

以下のファイルを出力する:

• docs/gp/07-dsl-notation.md — 記法の定義。テンプレート: templates/notation-template.md
• docs/gp/08-dsl-examples/ — サンプル仕様書

ステップ5: 次のステップの案内

次の活動として「ドメイン設計」（/domain-design）が推奨されるが、必要に応じて他の活動に進んだり、以前の活動に戻って成果物を更新してもよい。