agentsclimarketplace
Sign in

Test scope definition

Skill thinkyou0714/claude-lab-skills/lab-implementation-flow/skills/test-scope-definition

実装・変更に対して何をどこまでテストすべきかを定義する。テスト種別・対象・優先度・合否基準を整理し、テスト不足による手戻りを防ぐ。テスト計画を立てるときに使う。From its SKILL.md

Install
npx -y skills add thinkyou0714/claude-lab-skills --skill test-scope-definition

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.1 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it

Purpose

「テストを書いたが重要な箇所が抜けていた」「テストが多すぎて保守できない」を防ぐ。 変更の種別とリスクに応じて、最小限かつ十分なテストスコープを定義する。

Use When

  • 実装・変更の前後にテスト方針を決めたい場合
  • レビュー前にテストカバレッジを確認したい場合
  • テストを書く優先度をつけたい場合
  • 施工AIへのタスク委譲時にテスト要件を明示したい場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

  • 変更内容: テスト対象となる実装・変更の説明
  • 変更種別: 新機能追加 / バグ修正 / リファクタリング / DB マイグレーション / API 変更
  • 影響範囲: 変更が波及する機能・API・DB テーブル
  • 既存テスト: 現在のテストファイル・テスト種別・カバレッジ概要
  • テストツール: 使用するテストフレームワーク・ツール

Output Contract

以下の順で出力すること。順序を変えない。

  1. 論点: このテストスコープを左右する核心的な判断軸
  2. 根拠: その論点をそう判断した理由
  3. テストスコープ定義: 種別・対象・優先度・合否基準の一覧
  4. 含意: このスコープの網羅度と残存リスクの意味
  5. 改善案: テストコストを下げつつカバレッジを上げる工夫
  6. 代替案: フルテストが困難な場合のリスクベース優先付け
  7. 判断材料: 「このスコープで進む / スコープを縮小する / スコープを拡大する」を選ぶための情報

テストスコープ定義 フォーマット

テスト種別対象優先度合否基準
ユニットテスト（関数・モジュール名）必須 / 推奨 / 任意（どういう状態をパスとするか）
統合テスト（エンドポイント・フロー名）必須 / 推奨 / 任意
E2E テスト（ユーザーシナリオ名）必須 / 推奨 / 任意
手動確認（確認手順名）必須 / 推奨 / 任意
パフォーマンステスト（対象処理名）必須 / 推奨 / 任意

テスト種別は実際に使用するもののみ記載すること。

Review Lens

  • 目的妥当性: テストスコープが変更リスクに対して適切か
  • 範囲の過不足: 重要なユーザーシナリオが抜けていないか / 過剰テストになっていないか
  • 中長期リスク: テストが増えすぎて保守コストが上がらないか
  • LAB全体との整合性: 既存テスト構成（Vitest / Playwright 等）と整合しているか
  • 非エンジニア理解可能性: 合否基準が非技術者に説明できるか
  • 他LLM移植耐性: テスト種別の定義が Claude 固有の解釈に依存していないか

Instructions

  1. 変更種別に応じてテスト戦略の重点を変える（新機能→正常系、バグ修正→再現ケース、リファクタ→既存動作保証）
  2. 変更の影響範囲を元にテスト対象を列挙する
  3. 各テスト対象に優先度（必須 / 推奨 / 任意）を付ける
  4. 「必須」のテストが全通過しない場合はマージ・デプロイ不可とする基準を明示する
  5. E2E は重要なユーザーシナリオに絞る（網羅的 E2E は保守コストが高い）
  6. 手動確認が必要な場合はチェックリスト形式で手順を提示する
  7. 最終スコープ判断は人間に委ねる

Guardrails

  • 「テストがないが影響軽微だから任意」で必須テストを任意に格下げしない
  • カバレッジ数値を目的にしない。重要な動作の保証を目的にする
  • バグ修正には必ず再現テストを「必須」に含める
  • DB マイグレーション変更にはロールバック後の状態確認テストを含める
  • 外部 API 呼び出しはモックと実 API テストを分けて明示する

LAB Cross-Check

観点状態備考
自動化フロー—Webhook / n8n フローのテストが含まれているか
データ / 認証 / ログ—認証・RLS・ログ出力のテストが含まれているか
実装 / 運用フロー—CI での自動実行が可能なスコープか
非エンジニア理解可能性—合否基準を説明できる言葉か
会員共有 / 再利用耐性—テストスコープ定義の形式が他変更にも転用できるか
他LLM移植耐性—評価基準が Claude 固有に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

  • 要件: テストスコープの定義（種別・対象・優先度・合否基準）
  • 成功条件: 必須テストが全通過し、手動確認チェックリストが完了した状態
  • 失敗条件: 必須テストが1件でも失敗している状態
  • 実行範囲: テストを書く / 実行するファイル・ディレクトリ
  • 影響範囲: テスト追加によって変更が必要な設定ファイル・CI 定義
  • ロールバック方針: テスト追加後に CI が壊れた場合の切り戻し
  • コスト比較: テスト実装コスト vs テストなしで問題発覚した場合のコスト

Further Reading

  • implementation-gate skill — テストスコープ確認を含む実装着手前チェック
  • change-impact-scan skill — テスト対象の影響範囲洗い出し
  • patch-readiness skill — パッチ適用前のテスト準備確認
  • docs/CONTEXT.md — 技術スタック・テストツール

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.