メニュー
テスト実行時の絞り込み運用ルール。プロジェクト全体テストではなく修正範囲に絞ったテスト実行を行う。 `gradlew test`/`pytest`/`jest`/`go test`等のテストランナーを実行するとき、テスト実行コマンドを 組み立てるときに必ず参照する。コミット差分や修正ファイルから対象テストを特定する手順を含む。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | test-targeted |
| description | テスト実行時の絞り込み運用ルール。プロジェクト全体テストではなく修正範囲に絞ったテスト実行を行う。 `gradlew test`/`pytest`/`jest`/`go test`等のテストランナーを実行するとき、テスト実行コマンドを 組み立てるときに必ず参照する。コミット差分や修正ファイルから対象テストを特定する手順を含む。 |
特別な指示がない限り、プロジェクト全体テストの一括実行は行わない。直前の作業内容・最新コミット差分・修正ファイルのパスから影響範囲を特定し、対象テストクラスのみに絞って実行する。
git log / git diff で修正対象のクラス／パッケージを特定する--tests "*ClassNameTest" または --tests "FQCN"pytest path/to/test_file.py::TestClass::test_func または -k "expr"jest path/to/file.test.ts または -t "test name pattern"go test ./pkg/... -run TestNamecargo test --test integration_test test_name以下の場合のみ全範囲テストを実行する：
計画書に「全体テスト」と明示されていても、ユーザーから直接の指示がなければ対象テストに絞る。
実行コマンドと生出力（終了コード・緑赤の集計行）を応答に提示して完了とする。貼れないなら未完。
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 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 スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。