speckit-constitution

speckit-constitution

このスキルの内容は、GitHub Spec Kit の公式プロンプトテンプレートに基づいています。

• 上流：https://github.com/github/spec-kit
• ライセンス：MIT License, Copyright GitHub, Inc.（全文は同じディレクトリの LICENSE.txt を参照）
• 適応に関する説明：公式テンプレートはスラッシュコマンドの用途を想定しています。原文の $ARGUMENTS は、ユーザーが会話で提示するリクエストを指します。 コマンド間の参照（speckit.plan など）は、このスキル体系では同名の speckit-* スキルに対応します。 それ以外の内容は上流のものと同じで、書き換えていません。

---

ユーザー入力

$ARGUMENTS

ユーザー入力が空でない場合は、先に進む前に必ず考慮してください。

スコープのガード

このコマンド自体の作業範囲は、プロジェクト憲章自体の更新に限定されます。依存するテンプレートやコマンドは実行時に憲章を読み込みますが、ここでは変更しません。

• ユーザー入力の各部分を、憲章の内容か、それとは別の非ガバナンス上の意図に分類してください。
• 入力に機能の実装、コードの生成、リファクタリング、ビルド、デプロイのリクエストが含まれている場合、それらを実行してはいけません。代わりに、後続の意図として抽出してください。
• 憲章のワークフローに関連しないアプリケーションのソースファイル、機能ルート、コンポーネント、テスト、デプロイファイル、その他の成果物を、作成、変更、削除してはいけません。
• 指示が憲章の内容に該当するかどうか不明な場合は、変更を加える前に確認してください。
• 憲章の更新を完了した後、後続の意図ごとに Next Actions セクションを含めてください。元の意図を記載し、__SPECKIT_COMMAND_SPECIFY__ など適切な後続の Spec Kit コマンドを提案します。ただし、実行してはいけません。
• 非ガバナンス上の意図がない場合は、Next Actions セクションを省略してください。

実行前の確認

拡張フックの確認（憲章の更新前）：

• プロジェクトルートに .specify/extensions.yml が存在するか確認してください。
• 存在する場合はそのファイルを読み込み、hooks.before_constitution キーの下にあるエントリを確認してください。
• YAML を解析できない場合、または無効な場合は、何も伝えずにスキップしてはいけません。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録された必須（optional: false）フックを含め、フックが確認されなかったことをユーザーに伝えたうえで、通常どおり続行してください。
• enabled が明示的に false のフックを除外してください。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、condition 式を解釈または評価しようとしてはいけません。
  • フックに condition フィールドがない場合、またはその値が null／空の場合は、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に任せます。
• 実行可能なフックごとに、optional フラグに応じて次の内容を出力してください。
  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意の事前フック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

  • 必須のフック（optional: false）：

    ## 拡張フック
    
    **自動事前フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    
    上記のブロックを出力した後、先に進む前に必ずフックを実際に呼び出し、完了を待ってください。このエージェント／セッションで自分がコマンドを実行する場合と同じ方法で実行してください（呼び出し方法は、表示されている `{command}` ID と異なる場合があります。たとえば、スキルモードのエージェントでは `/skill:speckit-...` や `$speckit-...` のようになります）。ブロックを出力しただけでは、フックを実行したことにはなりません。
    

• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何もせずにスキップしてください。

概要

.specify/memory/constitution.md にあるプロジェクト憲章を更新します。有効な憲章のひな形は、コマンド実行時に Spec Kit のプリセット／テンプレート解決スタックを通じて constitution-template から解決されます。

次の実行手順に従ってください。

1. リポジトリのルートから {SCRIPT} を実行し、TEMPLATE_CONTENT を現在のテンプレートとして解析します。

   • 共有リゾルバーは、コアテンプレートへのフォールバックより前に、プロジェクトのオーバーライド、プリセットレイヤーの合成、拡張レイヤーを適用します。続行する前に、必ず成功しなければなりません。
   • 失敗した場合は処理を中止し、解決エラーを報告します。寄与するテンプレートレイヤーが1つだけの状態で続行してはなりません。
   • .specify/memory/constitution.md が存在する場合は、現在のプロジェクト固有の値と改訂内容の情報源として読み込みます。新たに解決されたひな形を適用する際も、引き続き該当する情報は保持します。
   • 存在しない場合は、解決されたテンプレートを初期ドキュメントとして使用します。
   • バージョン管理されているテンプレートレイヤーには書き戻さないでください。
   • [ALL_CAPS_IDENTIFIER] 形式のプレースホルダートークンをすべて特定します。 重要：ユーザーがテンプレートで使用されている原則より少ない、または多い原則を求める場合があります。数が指定されている場合はそれに従い、一般的なテンプレートに沿ってドキュメントを更新してください。

2. プレースホルダーの値を収集または導出します。

   • ユーザー入力（会話内）で値が提示されている場合は、それを使用します。
   • それ以外の場合は、既存のリポジトリのコンテキスト（README、ドキュメント、埋め込みの旧版の憲章）から推測します。
   • ガバナンスの日付については、RATIFICATION_DATE は最初の採択日です（不明な場合は質問するか、TODO と記載します）。変更を加える場合、LAST_AMENDED_DATE は今日の日付とし、変更がない場合は前回の日付を維持します。
   • CONSTITUTION_VERSION は、セマンティックバージョニングの規則に従って更新します。
     • MAJOR：後方互換性のないガバナンスや原則の削除、または再定義。
     • MINOR：新しい原則やセクションの追加、またはガイダンスの大幅な拡張。
     • PATCH：明確化、表現の修正、誤字修正、意味に影響しない改善。
   • バージョンの更新区分が曖昧な場合は、確定前に判断の根拠を提示します。

3. 解決されたテンプレートを必須の構成として、更新後の憲章の内容を作成します。

   • すべてのプレースホルダーを具体的な内容に置き換えます（プロジェクトが未定義のままにすることを選んだテンプレート上のスロットを意図的に残す場合を除き、角括弧で囲まれたトークンを残してはなりません。残す場合は、その理由を明記します）。
   • 見出し階層を維持します。置き換え後のコメントは、説明として引き続き必要なものを除き、削除しても構いません。
   • 各原則セクションには、簡潔な名称行を設け、交渉の余地がない規則を段落または箇条書きで記述し、根拠が明白でない場合は明示します。
   • ガバナンスセクションには、改訂手順、バージョニングポリシー、コンプライアンスレビューの要件を記載します。

4. 更新後の憲章ファイルの先頭に、HTML コメントとして Sync Impact Report を記載します。 このレポートは改訂内容を人が確認するための一時的な作業メモであり、ガバナンスの内容ではありません。改訂後の憲章ファイルをコミットする前に削除することが想定されています。

   • バージョン変更：旧版 → 新版
   • 変更した原則の一覧（名称を変更した場合は旧名称 → 新名称）
   • 追加したセクション
   • 削除したセクション
   • プレースホルダーを意図的に保留した場合のフォローアップ TODO

5. 最終出力の前に検証します。

   • 説明のない角括弧付きトークンが残っていないこと。
   • バージョンの行がレポートと一致していること。
   • 日付が ISO 形式（YYYY-MM-DD）であること。
   • 原則が宣言的で、検証可能であり、曖昧な表現（「should」など）を含まないこと。必要に応じて、根拠を添えた MUST／SHOULD に置き換えます。

6. 完成した憲章を .specify/memory/constitution.md に書き戻し、上書きします。

7. 次の内容を含む最終概要をユーザーに提示します。

   • 新しいバージョンと更新の根拠。
   • TODO のプレースホルダー、または手動での対応が必要な保留項目。
   • 推奨コミットメッセージ（例：docs: amend constitution to vX.Y.Z (principle additions + governance update)）。
   • 保留中のガバナンス以外の意図がある場合は、「次のアクション」セクション。

書式とスタイルの要件：

• テンプレートと同じ Markdown 見出しを使用してください（見出しレベルを下げたり上げたりしないでください）。
• 長い根拠の行は、読みやすさを保てるように（できれば 100 文字未満に）折り返してください。ただし、不自然な改行を無理に入れる必要はありません。
• セクション間には空行を 1 行だけ入れてください。
• 行末に空白を入れないでください。

ユーザーから部分的な更新（たとえば、1 つの原則の改訂のみ）が提供された場合でも、検証とバージョン決定の手順を実行してください。

重要な情報が不足している場合（たとえば、批准日がどうしても不明な場合）は、TODO(<FIELD_NAME>): explanation を挿入し、保留項目として Sync Impact Report に記載してください。

.specify/memory/constitution.md だけを書き込んでください。テンプレートのソースファイルを作成または変更しないでください。

実行後のチェック

拡張フックの確認（憲章の更新後）： プロジェクトのルートに .specify/extensions.yml が存在するか確認してください。

• 存在する場合は、それを読み込み、hooks.after_constitution キーの下にある項目を確認してください。
• YAML を解析できない場合、または無効な場合は、黙ってスキップしないでください。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録されている必須（optional: false）フックを含め、フックを確認していないことをユーザーに伝えたうえで、通常どおり続行してください。
• enabled が明示的に false のフックは除外してください。enabled フィールドがないフックは、デフォルトで有効として扱ってください。
• 残りの各フックについて、フックの condition 式を解釈または評価しようとしないでください。
  • condition フィールドがない場合、または null／空の場合は、実行可能なフックとして扱ってください。
  • 空でない condition が定義されている場合は、フックをスキップし、条件の評価は HookExecutor の実装に任せてください。
• 実行可能な各フックについて、optional フラグに基づき、次のように出力してください。
  • 任意のフック（optional: true）：

    ## Extension Hooks
    
    **Optional Hook**: {extension}
    Command: `/{command}`
    Description: {description}
    
    Prompt: {prompt}
    To execute: `/{command}`
    

  • 必須フック（optional: false）：

    ## Extension Hooks
    
    **Automatic Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    

    上記のブロックを出力した後、続行する前に必ずフックを実際に呼び出し、完了するまで待ってください。このエージェント／セッションで自分自身がコマンドを実行する場合と同じ方法で呼び出してください（呼び出し方法は、表示される {command} の ID と異なる場合があります。たとえば、skills モードのエージェントでは /skill:speckit-... や $speckit-... として実行します）。ブロックを出力するだけではフックを実行したことになりません。
• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何もせずにスキップしてください。