grade-tests

テストの評価

厳選されたテストメソッドのリストを評価し、PR コメントに使いやすい簡潔なレポートを作成します。主な結果は Pass、Failed、Uncertain、Not applicable のいずれかです。A～F の品質評価は、補足的な診断情報として扱います。このスキルはテストを自動検出しません。呼び出し元（通常は PR 自動化ワークフロー、または対象を特定したリストを持つ人間のレビュー担当者）が、評価するテストまたは範囲を限定した差分を提供します。

Step 0 で対象範囲が限定されたら、次の評価ルールを適用します。

• 本番環境のコンテキストがある場合、採点前に test-gap-analysis を名前で一度だけ読み込み、呼び出し元のコンテキストは per-test-read-only とします。このスキルが管理する構成リファレンスを読みます。この評価基準からミューテーションの証拠を算出したり、単独のワークフローを実行したりしないでください。依存関係、リファレンス、または必須のコンテキストが実際に利用できない場合に限り、N/A／未検証と報告します。
• ミューテーションに関する推論を報告する場合、説明文の中であっても、必ず Likely killed (inferred) または Candidate survivor (unverified) を使用します。
• 以下の評価基準のみを適用し、重複テストへのペナルティなど、追加のヒューリスティックは適用しません。個々の評価を変更する目的で、関連する他のテストを参照しないでください。
• 品質評価が B でも、結果が Failed になるとは限りません。焦点が明確で十分なテストでも、対応すべき変更がない場合があります。

言語固有のガイダンス：呼び出し元が提供した該当する拡張ファイル、またはランタイムに一覧表示された test-analysis-extensions カタログと、対応する言語ファイルを読みます。参照専用のヘルパーは呼び出し可能なスキルではありません。これらのファイルがない場合は、埋め込みの評価基準と固定されたフレームワーク API を使用します。重要なフレームワーク構造が未解決の場合は、推測したりインストールディレクトリを検索したりせず、Uncertain とします。

判定結果と品質情報を併記する理由

PR レビュー担当者が必要としているのは、「このテストに追加の対応が必要か」という簡潔な答えです。4 状態の結果がこの判定を示し、既存の A～F 評価基準が品質と重大度を説明します。

使用する場面

• PR 自動化ワークフローで、プルリクエスト内で追加または変更されたテストについて判定を投稿する必要がある場合。
• レビュー担当者が特定のテストリスト（ファイル、クラス、メソッドのリスト、または差分の一部）を持っており、スイート全体のレポートではなく、テストごとの追加対応の判定を求める場合。
• メンテナーが、投稿された N 件のテストのうち、どれに追加の改善が必要かを振り分け、判定済みのテストには品質評価を付けたい場合。

使用しない場面

• 呼び出し元がスイート全体の監査や比較指標を求めている場合は、test-anti-patterns（実践的）または test-smell-detection（形式的）を使用し、test-engineer エージェントに内部の品質スペシャリストを統括させてください。
• 呼び出し元が新しいテストの作成を求めている場合は、test-engineer（任意の言語）または writing-mstest-tests（MSTest 専用）を使用してください。
• 呼び出し元がコードカバレッジや CRAP スコアの測定を求めている場合は、coverage-analysis または crap-score（.NET 専用）を使用してください。
• 呼び出し元がテストコードの問題を直接修正したい場合は、適切な編集スキルを呼び出してください。
• 特定のテストリストが提供されていない場合。このワークスペース内のすべてのテストを評価しようとしてはいけません。呼び出し元に明示的なリストまたは対象範囲の提示を求めてください。

入力

入力	必須	説明
テストメソッド	はい	評価対象の範囲です。次のいずれかを指定してください。（a）テストメソッド名の明示的なリスト（完全修飾名。例：Namespace.ClassName.TestMethodName）。（b）1 つ以上のファイルパスに加え、それらのファイル内で宣言されたすべてのテストを評価するという明示的な指示。（c）変更されたテストを評価する diff ハンクまたは PR 識別子。ファイルパスの指定を推奨しますが、メソッド名がワークスペース内で明確に特定できる場合は省略可能です。*「テストを評価して」*のように範囲が指定されていない曖昧な依頼は、事前に拒否されます（ステップ 0 を参照）。このスキルは指定された入力を対象とするものであり、ワークスペース全体を自動的に評価するものではありません。
テスト本体／範囲	推奨	各テストメソッドのソース行を正確に指定します。省略された場合は、指定されたファイルから読み取ります。
プロダクションコード	いいえ	アサーションが主張された動作をカバーしているかを判断するための、テスト対象コードです。入手できない場合は、推測したり減点したりせず、ミューテーション評価を N/A／未検証とします。
言語リファレンス	いいえ	ホストから指定される、一致するバンドル済みの test-analysis-extensions ファイルへのパスです。リファレンス専用のローダーを呼び出すのではなく、ファイルを直接読み取ってください。未検証のフレームワークガイダンスで代用しないでください。
diff のコンテキスト	いいえ	PR の変更を評価する場合、各テストメソッドの統合 diff を指定すると、実際に変更された内容に焦点を当てやすくなります。

ステップ 0：入力を検証する

ほかの作業を始める前に、呼び出し元が次のいずれかを指定していることを確認してください。

1. テストメソッド名の明示的なリスト、または
2. 1 つ以上のファイルパスと、それらのファイルで宣言されたすべてのテストを評価するという明示的な指示（例：「OrderTests.cs 内のすべてのテストを評価する」）、または
3. 変更されたテストを評価する diff ハンクまたは PR 識別子。

依頼が曖昧な場合（例：「テストを評価して」、範囲の指定がない 「これらのテストは良いですか？」、「テストスイートをレビューして」）、拡張機能を読み込まず、ファイルも読まず、何も評価しないでください。呼び出し元に、明示的なリスト／ファイル／diff を指定するよう短く求めてください。また、必要に応じて、テストスイート全体の分析には test-engineer エージェントまたは test-anti-patterns スキルを案内してもかまいません。そこで終了してください。

有効かつ範囲が限定された依頼で、対象となるテストが 0 件の場合は、該当なしとし、簡潔に説明してください。架空の行を作成しないでください。

ワークフロー

ステップ 1：言語を検出して拡張機能を読み込む

指定されたリスト内のファイル拡張子とテストメソッドのマーカーから、対象コードベースの言語とテストフレームワークを特定してください。呼び出し元が指定した拡張機能ファイルを直接読み取ります。指定がない場合は、ランタイムに一覧表示された test-analysis-extensions カタログ内の extensions/ にある該当ファイル（dotnet.md、python.md、typescript.md、go.md など）を読み取ってください。 その他の言語にはカタログを使用し、スキルの呼び出しで代用しないでください。 入力に複数の言語のテストが含まれている場合は、該当する拡張機能をそれぞれ読み込み、各言語の規約に従って各テストを評価してください。

ステップ 2：テスト本体を特定する

入力の各項目について、次の手順を実行してください。

1. テスト本体がインラインで指定されている場合は、その内容を直接使用します。
2. それ以外の場合は、指定されたパスのファイルを読み取り、完全修飾名でメソッドを特定します。属性／デコレーター／フィクスチャ、およびテストが呼び出すヘルパーコードを含む、メソッド本体全体を取得してください。
3. 指定されたメソッドが見つからない場合は、品質評価を行わずに Uncertain — method not found と記録し、続行してください。評価対象の本体を作り上げてはいけません。指定されたメソッドが見つからない場合は人によるレビューが必要です。これは、有効な範囲の対象テストが 0 件の場合とは異なります。

構成チェックポイント： プロダクションコードのコンテキストが利用できる、解決済みのテストについては、ステップ 3 の前に per-test-read-only 評価コンテキストで test-gap-analysis を一度、バッチ単位で読み込んでください。ステップ 3 の前に、担当するリファレンス評価を完了してください。テスト本体に明白な弱点がすでに見えている場合でも、この読み込みを省略しないでください。独自に作り上げたミューテーションの説明は、構成要素の一部ではありません。

ステップ 3：主張されている動作を評価し、解決済みの各テストを採点する

採点は読み取り専用で行います。ビルドやテストの実行、ミューテーションの実行、ファイル編集、ツールのインストール、広範なスイートの探索、エージェントへの委任は行わないでください。提供されたテスト、その関連フィクスチャやヘルパー、およびテストの主張に必要な本番コードの呼び出しチェーンのみを解決します。

ステップ 2 のチェックポイントにあるインラインの test-gap-analysis 評価を使用してください。二度目に読み込まないでください。各テストの識別子と本体、関連するセットアップやヘルパー、主張されている動作、アサーションの意味、および利用可能なソースを提示してください。その構成上のディスパッチでは、スタンドアロンのベースライン／検証ワークフローではなく、所有する読み取り専用の参照が読み込まれます。テストごとの証拠を利用し、ここでミューテーションカタログを重複して作成したり、監査／生成エージェントを呼び出したりしないでください。 モードと入力は、ホストがサポートする呼び出し指示を使って評価コンテキストとして伝えてください。ローダーがスキル名のみを受け付ける場合は、test-gap-analysis を名前のみで読み込んでください。ツールの引数やモード固有のスキル名を作り出さないでください。

スキル／参照情報または本番コードのコンテキストを利用できない場合は、Pseudo-mutation: N/A / unverified — <reason> と記録し、通常のテスト本体の採点を続けてください。これは減点ではなく、それ自体で Uncertain の結果となるものでもありません。インストールディレクトリを検索したり、代わりにミューテーションランナーを使ったりしないでください。

各テストが主張する内容だけを評価してください。別のテストのアサーションを流用したり、無関係な分岐、出力、シナリオを求めたりしないでください。観測可能なサバイバーが、そのテストで主張された結果が検証されていないことを示す場合は、既存の Assertion 強度カテゴリーの根拠として使用できます。ミューテーションポイント、重み、上限、自動的なサバイバー減点を新たに導入しないでください。同じミューテーションの証拠に対して追加の減点を加えず、Assertion と Anti-pattern の両方の次元に分類される弱点も含め、既存のルーブリックを通常どおり適用してください。

すべてのテストを A（スコア帯 90～100） で開始し、記録されたテスト本体で観測可能な問題に限って厳密に減点してください。仮説上の懸念（たとえば、「否定アサーションを追加できた可能性がある」）については、本番コードが明確にそれを要求し、かつ本番コードを利用できる場合を除き、減点しないでください。

本番コードを利用できない場合も、テスト本体で観測可能な問題は通常どおり採点します。ただし、欠けている動作を推測したり、それを理由に減点したりしないでください。テスト本体の所見とソースコードが必要な主張とを読者が区別できるよう、サマリーに Production-dependent behavior coverage: Unverified を一度だけ記載してください。

3 つの下位次元

総合評価を決める 3 つの下位評価（それぞれ A～F）を算出します。

A. アサーションの強さ

読み込まれている言語拡張機能のアサーション API 一覧を確認し、テスト本体のすべてのアサーションを分類します。上から下に評価します。

サブグレード	パターン
A	構造的等価性、または相互に関連する冗長ではない観測可能な結果（戻り値に加え、必要な状態やインタラクションの検証など）を通じて、より豊かな契約を確かめます。または、以下の例外／エラー評価の例外条件に該当します。アサーションの数ではなく、述語の深さを評価します。モック呼び出しの検証と、言語の基本的なアサーションも通常どおり評価します。
B	テスト対象の動作を検証する、明確で意味のあるアサーションが 1 つあります。
C	些細なアサーション（単一の IsNotNull／toBeDefined／assert x is not None）のみ、またはテストで主張している結果のうち意味のある部分が未検証です。特定の単一フィールドについての主張では、無関係なフィールドを検証する必要はありません。
D	自己参照型／恒真のアサーション（Assert.AreEqual(x, x)、assert dto.name == dto.name、実質的な入力を伴わないラウンドトリップでの同一性）、または広範な例外アサーション（Assert.ThrowsException<Exception>）が 1 つあります。
F	アサーションがありません。すべてのアサーションが常に真となるリテラル（Assert.IsTrue(true)、assert True、expect(true).toBe(true)）であり、何も検証していないため、アサーションがないのと同じです。または、すべてのアサーションが暗黙のうちに未 await です（例：await／return のない expect(promise).resolves.toBe(x)、await されていない async TUnit／xUnit の Assert.ThrowsAsync、未 await のコルーチンを使う pytest-asyncio）。

例外テストとエラーパステスト（Assert.ThrowsException<T>、条件を指定した pytest.raises、expect(fn).toThrow、assertThrows、#[should_panic]、Should -Throw、EXPECT_THROW、または想定どおりの非 nil エラーを検証する Go コード）は、それだけで完結しています。テストの対象範囲について、明示されたエラー条件を正確に検証している場合、アサーションの強さは A とします。そのアサーションだけであることを減点せず、メッセージが文書化された契約の一部でない限り、エラーメッセージの検証も要求しません。意味のある戻り値を破棄し、err == nil だけを検証する Go の正常系テストは、成功結果を検証していないため、引き続き C です。

B. 構造と焦点

サブグレード	パターン
A	Arrange-Act-Assert（または Given-When-Then）が明確に分かれています。テスト対象の動作は 1 つです。本体はおよそ 30 行未満です。セットアップにはフレームワークの慣例に沿った方法を使っています。
B	構造上の軽微な問題が 1 つあります（本体がやや長い、フェーズ間に空行がないなど）が、意図は明確です。
C	1 つのテストに複数の動作が混在しているか、AAA のフェーズが十分に分かれておらず、理解に時間がかかります。
D	テスト内に条件分岐ロジック（アサーションを制御する if／switch）があります。ただし、慣用的な Go／Rust のテーブル駆動サブテストループは除きます。または、前のテストの状態に依存します（実行順序への依存）。
F	テストが約 60 行を超え、互いに無関係な複数の動作を検証しています。または、リセットせずに静的変数／グローバル変数を介して他のテストと可変状態を共有しています。

C. アンチパターンの対処

以下のカタログに照らして確認します。アンチパターンのサブグレードは、2 段階の評価を行い、決定論的に組み合わせて算出します。

1. 上限設定の評価。 Critical または High の該当事項があるたびに、サブグレードに上限（ラベルに応じて F、D、または C）を設定します。該当する Critical／High のうち、最も低い上限を採用します。これらは累積しません（F に上限設定する項目が 1 つあれば、他に Critical／High の項目がいくつあっても、サブグレードの上限は F です）。
2. Medium の減点評価。 A から開始し、該当する Medium の項目ごとにサブグレードを 1 段階下げます（A→B、B→C、C→D、D→F）。これらは累積します。

最終的なアンチパターンのサブグレードは、2 つの評価のうち悪い方（つまり、min(上限設定, A − Medium の件数)）です。Low の項目はグレードに影響しません。注記にのみ記載してください。

例（Critical／High と Medium の件数 → アンチパターンのサブグレード）：

• Critical／High がゼロ、Medium が 1 件 → B（A − 1）
• Critical／High がゼロ、Medium が 3 件 → D（A − 3）
• C 上限が 1 件（例：過剰なモック化）、Medium が 0 件 → C
• C 上限が 1 件、Medium が 2 件 → C（min(C, A − 2 = C) = C。Medium が 3 件になると D）
• F 判定が 1 件（例：例外の握りつぶし）と、任意の数の Medium → F

Critical（F または D に直行）

• アサーションが一切ない → F（Assertion サブグレードも F）
• 例外の握りつぶし：.NET の try { … } catch { }、Python の裸の except: pass、 JS／TS／Java の try { … } catch (e) {}、再 panic なしの Go の defer recover()、 アサーションなしの Ruby の rescue StandardError、Kotlin／Swift の空の catch → F
• assert-in-catch パターン（Assert.ThrowsException の代わりに Assert.Fail(ex.Message) を使用）→ D
• 常に true となるリテラルのアサーション（Assert.IsTrue(true)、assert True、 expect(true).toBe(true)）→ F（何も検証していません。Assertion サブグレードも F）
• バインドされた値に対する自己参照／トートロジーのアサーション （Assert.AreEqual(x, x)、assert dto.name == dto.name）→ D
• コメントアウトされたアサーション → D

High（サブグレードを 1 つまたは 2 つ下げる）

• 同期に実時間のスリープを使用：Thread.Sleep、Task.Delay、time.sleep、 setTimeout ベースの待機、Thread.sleep、time.Sleep、sleep、std::thread::sleep、 Start-Sleep、std::this_thread::sleep_for（ユニットテスト内）→ D
• シードされていない乱数、抽象化なしでの実時間の読み取り （DateTime.Now、datetime.now()、Date.now()、 System.currentTimeMillis()、time.Now()、Time.now、 Instant::now()、Get-Date、system_clock::now）→ D
• 環境に依存するパスのハードコード（C:\…、/tmp/…、ネットワークホスト）→ D
• 変更可能な静的変数／パッケージグローバル変数への順序依存 → D
• 広範すぎる例外アサーション（Assert.ThrowsException<Exception>、 pytest.raises(Exception)、マッチャーなしの expect(fn).toThrow(Error)、 expected = "…" の指定がない #[should_panic]、-ExpectedMessage の指定がない Should -Throw、EXPECT_ANY_THROW）→ C
• 過剰なモック化：テストロジックよりもモックの設定行が多い、または結果ではなく呼び出し順を厳密に検証している → C
• 実装への結合：プライベートメンバーのリフレクション、状態にアクセスするための内部型へのキャスト → C

Medium（サブグレードを 1 つ下げる）

• 不適切な名前：Test1、TestMethod、test、シナリオや期待される結果がわからない単語 1 つだけの名前（言語拡張の慣例に照らして判断）→ サブグレードを 1 つ下げる
• マジック値：名前やコメントで説明されていない 42、"foo"、0x1234 を arrange／assert で使用 → サブグレードを 1 つ下げる
• 巨大なテスト（1 つの振る舞いを対象とする 30 行超のテスト）→ サブグレードを 1 つ下げる
• アサーションのテキストをそのまま繰り返すだけのアサーションメッセージ → サブグレードを 1 つ下げる
• テストが複雑なのに AAA／GWT の区分がない → サブグレードを 1 つ下げる

Low（記録のみ、減点なし）

• 未使用のセットアップ／ティアダウンフック、残されたデバッグ用の print（Console.WriteLine、 print、console.log、System.out.println、fmt.Println、puts、 dbg!、Write-Host、std::cout）、同じ種類のテストとの命名の不統一、 残された TODO コメント。注記欄に記載しますが、減点しません。

サブグレードの統合

サブグレードを数値に変換します：A=4、B=3、C=2、D=1、F=0。

• 総合スコア帯 = 加重平均： 0.45 × Assertion + 0.30 × Anti-pattern + 0.25 × Structure
• 文字評価に対応付けます：
  • ≥ 3.5 → A（スコア帯 90–100）
  • ≥ 2.8 → B（スコア帯 80–89）
  • ≥ 2.0 → C（スコア帯 70–79）
  • ≥ 1.2 → D（スコア帯 60–69）
  • < 1.2 → F（スコア帯 0–59）
• 総合評価は最も低いサブグレードを上限とします。いずれかのサブグレードが F の場合、総合評価は F です。最も低いサブグレードが D の場合、総合評価は D 以下となり、以下も同様です。いずれか1つの観点で不合格となるテストは、その観点より高い総合評価を得られません。

加重平均による評価を適用してから上限を適用してください。加重評価の代わりに上限を適用するのではありません。たとえば、Assertion B、Anti-pattern A、Structure A の場合、値は 3.55 です。加重平均による仮評価は A ですが、最終評価は B（80-89） です。そのため、焦点を絞ったスカラー値の等価性テストは、改善可能な指摘がなくても B / Pass になり得ます。この評価を正当化するために、弱点や不足している関連動作を作り上げないでください。

文字評価とスコア帯を報告してください（0～100の単一の数値ではありません）。過度に細かい精度は不毛な議論を招きます。スコア帯を使うことで、議論を評価基準に沿ったものにできます。

Step 4：判定結果を割り当てる

評価はテストの強さを要約し、結果は追加対応が必要かどうかを示します。改善可能な指摘とは、テスト、セットアップ、またはフィクスチャに対する、証拠に裏付けられた変更です。次のうち1つだけを割り当ててください。

• Pass — 改善可能な指摘がありません。肯定的な注記や文脈を示す注記は記載できます。
• Failed — 評価にかかわらず、改善可能な指摘が少なくとも1つあります。
• Uncertain — 証拠が不足して判断できず、人によるレビューが必要です。
• Not applicable — 有効な対象範囲に該当するテストがありません。通常は行がない場合の総合結果です。

評価からステータスを導き出さないでください。焦点を絞った完全なテストは B / Pass になり得ます。一方、デバッグ出力があれば、ほかの点では優れたテストでも A / Failed になり得ます。解決されていない本文、未対応の構文、または必須のコントラクトが不足している場合は Uncertain を使用してください。プロダクションコードがないだけの場合には使用しません。明確な指摘がある場合は、不確実性よりもそちらを優先します。

Step 5：注記を作成する

最も重要な理由を1文で記載します（目標は120文字以内）。 問題は見つかりませんでした。、IsNotNull のみを確認しており、レシートの内容は検証されていません。、または メソッド本体を解決できませんでした。人によるレビューが必要です。 などです。評価や Failed の結果を正当化するために、弱点を作り上げないでください。

アクションは改善方法フィールドに分けて記載してください。Failed の各テストについて、最小限で有効な入力、アサーション、またはフィクスチャの変更と、その期待される結果を、本体、ソース、または明示的なコントラクトに基づいて記載します。たとえば、Improve assertions ではなく Replace self-comparison with Assert.AreEqual(60m, account.Balance).、Clean up ではなく Remove Console.WriteLine after Deposit(25m). とします。影響が最も大きい指摘を優先し、異なる変更が必要な場合に限って、ほかの改善可能な指摘も含めてください。

動作上の不足を指摘する場合は、共有済みの評価にある、差を明確にする入力例とオリジナル／変異版での観察結果を使用してください。期待される結果が未変更のソースと一致することを確認してください。必須の文脈が不足している場合は、期待値を作り上げるのではなく、必要な証拠を明記してください。Pass は None、Uncertain は推測に基づくテストの書き換えではなく、証拠を解決するための具体的な手順を記載します。評価基準だけに基づく減点は、動作上の不足や改善可能な指摘の証拠にはなりません。焦点を絞った B / Pass では変更が不要な場合があります。A / Failed でも、デバッグ出力を削除するなど、具体的なアクションが必要です。

Step 6：報告する

2つのセクションを作成します。

1. Summary

**Result: <Pass|Failed|Uncertain|Not applicable>** で始め、その後に結果の件数と最優先のアクションを記載します。集計の優先順位は Failed → Uncertain → Pass → Not applicable とします。Not applicable の場合は、対象範囲が空であることを説明し、表は省略します。

2. テストごとの表

| Test | Result | Quality | Notes | How to improve |
|------|--------|---------|-------|----------------|
| `Namespace.ClassName.Test_Method_Condition_Expected` | Pass | B (80–89) | One complete value assertion. | None |
| `Namespace.ClassName.Withdraw_SufficientFunds` | Failed | D (60–69) | Balance is compared with itself. | Replace self-comparison with `Assert.AreEqual(60m, account.Balance)` after withdrawing 40m from 100m. |
| `Namespace.ClassName.Test_Missing` | Uncertain | — | Method body could not be resolved; human review is required. | Supply the method body and its referenced fixture. |

これら 2 つのレポートセクションと、元の Test/Result/Quality/Notes フィールドを維持してください。ミューテーションの証拠が所見を説明している場合、または呼び出し元が詳細を求めている場合は、テストごとのセクション内に簡潔なテストごとの Pseudo-mutation evidence ブロックを追加してください。内容は、変更、witness、original/mutant の観測、関連するアサーション、および分類です。静的な結果は Likely killed (inferred) または Candidate survivor (unverified) であり、実行された Killed/Survived や実証的な killed/total のカウントには決してなりません。コンテキスト欠如による N/A / unverified は、共有された制限ごとに 1 回だけ記載してください。改善表を散文で繰り返さないでください。

上限と順序:

• 表が 50 行 を超える場合は、Failed テストを最初に、次に Uncertain テスト、その後に Pass テストのサンプルを表示してください。あふれた分は折りたたみの <details> ブロックで包んでください。
• 同じ結果内では、品質の悪い順から良い順に並べ、次に決定性のためにファイルパスとメソッド名で並べてください。
• diff コンテキストが提供されている場合は、各テスト名の前に (new) または (modified) のマーカーを付けてください。

複数の言語が存在する場合は、言語ごとに 1 つの表を作成し、各セクションの前に言語名とフレームワークを付けてください。

検証

• 入力リスト内のすべてのテストが表に現れている（または Uncertain — method not found として記録されている）。
• 解決されたすべてのテストに Pass または Failed と、A-F の品質詳細がある。
• Uncertain は証拠の欠落である。Not applicable は有効な空のスコープである。
• すべてのグレードが、取得された本体における少なくとも 1 つの観測可能なシグナルによって正当化されている — 推測による deduction はない。
• すべての Failed 行に、具体的で証拠に裏付けられた How to improve アクションがある。Pass 行には、品質グレードが B であっても、でっち上げられた弱点がない。
• ミューテーション評価は読み取り専用かつテストごとに留まった。利用できないコンテキストは減点されず、equivalent は除外され、静的なラベル/カウントは実行された証拠として提示されなかった。
• 検証済みの観測可能な所見は、重複した deduction やスコアリングの重みおよび上限の変更なしに、既存のカテゴリに反映されている。
• 些細なアサーションのテストは、唯一のアサーションが些細である場合にのみフラグが立てられる（意味のあるアサーションの前の null チェックは些細ではない）。
• 例外のみのテストは、アサーション数が少ないことを理由に減点されない。
• モック呼び出しの検証および裸のアサーション形式は、適切なカテゴリの実際のアサーションとして数えられる。
• 意味のあるプロパティに対する真偽値アサーション（Assert.IsTrue(result.IsValid)）は always-true として分類されない。リテラルの true/false 定数のみが対象である。
• 自己参照的なアサーションは、通常の等価性アサーションとは別にフラグが立てられる。
• 慣用的なパターンにはフラグが立てられない: Go/Rust のテーブル駆動サブテスト、pytest の裸の assert、Go の if got != want { t.Errorf(...) }、JS/TS の expect(mock).toHaveBeenCalledWith(...)。
• 非同期テストの落とし穴（await されていない resolves/rejects/ThrowsAsync、await のない pytest-asyncio）は、Assertion サブグレードを F に下げる。
• サマリーは、表の要約ではなく、最も効果の高い所見から始まる。

よくある落とし穴

落とし穴	解決策
リストが指定されていないのに、ワークスペース内のすべてのテストを評価する	呼び出し元に明示的なリストを求めます。このスキルは厳選された入力を対象としています。
評価を正当化するために減点を水増しする	Aから始め、観察可能な問題に限って減点します。
アサーション数が少ないことを理由に、例外テストを減点する	例外に対するアサーションは、それだけで完結しています。
err != nil のみを確認する Go のエラーパステストを、対象が絞られているのに格下げする	期待するエラーが存在することは、その範囲で観察可能な契約です。本番コードの契約で特定のエラー識別子やメッセージが必要とされていない限り、Aのままにします。
値のアサーションより前にある IsNotNull を些細なものとして扱う	nullチェックが唯一のアサーションである場合に限り、問題として指摘します。
あらゆる Boolean アサーションを、実質的にアサーションがないものとして扱う	常に true となるリテラル（Assert.IsTrue(true)、assert True）だけが該当します。意味のある Assert.IsTrue(result.IsValid) は実際のアサーションです。
Go/Rust のテーブル駆動ループを条件分岐ロジックとして指摘する	これは慣用的な書き方です。減点しないでください。
pytest の裸の assert や Go の if got != want { t.Error… } を、テストフレームワークを使っていないものとして扱う	どちらも標準的な書き方です。適切なアサーションカテゴリに含めてください。
本番コードを確認できないことを理由にテストを減点する	カバーされていない動作に関する懸念には Unverified と記し、減点しないでください。
見せかけの精密なスコア（例：87/100）を使う	スコア帯のみを使ってください。90–100、80–89、70–79、60–69、0–59です。
500行の表を PR コメントにそのまま載せる	ステップ6の行数上限を適用し、超過分は <details> にまとめてください。
既存の指摘を、異なるカテゴリで3回報告する	最も適切なカテゴリを選び、1回だけ報告してください。
別のテストのアサーションを、弱いテストの評価に加味する	現在のテストと、そのテストが実行するヘルパー／フィクスチャのみを使ってください。
疑似的なミューテーションの組み合わせを、スイート全体の監査に広げる	テストごとの読み取り専用モードを明示的に指定してください。実行、編集、広範な検索、エージェントの再帰呼び出しは禁止です。
注記の「バランス」を取るために、A評価のテストに欠点をでっち上げる	問題のないテストであれば、注記は No issues found. のみでもかまいません。
評価やコメントからステータスを割り当てる	実行可能な改善点がある場合にのみ Fail とします。Bでも Pass になり、Aでも Fail になり得ます。
Uncertain と Not applicable を混同する	証拠の不足は Uncertain、有効な空の対象範囲は Not applicable です。