done

タスク後の検証（/done）

done は、タスクを完了するための唯一の場所です。各チェックはユーザーが操作する対象に対して実行し、リポジトリのチェックは、そのチェックで対象範囲をカバーできることを示す証拠としてのみ使用してください。

1. 実行内容を記録し、受け入れレーンを選択する

最初の依頼を、変更せずに使える完全な要約として記録します。先に進む前に、その後のユーザーによる修正も要約に反映してください。

Git の初回実行では、git rev-parse --abbrev-ref HEAD の正確な出力をブランチとして、git rev-parse HEAD の正確な出力を検証前の HEAD として記録します。ブランチ名の変更やブランチの切り替えが行われた場合、このカードは無効になります。公開後の実行では、同じカードを再開し、後述の既存 PR のベース再設定手順を明示的に使う場合を除き、ブランチ、検証前の HEAD、ベース、検証済みスナップショットを維持します。

PR に関連する作業では、ここで使用するベースを一度決定します。リポジトリにポリシーがある場合は、それに従ってください。ない場合は、デフォルトと統合ブランチの候補を確認します。

gh repo view --json defaultBranchRef -q .defaultBranchRef.name
git ls-remote --heads origin 'refs/heads/dev*' 'refs/heads/develop*'

明確に有効な dev または develop の統合ブランチを一つ選び、該当するものがなければデフォルトブランチを使用します。候補が複数あり、いずれも妥当と思われる場合は、作業を中断して確認してください。選択した origin の ref だけを更新し、その名前、リモートのベース先端 SHA、マージベース SHA、実行したコマンドを正確に記録します。

git fetch --no-tags origin "+refs/heads/<base-ref>:refs/remotes/origin/<base-ref>"
git rev-parse "refs/remotes/origin/<base-ref>"
git merge-base HEAD "refs/remotes/origin/<base-ref>"

Git を使用しない外部作業では、代わりに信頼できる対象を基準として最新性を記録します。システムが情報を公開している場合は、各対象の安定した ID または URL、環境、バージョンまたはリビジョン、および読み戻しの記録を正確に残します。Git のフィールドとコミットは該当しません。Git と外部の両方を使用する作業では、両方の基準を記録します。

最初の依頼、変更した成果物、すでに実行した操作に基づいて、必要なレーンを決定します。チェックを実行する前に、必要または該当しない理由をそれぞれ添えて、6 つのレーンすべての選択を示してください。通常の確認を求めずに作業を続け、最終判定の前にユーザーによる修正を反映してください。

レーン	選択する条件
コード	ソース、テスト、スクリプト、ビルドの動作、またはランタイムロジックを変更した場合
UI	ユーザーに表示されるインターフェースまたは操作を変更した場合
ドキュメント	ドキュメント、生成された成果物、リンク、アセット、またはナビゲーション経路を変更した場合
グローバル設定またはスキル	エージェントのルール、設定、登録、検出、または呼び出しを変更した場合
外部メタデータまたはデータ	ボード、Issue、PR、データベース、リモートレコード、または計算された外部結果を変更した場合
公開またはデプロイ	リリース、デプロイ、プッシュ、公開パッケージ、ホストされた成果物、または稼働中の利用者に変更が及んだ場合

選択されていないレーンは、除外理由を添えて not-applicable とします。選択したレーンは、その境界にアクセスできない場合でも引き続き必須です。

ゲート。 依頼の要約と該当する最新性の基準が正確であり、6 つすべてのレーンに選択と理由が示され、ユーザーが求めたすべての成果が、それぞれ該当するすべてのレーンに対応付けられていること。無関係なレーンを必須にしてはいけません。

2. 必須レーンをそれぞれ検証する

実際の受け入れ境界に達する、最も範囲の狭いチェックを使用します。コードレーンがないタスクではコードチェックを実行せず、別のレーンの証拠として内部プロキシを使用しないでください。

コード、グローバル設定、またはスキルが必要な場合は、該当するレビューと解析チェックの後に simplify を1回実行します。内容が編集された場合、すべてのレーンと証拠の側面にわたり、変更された内容に依存する受け入れ時の観察結果をすべて破棄します。影響を受けるコードチェックとグローバルチェック、レビューの網羅性、ブラウザー／UI フロー、レンダリング済みのドキュメント／アセット／リンク、外部データまたはメタデータの読み戻し、公開または実際の利用者によるチェックを再実行します。影響を受けるレビューの網羅性は converge-reviews に通してから、該当レーンを verified にします。

レーン	最低限必要な境界証拠
コード	影響を受けるリポジトリ標準の型、lint、ビルド、テストの各チェックを実行します。TypeScript が該当する場合は fix-ts-errors を使用します。対象を絞った初回チェックは許可されますが、必ずワークスペース全体のチェックを少なくとも1回実行してください。記録されたマージベース SHA を比較ベースとして parallel-review を実行し、その converge-reviews の結果を適用して、差分に対する依頼内容を確認します。simplify の追加コメントスキャンはここではブロッキングです。出力されたコメントが差分に残っている場合、このレーンは未検証のままです。スイープモードで reuse-first を実行し、何も返されなかった場合も含め、結果を記録します。simplify は独自のゲートにより変更で導入された重複のみを対象とするため、このレーンの他のチェックでは既存の重複を検出できません。
UI	browser-qa で影響を受けるフローを実行します。影響を受けるすべてのステップが成功することを必須とし、ブラウザーの出力、スクリーンショット、ネットワーク結果、コンソールの状態を記録します。
ドキュメント	レンダリング済みまたは生成された最終成果物を確認し、影響を受けるリンク、アセット、ナビゲーションを実際に操作して確認します。ソーステキストだけでは、レンダリング結果を検証できません。
グローバル設定またはスキル	最終的な設定を解析し、登録と検出を確認します。その後、変更が影響する範囲に応じて、ピッカーでの表示、手動での呼び出し、または実際の利用者の動作を確認します。
外部メタデータまたはデータ	変更した対象をすべて、信頼できるシステムから新たに再取得し、正確な ID、フィールド、件数、合計値を依頼内容および変更台帳と照合します。
公開またはデプロイ	公開された利用者向けの対象または稼働中の環境を、正確なバージョンと環境で確認します。アップロードまたはデプロイのコマンドが成功しただけでは不十分です。

コードレーンでは、Critical および Serious のレビュー指摘を修正して converge-reviews を適用します。continue の場合は続行し、converged の場合は先に進み、blocked-at-cap の場合は停止し、follow-up-proposed の場合は承認境界を提示します。修正によって無効になったチェックのみを再実行します。

共有状態の変更が完了した場合は、その実行ワークフローで作成された、信頼できる同一の読み戻し計画と、反映済み項目の台帳を再利用します。直接観察ではなく推論によってレーンの結論を裏付ける場合は、verify-claims を実行し、その証拠の上限を維持します。

失敗したチェックは修正し、それによって無効になる証拠のみを再確認します。未解決のままの場合、そのレーンを blocked にします。

ゲート。 必須レーンごとに境界を直接示す証拠または具体的な不足点があり、該当レーンで指定されているすべてのチェックについて結果が記録されていること。

3. 状態を割り当てる

すべてのリクエスト項目、レーン、エビデンスの側面に、以下の語彙を使用します。

• verified：最小限の境界エビデンスが、要求された結果を裏付けています。
• pending：必要な作業またはエビデンスが未着手であるか、満たされていない前提条件を待っています。PR がまだ存在しない段階での、PR に依存する CI やレビューは pending です。
• assumed：間接的なエビデンスのみが結果を裏付けています。前提を明記します。
• deferred：検証が意図的に延期されました。誰が、または何が、いつ再開するのかを明記します。
• blocked：前提条件が整った状態でアクションを試みましたが、失敗したか、続行できません。ブロッカーを明記します。
• not-applicable：リクエストおよび変更箇所の対象外であるレーンまたはエビデンスの側面に限り使用できます。対象外とする理由を再度明記します。リクエスト項目にはこの状態を使用しません。

境界エビデンスが不足している場合、エビデンスの上限が生じます。別のレーンが合格しても、verified にはなりません。

ゲート。 各状態は記録されたエビデンスに基づき、verified でない必須の行には、正確な不足点と次のアクションを記載します。

4. レディネスカードを作成する

対象範囲を宣言し、独立したスナップショットとして固定してから、${CLAUDE_SKILL_DIR}/references/readiness-card.md に従ってカードを作成します。今すぐ読み込んでください。このファイルには、作業ツリーの一覧、独立したスナップショットの手順、2 種類のカードテンプレート、file-pr への引き継ぎ、公開後の再検証、PR を作成しない場合のコミット手順が記載されています。これを読み込むまでは、以下の処理を実行しません。

完了。 カードの最新性を記録し、すべてのリクエスト項目を該当するすべてのレーンとともにそれぞれ 1 回ずつ記載し、6 つすべてのレーンと 5 つすべてのエビデンスの側面を報告し、正確な次のアクションが依存関係上実行可能であり、判定が必須の行のうち最も弱いものを超えていないことを確認しました。ready-to-publish は file-pr に引き継ぎます。タスクの完了を報告できるのは ready の場合のみです。