repository-governance-lifecycle

リポジトリガバナンスのライフサイクル

これは、エージェントが運用するリポジトリを統治するための中枢です。アプリ、ライブラリ、ツール、プラグイン、ハーネス、メタリポジトリに適用されます。Skill Steward 自体は、ドメインのチュートリアルカタログではなく、構造を管理するリポジトリであり続けます。倫理、ブランディング、アーキテクチャ決定記録（ADR）、生きたドキュメント（FAQ）を、決定 → 文書化 → 整理という一貫したループに統合します。

エージェントが構造の変更、主張の変更、永続的なポリシーの変更、またはドキュメント体系の変更を提案または実行する場合は、必ずこのループに従ってください。定期的なリポジトリの修復では、当初の目的と本来のゲートを優先してください。修復によって永続的な所有権、ポリシー、根拠、ADR／FAQの内容、または計画の整合性が変わる場合にのみ、このガバナンスループを使用してください。

ガバナンスループ

1. 倫理と境界を確認する（NORTH_STAR）

決定を下す前に、リポジトリの基本憲章と倫理的な基準を確認してください。

• Charter and Ethicsを読み、提案する変更がリポジトリの倫理的な境界に反していないことを確認してください（例：誇大な宣伝をしない、Skill Steward内にドメインのチュートリアルを置かない、そのリポジトリの製品に関するドメイン文書は、統治対象の製品リポジトリに置く）。
• North Star Rulesを読み、拡張モデルを理解してください。
• 永続的な構造変更については、north_star_impactをnone、applies、clarifies、sub_star、amends、conflictsのいずれかに分類してください。所有権、ポリシー、根拠の正確性、ADR／FAQの内容、またはリポジトリの中心が変わる可能性がある場合にのみ、このプロトコルを使用してください。
• 永続的なガバナンス対象を編集する前に、ゲートの質問に答えてください。きっかけとなった問題は何か、それがどのNorth Starの価値への道筋に役立つのか、それは仕組みなのか新たな中心なのか、リポジトリが所有するものや拒むものを変えるのか、変える場合はADRがどこにあるのか、変えない場合は仕組みが使命にならないようにどのチェックを設けるのか。
• noneとappliesは本来のワークフローで、clarifiesはFAQ／スキル／マップ／チェックの更新で、sub_starは明示的な親子境界の設定で扱います。amendsまたはconflictsの場合は、実装前にADRとNorth Starの差分が必要です。

2. 決定を記録する（ADR）

アーキテクチャ上重要な決定を下した場合（またはT1-T8のしきい値に達した場合）は、必ず記録してください。エージェントのコンテキストウィンドウにしか存在しない決定は有効ではありません。

• ADR Formatの書式ルールに従って、正式な決定記録を作成してください。

3. 生きたドキュメントを更新する（FAQ）

決定によって、リポジトリの日々の運用方法が変わります。常に最新の記録を更新してください。

• docs/DESIGN_FAQ.mdx（Why）またはdocs/DX_FAQ.mdx（How）を更新してください。
• 質問を検索しやすく、簡潔にするため、FAQ Formatの正確な構成ルールに従ってください。

4. ブランドとトーンのアイデンティティを適用する

ADR、FAQ、またはユーザー向けドキュメントを作成する際は、リポジトリのトーンを厳守してください。

• 企業のマーケティング用語は使用しないでください。
• Brand Guidelinesの禁止語リストを確認してください（例：「unlock」、「supercharge」、「ultimate」は使用しないでください）。

5. 計画の整理（クリーンアップ）

古くなった計画資料（task.md、implementation_plan.md）を恒久的なドキュメントとして残さないでください。

• ADR と FAQ を更新すれば、知識は永続化されています。
• 残っている有用なコンテキストを抽出し、作業用ファイルは削除するか、無視してください。
• 古くなったドキュメントや内容が重複する計画以外のドキュメントは、編集前に対応方針を一つ選んでください：維持、統合、ADR に移動、FAQ に移動、スキルに移動、チェックに移動、エビデンスに移動、利用側の証明に移動、または削除。
• この変更によって縮小または不要になる既存ドキュメントがないか確認してください。
• 正式なアーキテクチャはそれを管理するリポジトリに置いてください。利用側のリポジトリには、採用の証明、ローカルでの差分、ブロック状態、管理元へのリンクを含めてください。
• 分割、圧縮、昇格、降格、削除、ネイティブのまま維持といった、より広範な表層の形状に関する判断は、ガバナンスのみの方針を独自に作るのではなく、repo-quality-system-lifecycle と 進化的シンプルさ を通じて進めてください。
• ADR／エビデンスノート内のスチュワード、採用、ハーネス対応済み、成熟度に関する表現を格上げする前に、steward claim check --claim <claim> --evidence <path> --json を実行してください。not_rejected は否定ゲートの結果であり、受け入れを意味するものではありません。

6. エビデンスを適切に振り分ける

実行、計画、議論のすべてをエビデンスにしないでください。振り分けのルールには エビデンス成果物 を使用してください。

• ADR：永続的な決定、トレードオフ、ステータス、または影響。
• FAQ：人間やエージェントが今後も繰り返し尋ねる、定常的な理由や手順。
• スキル：繰り返し使えるエージェントの手順または解釈のループ。
• チェック／ツール／スキーマ／テスト：ドリフト、鮮度、形状、またはブロック状態を確定的に検出するもの。
• 現在の台帳：現状を正確に示す最も弱いステータスと、再実行の手順。
• エビデンス成果物：主張を裏付けたり、将来の動作を変えたりする、実際の実行証明、ブロック状態、パターンレビュー、PDSA ループ、事後分析、未知のケース、または参照資料。
• 削除／取り除く：有用な事実を抽出し終えた、完了済みのチェックリスト、古い計画、またはテンプレート。

エビデンス成果物を新規作成または大幅に更新する場合は、エビデンス成果物 にある正式なエンベロープを使用してください。ADR 0023 では、そのエンベロープが存在する理由を説明しています。

インストール

npx skills add arenukvern/skill_steward --skill repository-governance-lifecycle

ソース

references/sources.md を参照してください。