speckit-constitution

ユーザー入力

$ARGUMENTS

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

スコープガード

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

• ユーザー入力の各部分を、憲章の内容か、独立したガバナンス対象外の意図のいずれかに分類してください。
• 入力に機能の実装、コード生成、リファクタリング、ビルド、デプロイの依頼が含まれている場合は、それらを実行してはいけません。代わりに、後回しにする意図として抽出してください。
• 憲章ワークフローに関係のないアプリケーションのソースファイル、機能ルート、コンポーネント、テスト、デプロイファイル、その他の成果物を作成、変更、削除してはいけません。
• 指示が憲章の内容に該当するか不明な場合は、変更を行う前に確認を求めてください。
• 憲章の更新を完了した後、後回しにする意図ごとに Next Actions セクションを含めてください。元の意図を記載し、/speckit-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 の実装に委ねてください。
• フックのコマンド名からコマンド呼び出しを構築する際は、ドット（.）をハイフンに置き換えてください。たとえば、speckit.git.commit → /speckit-git-commit です。
• 実行可能な各フックについて、optional フラグに応じて次の内容を出力してください。

  • 任意フック（optional: true）：

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

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

    ## Extension Hooks
    
    **Automatic Pre-Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    
    Wait for the result of the hook command before proceeding to the Outline.
    

    上記のブロックを出力した後、続行する前に、実際にフックを呼び出して完了を待つ必要があります。このエージェント／セッションで自分がコマンドを実行する場合と同じ方法で実行してください（たとえば、skills モードのエージェントでは、文字列 {command} のコマンド ID と異なる /skill:speckit-... や $speckit-... などで呼び出す場合があります）。ブロックを出力するだけでは、フックを実行したことにはなりません。

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

概要

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

次の実行フローに従ってください。

1. リポジトリのルートから .specify/scripts/bash/resolve-template.sh constitution-template --json を実行し、TEMPLATE_CONTENT をアクティブなテンプレートとして解析します。

   • 共有リゾルバーは、コアテンプレートへのフォールバックより前に、プロジェクトのオーバーライド、プリセットレイヤーの合成、拡張レイヤーの適用を行います。続行する前に、必ず処理を成功させてください。
   • 失敗した場合は、解決エラーを報告して停止してください。寄与するテンプレートレイヤーのうち一つだけを使って続行してはいけません。
   • .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)）。
   • 保留中のガバナンス以外の意図がある場合は、Next Actions セクション。

書式とスタイルの要件：

• テンプレートと同じ 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 の実装に委ねてください。
• フックのコマンド名からコマンド呼び出しを組み立てる際は、ドット（.）をハイフンに置き換えてください。たとえば、speckit.git.commit → /speckit-git-commit です。
• 実行可能なフックごとに、optional フラグに応じて以下を出力してください。

  • 任意のフック（optional: true）：

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

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

    ## 拡張フック
    
    **自動フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    

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

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