test-code

実装後の品質ゲートを実行する。プロジェクトの構成と変更対象から手順を選び、該当する参照ファイルだけを読む。

手順の選択

リポジトリの AGENTS.md、変更差分、プロジェクト定義、既存のテスト設定と CI を確認する。拡張子だけで決めず、実際にテスト対象となるプロジェクト単位で判定する。

• 複数の対象がある場合は、変更したコンポーネントとその影響先ごとに対応する手順を選ぶ。たとえば .NET API と TypeScript フロントエンドを変更したら両方を対象にする。
• package.json がドキュメント用ツールにしか使われていない場合など、構成ファイルの存在だけを理由に対象を追加しない。
• 対象と選定理由を実行前に短く伝える。判定できる場合は言語の選択をユーザーに求めない。
• 対応手順のない言語では、他言語のツールを当てはめない。プロジェクト既定の検証を行い、このスキルの手順では未対応であることを報告する。

セキュリティ検証の選択

品質ゲートには CodeQL、Sanitizer 付きテスト、依存ライブラリの既知脆弱性検査も含める。具体的なコマンド・適用条件は、選択した言語別手順に従う。

• Lint・型チェック・コンパイラ診断はコード規約や型などの検査、CodeQL はクエリによるセキュリティ静的解析、Sanitizer は実行時の検査、依存監査は解決済み依存と既知アドバイザリーの照合。それぞれの成功を他の検証の完了として扱わない。
• 各検証のローカル / 既存 CI の担当、対象コミット、必要な権限・ライセンス・OS・ツールチェーンを着手前に確認する。CI で実行予定というだけでは確認済みにしない。
• 非対応の言語・プラットフォームは理由付きで対象外、適用可能だが環境や権限が不足する場合は未確認とする。未実行を合格にせず、再開条件を記録する。
• 言語別の既存ゲートを維持し、通常テスト成功後に Sanitizer 付きテストを実施する。CodeQL と依存監査も最終判定までに完了する。既存 CI の順序・クエリ・除外・重大度ポリシーを優先する。
• コマンド例の対象・パスを実プロジェクトに置き換え、実行ごとに成果物ディレクトリを用意する。終了コードを直後に記録し、ログ整形のパイプや || true で隠さない。

検査ごとの共通条件

• CodeQL の準備: CLI bundle とクエリパックの版を固定し、対応表・採用版のリリースノートでコンパイラ / SDK との互換性を確認する。codeql version と suite / パックの版を記録する。各言語の例の security-extended は、既存の承認済み suite があればそれに置き換える。
• CodeQL の利用条件: CLI の利用規約と設定条件を確認する。公開リポジトリと非公開リポジトリの利用権・GitHub Code Security 等の契約条件を区別し、ローカル実行なら無条件に無料と仮定しない。対象ソース・依存・ビルド環境へのアクセスを確認する。既存 Actions から SARIF をアップロードする場合は security-events: write 等のジョブ権限も確認する。CI 追加、有料契約、外部サービスへのソース送信をこのスキルだけで許可されたとみなさない。
• CodeQL の結果確認: DB 作成ログ・診断・解析対象ファイル情報から、対象ソースが抽出されたことを確認する。キャッシュによるコンパイル省略、空の DB、一部解析不能を未検出として合格にしない。解析の終了コード 0 は処理成功を示すため、SARIFの runs[].results、ルールの重大度、実行通知・抑制も読む。検出時は rule ID・箇所・データフロー・再現条件を調べる。
• Sanitizer の結果確認: 通常テストとは別のログ・結果を保存し、計装された対象と実行テスト数を確認する。テスト成功に加え、Sanitizer / race 診断がないことを合格条件にする。検出時はスタック・入力・並行実行条件を調べる。検査範囲は実行経路・計装済みコードに限られる。
• 依存監査の対象と結果確認: 解決済みのロック / 依存情報と実際のビルド対象を照合し、ワークスペース・推移的依存・開発時依存の範囲を確認する。監査ツールの対応形式、DB と取得日時（オフラインなら更新日時）、名前・版 / revision の照合方法を記録する。外部送信するパッケージ情報はプロジェクトの通信規約に従う。終了コードとレポートの両方を読み、抽出 0 件・DB 接続失敗・照合不能な依存を未検出にしない。依存が本当にない場合だけ根拠付きで対象外とする。検出時は advisory ID・重大度・依存経路・影響版・修正版・到達可能性を調べる。更新通知は監査の代替にならず、DB の収録範囲で未検出でも安全性の保証にはならない。
• 既存 CI の確認: gh run view <run-id> --repo <owner/repo> --json headSha,status,conclusion,jobs,url 等で対象 SHA と完了を確認し、解析対象・設定・SARIF artifact または同じ解析の alerts / tool status を読む。ジョブの成功表示だけで脆弱性未検出と報告しない。対象コミットが変わったら、古い成果物を変更後の結果として使わない。
• 検出後の判定: 調査・修正後は影響する通常テストと該当検査を再実行し、依存更新ならロック差分も確認する。未解決の基準違反は失敗、重大度ポリシーがなければ未解決の検出を残して合格にしない。誤検出・承認済み例外は根拠と対象を残し、重大度不明の検出や除外追加で合格にしない。

共通の進め方

• 各参照の順序に沿って個別に実行し、前段の失敗を解消してから次へ進む。コマンド例より、プロジェクトの既存スクリプト、パッケージマネージャー、設定、テスト対象を優先する。
• 失敗の原因を調べ、実装やテストを修正する。修正後は影響する検証を再実行し、必要のない全工程のやり直しを繰り返さない。
• カバレッジとミューテーションスコアは 90% 以上を合格ラインとし、意味のあるテストで 100% を目指す。カバレッジは原則ブランチカバレッジだが、Go は標準ツールを優先して文カバレッジを使い、指標名を明記する。達成に見合わない複雑さやコストが生じる場合は、実測値と未達理由を報告し、合格扱いにしない。
• PBT は仕様の不変条件・境界条件・対称性などを表す。カバレッジの数字を埋めるためのテストにしない。
• 合格のためにテストを無効化したり、閾値・解析ルールを緩めたりしない。
• 必要なツールやテスト基盤の整備は対象プロジェクトの規約と依頼範囲に従う。実行環境の不足や外部依存で進めない場合は、原因と再開条件を報告し、同じ失敗を無制限に繰り返さない。
• 未実行・測定不能を成功と扱わない。行・領域カバレッジをブランチカバレッジとして報告しない。

結果の報告

対象プロジェクト、対象コミット（未コミット差分の有無）、実行環境・ツールとバージョン、実行コマンド、各ステップの成否、カバレッジ・ミューテーションの実測値とレポートの場所を簡潔に示す。「確認済み」「失敗・基準未達」「対象外（理由付き）」「未確認（実行できなかった理由付き）」を区別する。

セキュリティ検証は種類ごとに、日時、対象・除外・限界、終了コードと処理成否、検出数・ID・重大度・対応、適用した合否ポリシー、ログ / SARIF / xcresult / 監査 JSON / CI 実行 URL を報告する。検出ありは未解決の基準違反の有無を示し、未検出は対象抽出・検査完了を確認できた範囲に限る。承認済み例外を検出 0 件と記載しない。未確認・対象外には理由を、未確認には再開条件も添える。

このスキルが担当するのは実装後の検証。TDD の実装サイクルはこのスキルの範囲外。コミット・push・PR 作成は、このスキルの呼び出しだけでは許可されたとみなさない。