team-constitution

team-constitution

このスキルでできること

対話形式で、{TEAM_AI_DIRECTIVES}/context_modules/constitution.md にチーム憲章を作成または改訂します。

team-setup（モード 3）が作成するひな形には、プレースホルダー（「チーム全体の原則はまだ定義されていません」）しか含まれていません。このスキルでは、ガイド付きの聞き取りを通じて、プレースホルダーを実際の憲章にします。

• チームのコンテキスト（既存のルール、CDR、AGENTS.md）に基づいて原則を提案します
• 各原則を対話形式で確認します。承認、編集、または却下できます
• 確立されたチーム形式（OKF v0.2 のフロントマター＋番号付き原則＋ガバナンスセクション）で憲章を作成します

このスキルが対象としないもの：

• spec-kit の spec.constitution テンプレート機能を移植したものではありません。プレースホルダートークン、フック、extensions.yml、テンプレートの反映、Sync Impact Report はありません
• セマンティックバージョニングではありません。チーム憲章は、チーム AI 指示リポジトリのGit 履歴でバージョン管理します。鮮度は、/team-repair によって OKF v0.2 のフロントマター（generated、verified、stale_after）で追跡します
• プロジェクトレベルの憲章（docs/adlc/memory/constitution.md、レガシーの .adlc/memory/constitution.md フォールバック）は対象外です。spec-kit を使用している場合、これらは引き続き spec.constitution の対象です

使用するタイミング

• team-setup モード 3 の実行後：ひな形にプレースホルダーが作成されるため、実際の原則を設定します
• 新しいチーム AI 指示（クローンまたは既存）：憲章がない、またはプレースホルダーのままの場合
• 原則の改訂：チームが原則の追加、言い換え、削除を希望する場合

使用しないタイミング

• プロジェクトレベルの憲章：docs/adlc/memory/constitution.md（レガシーの .adlc/memory/constitution.md フォールバック）には、spec-kit の spec.constitution を使用してください
• CDR フローを通じた憲章の変更：憲章の変更が CDR として提案された場合は、/team-levelup で処理してください
• チーム AI 指示が設定されていない場合：先に /team-setup を実行してください

プロセス

ユーザー入力

$ARGUMENTS

入力が空でない場合は、先にユーザー入力を必ず確認してください。

ユーザー入力の例：

• "テストとセキュリティの原則に重点を置く" — これらの領域を中心に提案します
• "原則 3 を改訂する" — 特定の原則の改訂に直接進みます
• "AI によるコードレビューについての原則を追加する" — 指定された原則を追加します
• 空の入力：聞き取り全体のフローに進みます（作成または改訂を自動検出）

役割とコンテキスト

チームが譲れない原則を明確にできるよう支援するチームガバナンスファシリテーターとして行動します。役割には以下が含まれます。

• 一般的な定型文ではなく、チームの実際の指示や慣習に根ざした原則を提案します
• すべての原則が宣言的で、検証可能であり、明確な根拠を持つようにします
• 憲章を簡潔に保ちます。原則は規則であり、論説ではありません

概要

1. 環境を設定する（フェーズ 0）：パスを解決し、憲章の状態を検出します
2. チームのコンテキストを読み込む（フェーズ 1）：既存の憲章とチームの指示を読み、提案の参考にします
3. 原則を聞き取る（フェーズ 2）：作成・改訂の対話ループ
4. ガバナンスセクション（フェーズ 3）：簡潔なガバナンスの段落を作成します
5. 憲章を書き込む（フェーズ 4）：OKF v0.2 のフロントマターを付けてファイルを書き込みます
6. コミットと概要（フェーズ 5）：コミットを提案し、結果を報告します

実行手順

フェーズ 0：環境のセットアップ

スキルのベースディレクトリからセットアップスクリプトを実行します。

scripts/bash/setup-team-constitution.sh

JSON を解析して、REPO_ROOT、TEAM_AI_DIRECTIVES、CONSTITUTION_FILE、CONSTITUTION_STATE、TD_IS_GIT、TD_CLEAN を取得します。

セットアップスクリプトが利用できない、または失敗した場合は、手動で解決します。

1. REPO_ROOT — cwd から上位にたどって .adlc/ を探すか、git rev-parse --show-toplevel、または pwd を使用します。
2. TEAM_AI_DIRECTIVES — TEAM_AI_DIRECTIVES 環境変数、次に .adlc/init-options.json の team_ai_directives、次に REPO_ROOT/team-ai-directives を使用します。
3. CONSTITUTION_FILE — {TEAM_AI_DIRECTIVES}/context_modules/constitution.md
4. CONSTITUTION_STATE：
   • missing — ファイルが存在しない
   • placeholder — ファイルが存在し、「No team-wide principles defined yet」を含む
   • populated — ファイルが存在し、実際の内容がある
5. TD_IS_GIT — git -C "$TEAM_AI_DIRECTIVES" rev-parse --is-inside-work-tree（終了コード 0 = true）
6. TD_CLEAN — git -C "$TEAM_AI_DIRECTIVES" status --porcelain（出力が空 = clean）

TEAM_AI_DIRECTIVES が設定されていない場合：

Team AI directives repository not configured.
Run: team-setup
Or set: export TEAM_AI_DIRECTIVES=/path/to/team-ai-directives

フェーズ 1：チームコンテキストの読み込み

原則の提案に反映するため、以下を読み込みます。

1. 既存の憲章 {CONSTITUTION_FILE}（populated の場合は改訂し、placeholder／missing の場合は作成します）
2. チームルールのインデックス：{TEAM_AI_DIRECTIVES}/CDR.md — 承認済みのルール／ペルソナ／例の記述から、チームがすでに重視している内容を把握できます。
3. 既存のルール：{TEAM_AI_DIRECTIVES}/context_modules/rules/ 内のファイル名と見出しに目を通します。
4. AGENTS.md {TEAM_AI_DIRECTIVES}/AGENTS.md — 読み込み順序とスキルの使用に関する期待事項を確認します。

原則は、確認できた内容に基づいている必要があります。たとえば、ルールディレクトリにセキュリティ関連モジュールが多い場合、「デフォルトでセキュリティを確保する」という原則は根拠に基づくものであり、定型文ではありません。チームの AI 指示がほとんど空の場合は、少数の基本セットに切り替え、その旨を明示します。

フェーズ 2：原則の引き出し

作成モード（missing または placeholder）

1. フェーズ 1 の調査結果に基づき、基本セット（3～7 個）を提案します。各原則について、以下を提示します。

### Proposed Principle N: {Name}

**Statement**: {Declarative, testable rule — one or two sentences}

**Rationale**: {Why this principle exists; what failure it prevents}

**Grounding**: {What team context motivated this — or "starter suggestion, no team AI directives evidence yet"}

Reply: [Y] accept / [e] edit / [n] reject

2. 各回答に対して：

   • Y：承認済みリストに追加します
   • e：ユーザーの編集を反映し、修正した原則を確認のために提示します
   • n：その原則を取り下げます

3. 基本セットを提示した後、**「追加する原則はありますか？」**と尋ねます。ユーザーが終了するまで繰り返します。

改訂モード（populated）

1. 現在の原則を一覧表示します（番号付き、各項目は 1 行）。
2. どうするかを尋ねます：amend N ／ add new ／ remove N ／ full review。
3. 改訂と追加には、作成モードと同じ提案 → 確認／編集／却下の手順を適用します。
4. 削除については明示的に確認します。削除は影響が最も大きい変更です。

原則の品質基準（承認するすべての原則に適用）：

• 宣言的で検証可能：エージェントが順守を確認できる（「すべての X は Y でなければならない」）ものであり、願望にとどまるもの（「X を重視する」）ではありません。
• 交渉の余地がない表現：原則は MUST です。好みや慣習は憲章ではなくルールに記載します。
• 根拠を含める：その原則が防ぐ失敗について、1 文で記載します。
• 曖昧な表現を使わない：「should」を MUST／NEVER に置き換えるか、ルールに移します。

フェーズ 3：ガバナンスセクション

短いガバナンスセクションを作成します。次の 3 点に限定し、内容を広げないでください。

## Governance

- **Amendments**: proposed as CDRs via `/team-init` or `/team-levelup`, reviewed and published via `/team-levelup`. Direct edits via `/team-constitution` are reserved for bootstrapping and explicit team decisions.
- **Compliance**: this constitution is loaded by `team-boot` at the start of every session. Agents and humans MUST follow it; on conflict, the constitution supersedes ad-hoc practices.
- **Alignment**: `/team-repair` (Check 6) verifies project constitutions inherit these principles. Project constitutions may extend, never contradict.

フェーズ 4：憲章の作成

{CONSTITUTION_FILE} を次の構成どおりに記述します。

---
type: Constitution
title: "{TEAM_NAME} Constitution"
description: "Team-wide principles and governance"
resource: ./context_modules/constitution.md
tags: [constitution]
generated: { by: agent:team-constitution, at: {TODAY}T00:00:00Z }
id: constitution
cdr_ref: null
created: {TODAY}
verified:
  - { by: agent:team-constitution, at: {TODAY}T00:00:00Z }
status: stable
stale_after: 180d
---

# {TEAM_NAME} Constitution

1. **{Principle Name}**
   {Statement. Rationale.}

2. **{Principle Name}**
   {Statement. Rationale.}

...

## Governance

{Governance section from Phase 3}

作成ルール：

• 既存の OKF v0.2 フロントマターのフィールドは、修正時も保持してください。generated.at を今日の日付に更新し、verified リストに追加します。ファイルにカスタムフィールド（created、id、cdr_ref）がある場合は保持してください。レガシーな v0.1 フィールド（timestamp、modified、age_days、evidence）があれば削除してください。これは /team-repair が自動で処理します。
• title と H1：チーム名が既にある場合はそれを維持し、ない場合はチームの AI ディレクティブディレクトリ名から決めるか、確認してください。
• 番号付きのフラットリスト（1. **Name**）を使用します。原則ごとの ### サブセクションや、バージョン／批准日を示す行は使用しません。
• CONSTITUTION_STATE が missing の場合は、先に親ディレクトリを作成します。mkdir -p "{TEAM_AI_DIRECTIVES}/context_modules"。

フェーズ 5：コミットと要約

TD_IS_GIT が true で、TD_CLEAN が true の場合は、現在のブランチへの単一コミットを提案します（ブランチ／PR のフローはありません。それは CDR のライフサイクルの役割です）。

Commit the constitution update to team-ai-directives?
  git -C "{TEAM_AI_DIRECTIVES}" add context_modules/constitution.md
  git -C "{TEAM_AI_DIRECTIVES}" commit -m "docs: {create|amend} team constitution — {N} principles"
[Y/n]

TD_CLEAN が false の場合は、コミットの提案を省略し、チーム AI ディレクティブに未コミットの変更があることを記載します。

次の内容を報告します。

## Team Constitution Summary

**Mode**: {Create | Amend}
**File**: {CONSTITUTION_FILE}
**Principles**: N ({added} added, {amended} amended, {removed} removed)
**Committed**: {yes | no — reason}

### Principles

1. {Name} — {one-line statement}
2. ...

### Next Steps

1. Run `/team-repair` to validate the team AI directives and refresh verification timestamps
2. Review project constitutions for alignment (team-repair Check 6)

主なルール

定型文ではなく、根拠に基づくこと

• 提案では、利用できる場合はチームのコンテキスト（CDR の記述、ルールの見出し、AGENTS.md）を引用してください。
• チーム AI ディレクティブが空の場合は、スターターセットが汎用的であることを伝え、3～5 項目に絞ってください。

チーム形式のみ

• OKF v0.2 フロントマター＋番号付きの原則＋ガバナンスを使用します。spec-kit のテンプレート構造は使用しません。
• **Version**／**Ratified** の行は使用しません。バージョン管理には Git 履歴を使用します。
• 原則ごとの ### サブセクションは使用せず、番号付きのフラットリストにします。

自動ではなく、対話形式で

• すべての原則は、書き込む前にユーザーの確認を得てください。
• 既存の populated な憲章を黙って書き換えてはいけません。修正モードでは、原則ごとに明示的な判断が必要です。

混同しないこと

• プロジェクト憲章（docs/adlc/memory/constitution.md）は対象外です。
• CDR に基づく憲章の変更には、このスキルではなく /team-levelup を使用します。

ワークフローのガイダンスと移行

/team-constitution の後

/team-setup (Mode 3 scaffold — placeholder constitution)
    ↓
/team-constitution (this skill — real principles)
    ↓
/team-repair (validate team AI directives, refresh freshness)

継続的な修正は CDR のライフサイクル（/team-init または /team-levelup → 仕様策定 → 明確化 → 公開）に従います。明示的な対話形式の編集には /team-constitution を使用できます。

検証

• {CONSTITUTION_FILE} が存在し、OKF v0.2 フロントマター（type: Constitution と generated フィールドを含む）を備えている
• placeholder マーカーのテキストが残っていない
• すべての原則に、太字の名前、宣言的な記述、根拠がある
• 3 つの項目（修正、遵守、整合性）を含むガバナンスセクションがある
• プレースホルダートークン（[ALL_CAPS]）やバージョン／批准日を示す行がない
• 修正したファイルでは、既存のカスタムフロントマターフィールドが保持され、modified が更新されている
• モード、原則の件数、コミット状況を含む要約が報告されている

設定

• TEAM_AI_DIRECTIVES — チーム AI ディレクティブへのパス（.adlc/init-options.json の設定より優先されます）。
• .adlc/init-options.json — team_ai_directives フィールドを含むプロジェクトレベルの設定ファイル。
• デフォルトのフォールバック：プロジェクトルートからの相対パス team-ai-directives/。

12 要素との整合性

要素 XI（ディレクティブをコードとして扱う）— チームの基盤となるガバナンス文書は、バージョン管理された成果物として作成・維持し、プロンプトに場当たり的に埋め込むことはありません。

コンテキスト

$ARGUMENTS