aitormf/agent-skills

レビューの適用

各フィンドゥングごとにユーザーが判断し、承認されたものだけを適用します。

コアルール： 明示的な決定なしに変更を推測、推定、または適用しないでください。フィンドゥングが曖昧な場合は、選択肢を提示する前に明確化を求めてください。各フィンドゥングは個別に決定され、決してグループ化しないでください。

成果物とステータス

• 各作業項目は docs/specs/<YYYYMMDD>-<type>-<name>/ にあります。
• spec.md と plan.md のフロントマターには status: draft | approved | obsolete が含まれています。approved を設定できるのはユーザーのみです。
• approved だった成果物を変更した場合は、ステータスを draft に戻し、その旨を伝えてください。

ステップ 1: フィンドゥングの提示

1. 作業項目とレビューファイル（review-spec.md または review-plan.md）を特定します。不明な場合は尋ねてください。
2. すべてのフィンドゥングを番号付きでリストアップし、ブロッキング（重大）なものを最初に表示します。各フィンドゥングについて以下を表示します：
   • フィンドゥング [N]: レビューの指摘内容。
   • 提案された修正（ある場合）。
   • オプション：
     • A) 修正をそのまま適用。
     • B) 修正を変更して適用（ユーザーが内容を説明）。
     • C) 却下（理由を添える）。
     • D) 保留。

次のステップに進む前に、ユーザーがすべてのフィンドゥングに回答するのを待ちます。

ステップ 2: 確認

決定サマリー
────────────────
[N] <タイトル> → 適用 / 修正適用 / 却下 / 保留

「これらの決定を適用してよろしいですか？」と確認してください。確認なしに先に進まないでください。

ステップ 3: 適用

1. 確認された変更（AおよびB）のみを、レビュー対象の成果物にのみ適用します。それ以外には一切触れないでください。
2. レビューファイル内で、各フィンドゥングの下に下した決定を記録します：
   • 却下したもの：理由。
   • 保留したもの：保留中の内容。
3. ユーザーに状況を伝えます：
   • ブロッキングフィンドゥングが残っていない場合、成果物はユーザーが approved とマークする準備ができているか、または別の review-spec パスを実行する準備ができています。
   • ブロッキングフィンドゥングが保留中の場合、またはリスクを伴う却下がある場合は、その旨を指摘します。

ステップ 4: 他の影響を受ける仕様

ステップ2の決定が他の進行中の仕様に影響を与えるかどうかを確認します：

1. docs/specs/*/spec.md の中から status: draft のものを探します。
2. それぞれについて、決定が競合を引き起こすか、依存関係を変更するか、前提を無効にするかを検討します。
3. 影響を受ける可能性がある各仕様について：
   • どの仕様、どのセクション、何を変更する必要があるかを示します。
   • 「この決定は影響しますか？変更を提案してもよろしいですか？」と尋ねます。「はい」または「いいえ」の回答を待ちます。
4. 回答が「はい」の場合、最小限の変更（該当するセクションと行のみ）をドラフトし、差分を表示し、承認後にのみ適用します。

それらの仕様の他の部分を改善、拡張、または再フォーマットしないでください。不明な点があれば、いつでも停止して質問してください。