--- name: check-execution user-invocable: false description: > formatter、linter、testerまたはプロジェクト固有のチェックツールを起動する直前と、変更範囲の検証の対象を選ぶ時点（計画の検証コマンドを書くときを含む）に起動する。 --- # formatter・linter・testerの実行本スキルはformatter、linter、testerおよびプロジェクト固有のチェックツールを起動する主体へ、起動手段の選び方を提供する。各ツールの受理形式、出力形式、個別の対処は、そのツールのヘルプ、MCPツールのスキーマ、公式ドキュメントに従う。検証後は「検証結果の診断と警告の判定」を読み、診断本文と担当差分を使って結果を判定する。 ## 変更範囲の検証の対象選定変更範囲の検証で動かすチェックとテストを選ぶとき（計画の検証コマンドを書くとき、実装後に検証する前、実行レビューで直接消費側を求めるとき）は、選ぶ前に`references/verification-scope.md`を全文読み、同書の類型で対象を決める。 ## 統合実行ツール経由の起動 - 対象プロジェクトが統合実行ツール（`pyfltr`など）を採用する場合は、formatter、linter、testerおよびプロジェクト固有のチェックツールを個別に直接起動せず、その統合実行ツールのサブコマンド経由で実行する。設定で無効化したツールも直接起動すれば動作するため、設定による無効化は直接起動への防御にならない。特定のファイルだけを対象にする場合も同じ形でパスを渡す。対象プロジェクトの規範がデバッガー、最小再現、環境ごとの原因の特定などの用途で直接起動を認める場合は、その用途に限り直接起動する - 出力の全量を観測するコマンドや、長大な出力が見込まれるコマンドは、`agents_server`の`start`（`mode`は`shell`）へ渡す（努力目標。委譲元のコンテキストを保護する）。委譲元はmanaged-tempの中に保存先を確保し、標準出力と標準エラーの保存先を`summary_policy`へ記す。委譲先が保存したファイルから必要な範囲を読み、終了状態と警告を検収する。出力が短い局所的な実行で統合実行ツールのMCPサーバーを利用できる場合は、そのMCPツールを使う - シェルからCLIを直接実行する場合は、`agent-toolkit:delegation`の`references/waiting-and-monitoring.md`「背景ジョブの起動形（Claude Code）」が定める長時間コマンドの前景実行に従う ## pyfltrの起動形 - 名前が確定したチェックコマンドの有効状態、実行器、実効コマンドライン、実行ファイルの解決結果を調べる場合は、最初に`pyfltr command-info --output-format=jsonl`でそのコマンドの実効設定を取得する。引数と返却フィールドは`pyfltr command-info --help`の説明に従う。未知のコマンド名の探索、pyfltrの導入およびチェックの実行には、それぞれの目的に対応する既存の呼び出し手段（CLI・MCPツールなど）を使う - pyfltrの起動形は、対象プロジェクトのタスクランナー定義（`Makefile`・`mise.toml`のtasks・`package.json`のscriptsなど）が用いる形へそろえる。この定義を持たない対象プロジェクトでは`uvx pyfltr`を使う - サブコマンドの使い分け、オプションの受理形式、JSONL出力のレコード種別とフィールドの解釈、失敗ツールの再実行手段、ツール解決の失敗への対処は、`pyfltr <サブコマンド> --help`の出力とMCPツールのスキーマで確認する。これらが扱わない設定リファレンスと新規プロジェクトへの導入手順はを取得し、そのページからたどって参照する ## 検証結果の診断と警告の判定検証した主体は、終了コードと要約に加え、診断本文、実行時警告、未到達・未適用・未完了を示す出力を読む。 pyfltrの`commands_summary.needs_action.warning`はコマンド結果の区分の件数であり、個々の診断のwarning件数ではない。この値が0でも診断本文を読み、変更行への指摘の有無を確かめる。出力契約の確認記録は`docs/development/audit-records.md`の「agent-toolkit/skills/check-execution/SKILL.md：検証結果の診断と警告の判定：2026年10月3日」にある。変更行への帰属を判定する基準版と検証対象版を、検証結果・進捗ログまたは引き継ぎ記録へ残す。通常の変更では、実装に着手する直前のHEADを基準版として記録する。レーンは初回実装前のHEADを基準とし、担当種別の切替と履歴統合の後も同じ基準からの累積差分を使う。 CI修正は修正前の版、統合は統合前HEADを基準とする。本節で結果、不足する条件および既存不良を返す先（以下、報告先）は、委譲された主体では委譲元、メインではユーザーとする。メインはユーザーへの報告と確認を`agent-toolkit:user-confirmation-and-report`の「手段の選択」に従って行う。 - 行位置を持つ診断は、検証対象版のファイル・行範囲・ruleと、基準版からのGit差分の追加・変更行を対応付ける - 追加・変更行に位置を持つ診断は、コマンド結果の区分にかかわらず解消するか、意味・影響・残す理由を検証記録へ書く - 行位置のない警告は、発生元・種別・内容・発動条件から帰属を判定する - 位置や帰属を確定できない出力は保留し、不足する条件を報告先へ返す未到達・未適用・未完了を示す出力は、既存か新規かにかかわらず阻害として扱う。警告の意味の判定は`agent-toolkit:bugfix`の`references/response.md`「問題を見つけたときの対処」に従う。処理が成立する警告で、変更による差を確かめる必要がある場合は、警告を観測した検証だけを基準版の結果と比べる。比較する対象範囲、オプション、依存版、並列度と実行環境をそろえ、全出力と終了状態を使う。同じ版と条件の保存結果があれば再利用し、無ければ該当コマンドを1回実行する。比較では診断のファイル・対応する行範囲・rule・内容の多重集合を使う。 Git差分から改名、行挿入と移動による既存行の位置の変化をたどり、同じruleの重複も対応付ける。同件数でも位置・rule・内容が変わった診断は差として扱い、既存行の番号だけがずれた診断は既存として対応付ける。位置のない警告では発生元・種別・内容・発動条件を対応付け、PIDや作業ツリーの絶対パスなど実行ごとに変わる部分は同一性の比較から外す。基準版にも同じ警告があり処理の成立に影響しない場合は、意味、対応と根拠を記録して続行する。是正を要する既存不良は、メインが`agent-toolkit/rules/01-agent.md`「完遂と先送り」に従って扱う。委譲された主体は、観測した出力、直接的原因、修正の対象と方向を委譲元へ返し、是正の要否と時機は委譲元が決める。基準版に無い警告や診断は原因と影響を調べ、是正するか根拠を添えて報告先へ返す。同じ条件の結果を得られない場合や意味を確定できない場合も、理由と不足する条件を報告先へ返す。警告の抑制と検証範囲の縮小は、警告の意味と由来の確認、および必要な是正の代わりにしない。抑制や縮小を選ぶ場合は、この判定を終えて警告の意味を確定した後に、その理由を検証記録へ残す。