メニュー
LLM/生成モデルが関わるテストを2局面(テストを書く道具としてのAI活用、製品に組み込まれた非決定的出力そのものの検証)で扱う。 test-catalog の手法カタログの一部。AI/LLM 支援テスト生成(観点出し、偽陽性/偽陰性対策)、 非決定的出力システムのテスト(階層化品質設計、入口/中央/出口層、スキーマ強制、メタモルフィック、複数サンプリング合意) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。
テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。
Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.
test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
| name | ai-nondeterministic |
| description | LLM/生成モデルが関わるテストを2局面(テストを書く道具としてのAI活用、製品に組み込まれた非決定的出力そのものの検証)で扱う。 test-catalog の手法カタログの一部。AI/LLM 支援テスト生成(観点出し、偽陽性/偽陰性対策)、 非決定的出力システムのテスト(階層化品質設計、入口/中央/出口層、スキーマ強制、メタモルフィック、複数サンプリング合意) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
LLM や生成モデルが関わるテストを2つの局面で扱う。
ひとつはテストを書く道具として LLM を使う局面、もうひとつは製品に組み込まれた非決定的出力そのものを検証する局面である。
性質ベースの自動生成テスト(PBT、差分、メタモルフィック等)は generative-property.md を参照する。
LLM にコードを渡してテストケースやアサーションを生成させる。 ケースの叩き台や見落とした観点の洗い出しには速いが、生成物の正しさは保証されない。
テストの初稿、命名、定型的な it.each の量産、観点のブレインストーミングに使う。 但し書き(必須): LLM が生成したアサーションは、実装の現在の挙動をそのまま「正解」と思い込んで固定しがちで、バグごと緑にする。生成テストは必ず人がレビューし、期待値の根拠を仕様に照らして確認する。 oracle を LLM に委ねてはならない。 正しさを数学的かつ網羅的に保証したい critical な箇所には使わず、PBT、差分、形式検証連携を使う。
この作業の本体は「LLM に観点を出させ、人が偽陽性/偽陰性を除き、残った観点を台帳の T-ID に落としてテスト化する」ことだ。LLM は観点の母集団を出す係で、採否の oracle ではない。次の順で進める。
../test-extract/assets/test-extract-template.md)の行にし、各々へ T-ID を採番する。観点と T-ID は1対1にする(1観点に複数 T-ID が要るなら観点が粗い、逆なら重複)。generative-property.md)、具体例だけ手書きに残す。テストの抜けレビューや、仕様とテストケースの整合チェックを AI に「指摘させる」と、見落とし(偽陰性)は少ない代わりに偽陽性が多い。 偽陽性を放置すると指摘が信用されず、レビュー自体が無視される(狼少年化)。 偽陰性を保ったまま偽陽性を絞る3手を、強い順に効かせる。
severity を強制)、閾値以上だけ採る。低深刻度に偏る偽陽性をまとめて落とせる。loop-engineering(TLA+)や formal-verification(Lean)へ渡す。いずれも最終判定は人または決定論的検証器に置く。AI は指摘の母集団を出す係で、採否の oracle にはしない(上の但し書きと同じ原則)。
LLM や生成モデルなど、同じ入力でも出力が毎回揺れる(非決定的な)部品を組み込んだシステムをテストする設計。 前項「AI/LLM 支援テスト生成」がテストを書く道具としての LLM の話なのに対し、こちらは製品に組み込まれた LLM 出力そのものを検証する。 揺らぎは AI の価値(探索や多様性)なので消さない。 代わりに、揺らぎを許す層と保証を固定する層を分け、層ごとに何を保証するか(保証の所在)を明示する。 これが階層化品質設計で、揺らぎを一つの層に閉じ込め、その外側を決定論的に固める。
出力が確率的で、toBe の固定値アサートが原理的に書けない部品をプロダクトに載せるときに使う。
チャット応答、要約、分類、コード生成、検索ランキングなど。
出力が決定論的なら本項は過剰で、通常の出力ベーステストで足りる(YAGNI)。
揺らぎを中央の層に閉じ込め、その入口と出口を決定論的に固める三層で考える。
generative-property.md を流用)。三層は「揺らぎをどこに閉じ込め、どこを固定するか」の線引きそのものだ。層ごとに何ケース作れば完了かを決めながら進める。
toBe の固定値で締める。grep で LLM-as-judge の呼び出しが最終判定に使われていないか逆引きする。../test-extract/assets/test-extract-template.md の用語定義表の隣)に明示し、「揺らぎを許す層」と「固定する層」の境界を曖昧にしない。境界が曖昧な設計は、揺らぎが保証側へ漏れる。