sdd-constitution

プロジェクト憲章（openspec/project.md）

憲章とは、このリポジトリのすべての変更が守らなければならない、簡潔で安定したルールのセットです。つまり、AI が仕様を作成したりコードを書いたりする際に破ってはならない「チームのルール」です。OpenSpec は openspec/project.md を読み込み、sdd-feature-flow の Analyze フェーズでは、憲章と矛盾する要件にフラグを立てます（憲章がない場合は、参考情報としてその旨を記録します）。

使用するタイミング

• SDD を導入するリポジトリに、まだ openspec/project.md がない場合（Analyze ゲートで作成が推奨されます）。
• チームの規約、技術スタック、制約が変わり、憲章が古くなった場合。

手順

1. 決めつけずに把握する。 原則を提案する前に、リポジトリを確認して、すでに決まっていることを推測します。README、CONTRIBUTING、既存の CLAUDE.md／AGENTS.md、リンター／フォーマッターの設定、テスト環境、パッケージマニフェスト、CI、およびいくつかの代表的なモジュールを確認します。実際の技術スタック、テスト／リンターのコマンド、ブランチ運用、明らかな規約を記録します。
2. openspec/project.md を作成します。 以下のセクションを含めます（各項目は簡潔にし、散文ではなく原則を記載します）。
   • 目的 — このプロジェクトが何であるかを1段落で記述します。
   • 技術スタックとツール — 言語、フレームワーク、パッケージマネージャー、テスト／リンターのコマンドを記載します。
   • 絶対に守るべき原則 — AI が決して破ってはならないルールです。例：「何をしたかではなく、なぜそうしたかをコメントする」「環境変数による機能フラグは禁止」「すべてのコミットに署名する」「環境ブランチ間のマージは禁止」。一般的なリストではなく、リポジトリとユーザーの発言に基づいて記載します。
   • 規約 — 命名、エラー処理、小数／精度のルール、リソース識別子、ディレクトリ構成など、このリポジトリで正しく動作させるために重要な事項を記載します。
   • ブランチとリリースのフロー — 例：feature → develop → testing → main。PR のデフォルトのターゲットも記載します。
   • 完了の定義 — テストがすべて成功していること、ドキュメントが更新されていること、仕様がアーカイブされていることなどを記載します。
3. リポジトリから確認できなかった推測事項は、ユーザーに確認します。 誤った憲章を設けるくらいなら、憲章がないほうがましです。
4. 検証します。 openspec validate --strict が引き続き成功すること、およびファイルが SDD のフローから自動的に参照されることを確認します（追加の設定は不要です）。

ルール

• 長く理想論的なものより、短く譲れないルールを優先します。強制できない行は削除します。
• すべての原則はリポジトリまたはユーザーの明示的な発言に基づかせます。チームのルールを決して作り上げてはいけません。
• このスキルが書き込むのは openspec/project.md だけです（質問は行います）。本番コードは変更しません。