skill-coverage-audit

ホスト：Codex CLI — このスキルはClaude Code向けに設計され、Codex用に調整されています。 相互参照コマンドでは、/octo:* スラッシュコマンドではなく、Codexにインストールされたスキル名を使用します。 現在のセッションで利用可能であることが確認できるまでは、アクティブなCodexシェルとサブエージェントツールを使用してください。プロバイダー、モデル、ホストのサブエージェントが利用可能だと断言しないでください。 ホストツールの同等機能については、skills/blocks/codex-host-adapter.mdを参照してください。

テストカバレッジ監査

実装前の成果物の整合性

仕様／計画／タスクの境界で呼び出された場合は、このスキルのコードテスト生成モードではなく、機能境界アダプターを使用してください。これにより、カバレッジ、宣言されたパス、安定したID、明示的な用語／列挙値／件数、検証済みのポリシー参照について、範囲を限定した決定論的チェックが自動的に実行されます。成果物が1つだけの場合は分析を省略し、チェックに問題がなければシートを消費しません。レポートは助言的なもので、元のソースを引用します。エスカレーションで使用する独立したシートは最大1つです。また、セマンティックレビューが利用できない、または失敗した場合でも、決定論的な結果はそのまま利用できます。

概要

差分に含まれるすべてのコードパスをたどり、既存のテストと対応付けてカバレッジのギャップを可視化し、未カバーのパス向けにテストを自動生成します。

基本原則： 変更されたファイル内のコードパスを追跡する -> 既存のテストと対応付ける -> カバレッジの品質を評価する -> ギャップを埋めるテストを生成する -> 変更前後の件数を報告する。

上限と制限

分析が際限なく広がらないよう、次の上限を設けています。

• 監査ごとにコードパスは最大30個です。差分に30個を超えるコードパスが含まれる場合は、複雑さとリスクに基づいて優先順位を付けてください（エラーパス、セキュリティ上重要な分岐、公開APIの境界を優先）。
• 監査ごとに生成するテストは最大20件です。影響の大きいギャップを優先してください。
• テストごとの調査上限は2分間です。1つのテストパスの理解に2分を超える場合は、「手動レビューが必要」として、次に進んでください。

フェーズ1：コードパスの追跡

ステップ1：変更されたファイルを特定する

差分の範囲を特定します。最も関連性の高いソースを使用してください。

# PR diff
git diff --name-only main...HEAD

# Staged changes
git diff --name-only --cached

# Last commit
git diff --name-only HEAD~1..HEAD

ソースコードファイルだけに絞ります（設定ファイル、ドキュメント、生成ファイルは除外します）。

ステップ2：すべての分岐を通じてデータフローを追跡する

変更された各ファイルについて、必ず次の項目を追跡してください。

1. 条件分岐 -- すべてのif/else、switch/case、三項演算子、パターンマッチを確認します。それぞれの分岐が個別のコードパスです。
2. エラーパス -- すべてのcatch、throw、エラーを返す箇所、検証の失敗、エラーを伴う早期リターンを確認します。理由：エラーパスは、テストされていないバグが最も多く発生する箇所です。
3. 関数呼び出し -- 変更されたコードから呼び出されるすべての関数を確認します。呼び出し先を1階層まで追跡し、統合境界を特定します。
4. ループの境界条件 -- ループにおける空のコレクション、要素が1つの場合、複数の要素がある場合の各パスを確認します。
5. ガード節 -- すべての早期リターン、nullチェック、権限チェックを確認します。

ステップ3：コードパスの一覧を作成する

構造化された一覧を作成します。

## Codepath Inventory: [filename]

| # | Path Description | Type | Risk |
|---|-----------------|------|------|
| 1 | validateUser() happy path | conditional | low |
| 2 | validateUser() missing email | error | medium |
| 3 | validateUser() invalid format | error | medium |
| 4 | processOrder() empty cart guard | guard | high |
| 5 | processOrder() payment timeout | error | high |
| 6 | processOrder() success | conditional | low |

種類のカテゴリ： conditional、error、guard、loop-boundary、integration、async

リスク評価： high = ユーザーに影響する障害またはデータ損失、medium = 動作の低下、low = 見た目またはログ上の問題

フェーズ2：テストとの対応付けと品質評価

ステップ1：既存のテストを検索する

差分内の各ファイルについて、テストディレクトリから関連するテストを検索します。

# Find test files that reference the changed file or its exports
# Search by filename pattern
find tests/ -name "*[changed_file_stem]*" -type f

# Search by import/require of the changed module
grep -rl "import.*from.*[module_name]" tests/
grep -rl "require.*[module_name]" tests/

# Search by function name references
grep -rl "[function_name]" tests/

ステップ2：テストの品質を評価する

各コードパスについて、次の基準に従って既存のテストカバレッジを評価します。

評価	意味	基準
★★★	動作とエッジケースをテスト済み	テストで動作を検証し、境界条件、エラーケース、境界値の入力もカバーしている
★★	正常系をテスト済み	テストで成功パスをカバーしているが、エラー分岐やエッジケースは対象外
★	スモークテストのみ	テストは存在するが、関数がエラーなく実行されることを確認するだけで、有意なアサーションがない
☆	テストが見つからない	このコードパスを参照するテストがない

ステップ3：カバレッジマップを作成する

各コードパスをテストカバレッジと対応付けます。

## Coverage Map: [filename]

| # | Codepath | Test File | Rating | Notes |
|---|----------|-----------|--------|-------|
| 1 | validateUser() happy path | test-user.sh:42 | ★★★ | Asserts valid + invalid inputs |
| 2 | validateUser() missing email | test-user.sh:58 | ★★ | Tests missing, not malformed |
| 3 | validateUser() invalid format | -- | ☆ | No test for format validation |
| 4 | processOrder() empty cart guard | -- | ☆ | Guard clause untested |
| 5 | processOrder() payment timeout | test-orders.sh:30 | ★ | Checks no crash, no assertions |
| 6 | processOrder() success | test-orders.sh:15 | ★★★ | Full integration test |

フェーズ 3：カバレッジ図

マップの作成後、ASCII 形式のカバレッジサマリーを作成します。これが主な成果物です。

COVERAGE: 5/12 paths tested (42%)
  Code paths: 3/5 (60%)
  User flows: 2/7 (29%)
GAPS: 7 paths need tests

カテゴリ別に分類します。

BY TYPE:
  conditional:  3/4 tested (75%)  ████████░░
  error:        1/5 tested (20%)  ██░░░░░░░░
  guard:        0/2 tested  (0%)  ░░░░░░░░░░
  integration:  1/1 tested (100%) ██████████

BY RISK:
  high:    1/3 tested (33%)  ███░░░░░░░
  medium:  2/5 tested (40%)  ████░░░░░░
  low:     2/4 tested (50%)  █████░░░░░

カバー済みには全ブロック、未カバーには薄い網掛けを使用します。バーは 10 文字にします。正確な分数と割合を必ず表示します。

フェーズ 4：テストの自動生成

ステップ 1：プロジェクトのテスト規約を検出する

テストを生成する前に、プロジェクトのテストパターンを必ず検出します。

**Detected Test Conventions:**
- Framework: [jest/vitest/pytest/bash/go test/etc.]
- Location: [tests/ | __tests__/ | src/**/*.test.* | etc.]
- Naming: [test-*.sh | *.test.ts | *_test.go | etc.]
- Style: [BDD describe/it | xUnit | TAP | custom]
- Helpers: [test-utils.ts | conftest.py | helpers/ | etc.]
- Assertion library: [built-in | chai | assert | etc.]

ステップ 2：未カバーのパス向けにテストを生成する

テストなし、およびスモークテストのみの各コードパスに対して、次の条件を満たすテストを生成します。

1. プロジェクトの命名規約に従う -- 同じディレクトリ構造とファイル命名パターンにします
2. 既存のテストヘルパーを使用する -- プロジェクトで使用されているものと同じテストユーティリティからインポートします
3. 実装ではなく動作をテストする -- 内部状態ではなく、観測可能な結果を検証します
4. 特定のギャップをカバーする -- フェーズ 1 で特定した分岐またはエラーパスを対象にします
5. エッジケースを含める -- 生成する各テストで完全なカバレッジを目指します

ステップ 3：生成したテストを提示する

生成したテストごとに、次を示します。

### Generated: test for [codepath description]
**Covers:** Codepath #N from [filename]
**Raises coverage:** from no-test to full coverage

[test code block]

ステップ 4：変更前と変更後を報告する

すべてのテストを生成した後、カバレッジの変化を示します。

BEFORE: 5/12 paths tested (42%)
AFTER:  11/12 paths tested (92%)
  New tests generated: 6
  Remaining gaps: 1 (manual review needed)

他のスキルとの連携

flow-deliver / skill-code-review との連携

カバレッジ監査は、コードレビューを補完します。デリバリーフェーズで実行する場合：

1. コードレビューで品質と正確性を評価します
2. カバレッジ監査でテストの網羅性を評価します
3. 両方の結果をリリース可否の判断に反映します

skill-tdd との連携

カバレッジ監査で新しいコードにギャップが見つかった場合は、次のイテレーションで TDD を採用するようユーザーに提案します。カバレッジ監査は既存のギャップを修正し、TDD は今後のギャップを防ぎます。

skill-verification-gate との連携

テストの生成後、skill-verification-gate を使用してテストスイートを実行し、新しいテストがパスすることを確認します。

注意事項 -- 次のことはしないでください

操作	問題である理由
パスではなく行数を数える	行カバレッジでは分岐カバレッジをまったく捉えられません
規約を確認せずにテストを生成する	プロジェクトのスタイルに合わないテストは受け入れられません
実装の詳細をテストする	リファクタリングで壊れる、もろいテストになります
エラーパスを省略する	多くのバグはエラーパスに潜んでいます
30 パスの上限を超える	分析の焦点がぼやけ、時間がかかります
20 件を超えるテストを生成する	効果が薄れていきます。影響の大きいものに集中してください
1 つのパスに 2 分以上かける	手動レビューが必要と記録し、次に進みます

クイックリファレンス

1. TRACE   -> Identify all codepaths in the diff (max 30)
2. MAP     -> Find existing tests for each path
3. SCORE   -> Rate coverage quality (no-test / smoke / happy-path / full)
4. DIAGRAM -> ASCII coverage visualization
5. GENERATE -> Auto-create tests for gaps (max 20)
6. REPORT  -> Before/after test counts