메뉴
テストの粒度選択のうち、システム全体を外から見る運用確認の層(スモークテスト、 サニティテスト、回帰テスト)を扱う。 test-catalog の手法カタログの一部。デプロイ直後の致命傷即検知、小さな修正後の 変更箇所の狭い確認、過去バグの再発防止と継続的な退行防止を検証したい、または 割り当てたいときに使う。通常は test-catalog スキルの索引経由で手法が選定された 後にこのスキルを直接参照する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | levels-operational |
| description | テストの粒度選択のうち、システム全体を外から見る運用確認の層(スモークテスト、 サニティテスト、回帰テスト)を扱う。 test-catalog の手法カタログの一部。デプロイ直後の致命傷即検知、小さな修正後の 変更箇所の狭い確認、過去バグの再発防止と継続的な退行防止を検証したい、または 割り当てたいときに使う。通常は test-catalog スキルの索引経由で手法が選定された 後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
システム全体を外から見るレベルのうち、デプロイ前後の足切りや退行防止に使う「運用確認」の層を集める。 ビルドやデプロイの直後、バグ修正の直後、変更を取り込むたびに、本物の環境に近い構成で「壊れていないか」を素早く確かめる。 いずれも網羅は目的でなく、致命傷の即検知(スモーク)・変更箇所の確認(サニティ)・退行の継続防止(回帰)に役割を絞る。
各レベルは「概要」「目的/いつ使う」「example」「落とし穴」「網羅の定義」「遂行手順(着手→完了)」「完了チェック(もれ確認)」で示す。 遂行手順は「何を最小確認とするか → どう書くか → 合否を判定する」を番号付きの手順に落とし、完了チェックは漏れ(項目過多・スキップ黙殺など)を実際に検出する確認項目を並べる。
ビルドやデプロイ直後に、最重要機能がそもそも起動して動作するかを最短で確認する。
詳細テストを回す価値があるかの足切りに使う。デプロイ後のヘルスチェックにも使う。 網羅的な検証には使わない(目的は「致命傷の即検知」だけ)。
import { describe, it, expect } from "vitest";
const BASE = process.env.SYSTEM_URL ?? "http://localhost:8080";
// 起動の生死だけを数秒で確認する最小集合
describe("smoke", () => {
it("ヘルスチェックが 200 を返す", async () => {
const res = await fetch(`${BASE}/health`);
expect(res.status).toBe(200);
});
});
あれもこれもと項目を足すとスモークでなくなり、足切りの速さという利点を失う。 逆に health だけ見て主要機能の 1 経路を入れないと、起動はするが壊れている状態を通す。
このレベルは「最重要機能の起動と生存のみ」を対象に取る層。 網羅ではなく致命傷の即検知が目的なので、対象は意図的に最小に絞る。
スモークの本体は「落ちたら以降のテストすべてが無意味になる致命点だけを、数秒で確認する最小集合に絞る」ことだ。何を最小確認とするかの線引きが甘いと、足切りの速さという唯一の利点を失う。次の順で進める。
特定の修正や小変更が意図どおり効いているかを、狭い範囲で素早く確認する。
バグ修正後や小さな変更後に、その箇所と周辺だけを軽く確かめたいときに使う。 全体の健全性確認には使わない(それはスモークや回帰の役割)。
import { describe, it, expect } from "vitest";
import { parseAmount } from "./parse-amount";
// 直前の修正点(全角数字の許容)に絞って確認する
describe("sanity: parseAmount 全角対応", () => {
it("全角数字を半角として解釈する", () => {
expect(parseAmount("１２３")).toBe(123);
});
});
スモークとの線引きが曖昧になりやすい。スモークは「広く浅く起動確認」、サニティは「狭く深く変更確認」と役割で分ける。 サニティで通ったから全体も大丈夫、と早合点して回帰を省くと別の箇所の退行を見逃す。
このレベルは「直近の修正点とその周辺のみ」を対象に取る層。 広く浅くではなく、変更箇所を狭く深く確認することに限定する。
サニティの本体は「今回の変更点を特定し、その意図どおりの挙動と、変更が直接触れた周辺だけを狭く深く確認する」ことだ。最小確認の範囲は「変更が触れた所」であって全体ではない。次の順で進める。
parseAmount)。何を直したかが曖昧なら、まずそこを言語化する。変更によって既存の動作が壊れていないかを、過去に通ったテスト群を再実行して確認する。
コード変更、依存更新、リファクタのたびに、CI で継続的に走らせる。 新機能そのものの検証には使わない(回帰は「壊していないこと」の保証)。
import { describe, it, expect } from "vitest";
import { renderInvoice } from "./invoice";
// 過去に修正したバグを再発防止として固定する(バグ番号を残すと由来が追える)
describe("回帰", () => {
it("#482: 数量 0 の行で NaN を出さない", () => {
const out = renderInvoice([{ name: "X", qty: 0, price: 100 }]);
expect(out).not.toContain("NaN");
});
});
落ちたテストを直さず skip で黙らせると、回帰スイートは飾りになる。 過去バグの再現テストを残さないと、同じ欠陥が何度でも戻ってくる。修正のたびに 1 本固定する。
このレベルは「過去に通った振る舞い全体と、再発防止すべき既知バグ」を網羅対象に取る層。 新機能の検証ではなく、壊していないことの継続的な保証に集中する。
回帰の本体は「バグ修正のたびに再現テストを1本ずつ追加し、過去分を消さずに蓄積し、CI で継続実行して退行を捕まえ続ける」ことだ。一回ぽっきりでなく、修正のたびに積み増す運用が核心。次の順で進める。
#482 など)、なぜ存在するかを追える形で残す。以後このテストは消さず蓄積する。grep -rn "\.skip\|\.only\|\.todo\|xit(\|xdescribe(" <testdir> または lint ルール(例 no-disabled-tests)で、黙らされたテストが残っていないか機械的に確認する。手目視だけだと見落とす。skip が残るなら、それは守られていない退行ケース。git log で回帰テストの削除がないか追える状態か。レベルを選んだあとの配分(ピラミッド/トロフィー)と階層化(関心事による分割)は strategy-allocation.md を読む(levels.md 末尾と同じ)。
広域確認の層(システム/E2E/UAT)は levels-system.md を読む。
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 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 スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。