EvolveHQ/docflow

add-convention

コンベンションを追加します — ただし、それが存在すべきかどうか、どこに属するかを評価した上でのみです。このスキルはゲートキーパー兼ルーターであり、単なる記録者ではありません。

Step 0 — 前提条件とコンテキスト

1. リポジトリがブートストラップされていることを確認します。
2. CONVENTIONS.md と AGENTS.md をすべて読み、既存のルールとの重複を検出し、適合性を判断します。

Step 0.5 — 評価（最初に実行）

共有評価プロトコルを実行します。トリアージ（Step 1）とルーティング（Step 2）の質問はこのプロトコルの下で行われます。

• 最初に提供された回答を再利用します。 リクエストまたはこのセッションですでに提供されている適用可能な選択肢（深さを含む）を、回答済みとして扱います。それらを再度尋ねずに要約します。デフォルトが明示的な選択肢を置き換えることは決してありません。すべての重要な選択肢が提供されている場合は、先に進みます。重要な選択肢が欠けているか矛盾している場合にのみ質問します。リポジトリの設定だけでは、現在の回答や実行許可にはなりません。

• 未解決の選択肢に対する深さセレクター。 深さが提供されておらず、選択肢が残っている場合、この評価をどの程度深く行うべきか尋ねます：express — すべての選択肢は推奨デフォルトを取ります。デフォルトが導出できない質問（自由記述の必須項目）のみが尋ねられます。guided — 以下の高インパクトとマークされた質問と、自由記述の必須項目のみが尋ねられます。full — 以下のすべての質問が尋ねられます。リポジトリの CONVENTIONS.md に Assessment depth: が記録されている場合、それを推奨オプションとして事前選択して尋ねます。記録された深さがサイレントに適用されることは決してありません。そうでない場合、リクエストがほとんどまたはまったくコンテキストなしで届いたときは full を推奨し、すでに完全に指定されているときは express を推奨します。どの質問でも、オペレーターは「ここからデフォルトを使用」または「より深く調査」と回答できます。その切り替えを即座に尊重します。

• 質問は 一度に一つずつ、それぞれに 推奨オプション と一行の理由を付けて尋ね、各回答を待ちます。

• 構造化選択（単一選択または複数選択）を使用します。ホストが構造化された単一選択/複数選択の質問ツールを公開している場合はそれを使用し、推奨オプションをマークします。それ以外の場合は、オプションを A/B/C のプレーンテキストでリストし、推奨オプションを指定します。自由記述は、列挙可能なセットが不可能な場合（例：正確な文言）にのみ使用します。

• オペレーターが決定します。 回答なしで質問を先に進めたり、コンテキストなしで呼び出されたときにスコープを推測したりしないでください。

質問（リクエストがすでに回答しているものはスキップ）：

1. 標準化する価値はあるか？ — はい（繰り返し発生する、安定している、テスト可能）またはいいえ（一回限り、重複、変動しやすい、曖昧）。推奨：Step 1 のトリアージによる。この質問が残りをゲートする。 (高インパクト — guided で尋ねられる。)
2. 保存場所 — AGENTS.md ハードルール / CONVENTIONS.md ガイダンス / GLOSSARY.md 用語 / 実際には決定（new-adr スキルに引き継ぐ）。推奨：ルールの性質による（Step 2 参照）。 (高インパクト — guided で尋ねられる：間違った保存場所は移動の手間になる。)
3. 検証ゲートで強制するか？ — はい / いいえ。推奨：いいえ。ルールが機械的にチェック可能でない限り。
4. 文言 — 自由記述（ルールステートメント自体。すべての深さで尋ねられる）。

Step 1 — 評価：これは標準化する価値があるか？

トリアージを適用します。以下の場合、追加に反対を推奨します：

• 既存のコンベンションで（明示的または暗黙的に）すでにカバーされている場合 — 重複する代わりにそれを指摘します。
• 一回限りの決定であり、繰り返し発生しない場合 — 標準化するとノイズが増えます。
• 変動しやすい場合 — 時期尚早なルールは古くて役に立たないものになります。
• 記述されたままではテスト可能または実行可能にするには曖昧すぎる場合。

以下の場合、追加に賛成を推奨します：繰り返し発生する決定であり、その曖昧さが手戻りを引き起こし、安定しており、エージェントが追加の解釈なしに従えるように記述できる場合。何かを行う前に、推奨事項とその理由を述べてください。

Step 2 — ルーティング：どこに属するか？

保存場所を決定し、その選択を説明します：

• エージェントが従わなければならないハードルール → AGENTS.md §ハードルールの箇条書き。内容は CONVENTIONS.md に記述します。交渉の余地のない制約に使用します。
• 作成/プロセスガイダンス → CONVENTIONS.md のセクション。ゲートにはならないが「私たちのやり方」を知らせるために使用します。
• 共有用語/定義 → GLOSSARY.md（存在しない場合は作成 — 最初の用語を追加すると用語集レイヤーが有効になります。記録されたアーティファクトルートに配置します）。リポジトリの CONVENTIONS.md §用語集を読み、それが実際に宣言しているルールを検査します。標準構造は、オプションの H1 見出しとオプションの導入散文、その後にヘッダーが 用語 | 定義 である正確に一つの二列 Markdown テーブルです。すべての用語は独自の行です。用語を見出し、箇条書き、段落として記録したり、二つ目のテーブルや異なる列形状を追加したりしないでください。古いまたは無関係な用語集の規則を述べている §用語集は、このテーブルを採用していません。標準形状を使用し、古い形状をコピーするのではなく、監査スキルの個別に同意されたルールとファイルの移行を提供します。GLOSSARY.md がないことは有効な状態です。このスキルは、用語が実際に追加されている場合にのみ作成します。
• 実際にはコンベンションではなく決定である場合（代替案と結果を伴うアーキテクチャ、製品、または技術の選択） → これは ADR です。停止して new-adr スキルを提供します。決定を CONVENTIONS に埋め込まないでください。

コンベンションがトリアージ/プロセスルール（例：受信作業のトリアージ方法）である場合、CONVENTIONS.md を推奨し、交渉の余地のない部分についてのみ AGENTS.md にハードルールの箇条書きを追加します。

Step 3 — ドラフトと確認

保存先ファイルの正確な文言をドラフトします。簡潔で、テスト可能で、リポジトリの言語で記述します。差分を表示します。書き込む前に確認します。

Step 4 — 書き込みとコミット

編集を適用します。コンベンションがハードルールに格上げされる場合、AGENTS.md と CONVENTIONS.md の一貫性を確保します。 Conventional Commit (docs: ...)。ADR に触れていない場合は Rationale: フッターは不要ですが、リポジトリの契約がコンベンション変更時にそれを要求する場合は追加します。

用語集の追加または拡張。 以下で定義された標準構造と宣言されたルールチェックを使用します。形状は実行間でずれてはなりません。

• ルールの出所。 CONVENTIONS.md に §用語集セクションがない場合（それより前のレガシーリポジトリ、またはルールが記録される前に有効になったレイヤー）、上記の製品デフォルト標準形状にフォールバックします：オプションの # 用語集 見出しと導入散文、その後一つの 用語 | 定義 テーブル。そのリポジトリのために異なる形状を発明したり、無関係なコンベンションをサイレントに編集したりしないでください。
• 宣言されたルールの読み取り。 §用語集が存在する場合、それが実際に宣言しているものを読みます。標準の二列 用語 | 定義 テーブルを記述している場合はそれに従い、明示的なリクエストがあった場合にのみ変更します。異なるまたは古い用語集の規則（箇条書き、散文、別の列形状）を述べている場合、リポジトリはこのテーブルを採用していません。古い形状をコピーせず、ルールをサイレントに書き換えないでください。用語には標準形状を使用し、監査スキルの移行を提供します。これはルールとファイルを別々に同意された差分としてカバーします。
• 規則の記録。 §用語集がない場合、追加される用語とは別の確認済みの編集として、CONVENTIONS.md に ## 用語集 セクションを記録して実際に使用された形状を記載することを提案します。その差分を表示し、ユーザーが受け入れた場合のみ書き込みます。他の CONVENTIONS.md セクションを書き換えたり並べ替えたりして場所を作ることは決してせず、ユーザーが辞退した場合は、用語集を標準のままにしますが、CONVENTIONS.md は変更しません。
• ファイルの作成。 オプションの # 用語集 見出しとリポジトリが必要とする短い導入散文を書き込み、その後、ヘッダー 用語 | 定義 を持つ単一の二列テーブルと、新しい用語を最初の行として書き込みます。プレースホルダーの用語を発明しないでください。
• 既存ファイルの拡張。 見出し、導入散文、エントリの順序、および既存のすべての行をバイト単位で保持します。新しい用語を一つの新しい行として追加します。ファイルを再構築、再ソート、または再フォーマットしたり、二つ目のテーブルを導入したりしないでください。
• アンカー。 新しい用語の行が、受信リンクがすでに使用している見出しアンカーから到達可能な場合、ターゲットを削除するのではなく、そのアンカーを行に保持します。アンカーを保持できない場合は、推測する代わりに停止してフラグを立てます。
• 意味を保持。 用語のスペル、エイリアス、リンク、インラインコードをそのまま保持します。リテラルのパイプは \| としてエスケープします。定義が本当に複数行にわたる場合は、余分な行に溢れさせるのではなく、ハードブレークに <br> を使用して一つのセルに保持します。
• 重複と曖昧さ。 用語がすでに存在する場合、既存の定義と提案された定義を表示し、更新するか既存の行をそのままにするかを尋ねます。同じ用語の行をサイレントにマージ、置換、または追加したり、定義を推測したりしないでください。
• 非標準ファイル。 既存の GLOSSARY.md が箇条書き、散文、見出し、または混合形状である場合、競合する行を追加したり、用語追加の副作用としてファイルを書き換えたりしないでください。非標準構造を表面化し、監査スキルの同意された移行を提供します。ユーザーが具体的な差分を受け入れた場合のみ適用します。辞退された移行は、ユーザーが維持するファイルをそのまま残します。

実行されたルールと伝播を命名します。更新されなかったリポジトリをリストします。

クロージングレポート

ブロックされた、失敗した、停止した実行を含むすべての実行を、正確に ステータスの概要 という見出しのセクションで終了します。このセクションには次の3つのラベルが含まれます。

• 今回の実行： 実際に試みられたアクションとその結果のみ。各検証ゲートの正確な出力と終了コード（タイムアウトや中断を含む）を引用します。
• 全体： 実装済み、部分的に検証済み、検証済み、ブロック済み、失敗、または不明。合格したサブステップは全体の合格ではありません。不完全または欠落している証拠が成功になることは決してありません。
• 未完了： 残っているすべてのアクション、未解決の調査結果、検証、クリーンアップ、または必要な入力。タスク全体が検証可能に完了している場合のみ「なし」と記述します。予算が尽きたために作業を省略しないでください。

定期的な進捗メッセージはブロックを必要としません。最終結果は簡潔に保ち、PR で準備された作業と、出荷が確認された作業を区別します。