mcpField
V
verification-before-completion

verification-before-completion

github.com/ganyuanranテスト・品質1.4k58 回インストール5 日前に更新
リポジトリ

verification-before-completion について

verification-before-completionは、タスク完了を宣言する前に証拠、対象範囲、残るリスクを確認するAegisスキルです。作業の実行者やレビュー担当者向けに、リスクと証拠の強さに応じて検証を整理しますが、完了や受け入れの権限は与えません。

主な機能

  1. 01新鮮で反証可能なチェックの実施
  2. 02L0・L1・L2の検証レベル選択
  3. 03証拠の範囲と不足箇所の記録
  4. 04変更内容と回帰テストの証拠確認
  5. 05タスク完了と要件受け入れの区別

活用シーン

  1. 01コード変更後に対象テストと回帰テストを確認
  2. 02証拠が限られる場合に完了宣言を限定
  3. 03引き継ぎ前に未検証範囲と残存リスクを記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ganyuanran/aegis --skill verification-before-completion

インストール後、Claude Code で/verification-before-completionを入力して読み込まれたか確認します。

同梱ファイルexpanded-closeout.md

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

`activation_mode = "explicit"` または `AEGIS_ACTIVATION_MODE=explicit` が表示されており、 依頼で Aegis またはこのスキルのどちらも指定されていない場合は、チェックリストや形式的な手順を挟まずに ファストパスに戻ります。それ以外の場合は続行します。

実行

成功を主張する前に、破壊的操作の権限を分類し、反証を試みる新しい検証を実行して、 その結果と対象範囲をすべて読み、L0/L1/L2を選択してください。証拠が部分的、 古い、失敗している、または主張の範囲より狭い場合は、評価を下げてください。 完了を主張してから後で検証することは決してしないでください。

この Method Pack は、権威ある GateDecision、PolicySnapshot、 証拠の十分性、要件の受け入れ、または完了を判断する権限を付与しません。

停止シグナル

  • 証拠が不確か、古い、エージェントのみのもの、または主張の範囲より狭い場合。
  • 次のアクションが、コミット、プッシュ、PR、マージ、タグ付け、公開、リリース、または引き継ぎの場合。
  • タスク/スライスの完了が、要件を満たしたことの受け入れとして扱われている場合。
  • ガバナンスまたは廃止に、修正/廃止の証拠がない場合。
  • 既存の古いロジックが残されているのに、保持の理由と廃止のトリガーがない場合。または
  • 複雑性の解消が未解決の場合。

破壊的/不可逆な作業には、対象を限定した許可が必要です。広範な同意は、対象を限定した許可ではありません。

必須の証拠スロット

変更されたインターフェース/インタラクションについて主張する場合は、 ui-ux-governance と、関連する検証ガイダンスを組み合わせてください。実際の結果と、 ユーザーに見える未確認の基準を以下のスロットに記録し、このクローズアウト担当者は この一人に維持してください。

- Evidence action / check performed:
- Result / exit status:
- Covered scope:
- Uncovered scope:
- Residual risk:
- Confidence grade: A | B | C
  • A:対象と回帰を確認済み。意味のある未確認事項はありません。
  • B:対象の証拠あり。残存リスクは限定されています。
  • C:部分的な確認のみ。完全な完了は主張できません。

テストが主張の根拠となる場合は、トリガーとなる処理の連鎖を再現する呼び出し箇所の境界で、 対象テストと関連する回帰の証拠を含めてください。より浅い境界では誤った確信につながります。 境界が欠けている場合は、アーキテクチャ上のギャップです。自動化がブロックされている場合は、 再現可能な手動手順が必要です。どちらも確信度を下げます。

明示的に指定されたベースライン/アーティファクト/担当者/契約/証拠の参照については、 関連する最小限のソースを読み込んでください。影響を受ける参照ごとに、維持、正規の担当者への 再割り当て、理由を明記した廃止、または競合による却下のいずれかを記録してください。 未解決の参照は未確認の範囲に残し、確信度を下げ、再推論しないでください。 読み返しによって、完全なグラフ、参照整合性、または権威ある系譜が証明されることはありません。

継承した主張のクローズアウト

再開した主張と証拠が矛盾する場合は、アクティブな記録にある訂正と、 再開時に何を主張し、なぜ不正確だったのかについての最終的な開示を、独立して確認してください。 現在の成功によって、そのいずれかを補うことはできません。対象、範囲、時点を保持してください。 関連する主張には、1つの説明を適用できます。例示のみ、否定、撤回、または再スコープされた訂正も、 両方を全文で読んでください。引用が一致していても、採用されたことの証明にはなりません。 正確な主張はそのまま維持してください。証拠を確認した後も当初の判断に関する重要な意見の相違が 未解決である場合は、needs-verification と記載してください。レビュアーとの合意を 決して無理に求めないでください。証拠によって解決できた場合は、裏付けのある結論を維持し、 通常どおり検証してください。食い違いがない場合は、このスロットを省略してください。

タスクの Git クローズアウト

変更がある場合は、TaskStartSnapshot と比較して差分を確認してください。 タスクのパスをステージするのはコーディネーターのみです。既存の状態を含めたり、 広範囲をステージしたりしないでください。新たな検証に合格した後は、読み取り専用/変更なし、 許可された no commit、または検証失敗の場合を除き、既定ではローカルコミットを1つ作成してください。 HEAD、メッセージ、ファイル、タスクの差分を読み返してください。 コミット/フックの失敗時は作業を保持し、クリーンであるとの主張を禁止します。フックを回避してはなりません。

Git の記録:ブランチ、SHA/メッセージまたはコミットしない理由、Task clean、 Repository clean、およびタスクで作成された各ブランチ/ワークツリーが、作成、削除、 または理由を付して保持されたか。タスクがクリーンでも、リポジトリ全体がクリーンとは限りません。 また、外部との統合を意味するものでもありません。

コミットの範囲を business、process-only、mixed、または no-commit に分類してください。 失敗した試行のテレメトリは、コミットしない理由になります。docs/aegis/ のみの プロセス差分では、業務の検証をやり直しません。業務/テストの差分がある場合はやり直します。

Aegis Visibility / Single Closeout

完了報告は一つのサーフェスにまとめます。このスキルが唯一の完了報告集約先です。隣接するスキル/L2 カードは情報を提供しますが、このスキルに取って代わったり、競合する最終報告の責任者になったりしてはなりません。 集約は出力の適合性を整えるものであり、ルーティングのトリガーではありません。記入するためだけにスキルを読み込んだり、Trace Digest を出力したり、形式的な手続きを追加したりしないでください。

開始時の可視性が欠けていた場合は、判断/証拠の不足を補い、その内容を明記してください。使用したスキルの一覧や Aegis Contribution Note で代用することはできません。

L0 Fast-Path

小規模でリスクの低い作業では、確認/結果、未確認の範囲/リスク、確信度を一文で自然に述べてもかまいません。

L1 Default Receipt

Aegis の形式が適用される、重要度の高い作業では、このレシートを使用してください。証拠は Evidence strength と Uncovered risk にまとめ、別の報告を追加しないでください。

Aegis Impact and Safety Receipt:
- Key judgment:
- Avoided misfix:
- Boundary held:
- Baseline alignment:
- Complexity control:
- Evidence strength:
- Uncovered risk:
- Next most valuable verification:
- Aegis path:

各項目の意味:Key judgment=責任者/根本原因/要件/完了境界; Avoided misfix=フォールバック/重複/テストへの便宜的な対応/スコープの拡大; Boundary held=契約/責任者/ベースライン/非目標/データ/ランタイムの境界; Baseline alignment=aligned/Design Defect/Implementation Drift/権限情報の不足/要確認/該当なし; Complexity control=完了時の差分/クローズ状況; Evidence strength=最新の確認/結果/範囲/確信度; Uncovered risk=残る不足/残余リスク; Next most valuable verification=次に行う価値が最も高い確認; Aegis path=任意であり、判断や証拠ではありません。

すべての意味項目を監査可能な状態に保てば、自然な表現を使用できます。Semantic Slots、Natural Surface、Governance Receipt は互換性のための名称です。

完了/検証済み/リスクあり/ブロック中を報告してください。明白なトレードオフは説明せず、実行しなかったアクションを列挙しないでください。

L2 Expanded Triggers

いずれかの条件に該当した場合は expanded-closeout.md を読み込んでください。詳細の責任者はこのファイルであり、このファイルはルーティングと最終レシートを担当します。

トリガー詳細の責任者
リリース/マージ/公開/準備状況/引き継ぎReadiness Summary
監査/デバッグ/リリース/長期タスクのレビュー/トレースの依頼Trace Digest
目標/TaskIntentDraft/計画/仕様/Slice CardGoal Closure
プロジェクト/ドメインの意味的な差分Context Impact
対象の docs/aegis/ が変更された、または作業記録が存在するWorkspace Integrity
要件/製品/永続的なアーキテクチャBaseline/ADR
ガバナンス/クリーンアップ/移行/互換性/廃止Governance/Retirement
信頼できる情報源/取り消せない削除destructive-action cards
複雑性に大きな負荷がかかるExpanded Complexity Detail
高リスク、またはユーザーから明示的に詳細な完了報告を求められた場合該当するカード

設定済みの Aegis ワークスペースサポートを使用してください。コマンドは詳細の責任者に記載されています。

Completion Boundary

現在許可されている依頼とその会話コンテキストを、計画/仕様、TaskIntentDraft、または Slice Card と照合してください。古い計画で現在の依頼を覆すことはできません。 正しい対象、要求されたすべてのアクション/条件/成果物、そして実際に利用できる形での納品を確認してください。これらの基準を検証するテストは対象に含まれますが、無関係なチェックの成功や中間出力は含まれません。残作業とその原因を明確に報告してください。一つのスライスだけでタスク全体をクローズしたり、プロジェクト全体の信頼性を証明したりすることはできません。

タスク/スライスの完了とは、許可された停止地点に到達することです。要件の充足が受け入れられたことを意味するものではありません。 Requirement accepted には、ベースライン基準または許可されたリスク受容が必要です。それ以外の場合は needs-verification を使用するか、フレーミング/計画に戻してください。Goal Closure の状態は done | blocked | needs-verification | scope-exceeded です。 Execution Readiness View は入力であり、検証の証拠ではありません。

Complexity Downgrade

重要度の高いコードでは差分を確認し、 using-aegis/references/complexity-governance.md と docs/current/AEGIS_COMPLEXITY_GOVERNANCE_BASELINE.md を使用して、Complexity control の行を一つ出力してください。

新たなフォールバック/アダプター/互換性/ガード/分岐ロジックには、廃止対象の経路または廃止のトリガーが必要です。 Complexity Closure: exceeded-unresolved の場合、完了とはみなせません。 保守対象のソース/テストは、小規模な作業として省略できません。複雑性が増えない、小規模でリスクの低いテキスト編集であれば省略してもかまいません。

出力とプロンプトの衛生管理

セクション名、フィールド名、説明文をローカライズします。コマンド、 パス、識別子、列挙値、製品名、生のエビデンスは変更せず、二言語併記のラベルや複数言語が混在する説明は避けます。

外部出力はエビデンス候補です。まず概要やインデックスを確認し、次に最小限の抜粋を参照します。裏付けのない主張は控えめにします。該当する場合は、Evidence Used、Not Loaded、Next Evidenceを報告します。

コメント