菜单
期待値(oracle)を用意しにくい対象の頑健性を、機械生成した不正・極端・ランダムな入力を 大量に流し込んで叩く手法(ファジング、カバレッジガイデッドファジング)を扱う。 test-catalog の手法カタログの一部。パーサー・デシリアライザ・入力検証など信頼できない 入力境界で「壊れない・止まらない・不変条件を保つ」ことを検証したい、または割り当てたい ときに使う。通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを 直接参照する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | generative-fuzzing |
| description | 期待値(oracle)を用意しにくい対象の頑健性を、機械生成した不正・極端・ランダムな入力を 大量に流し込んで叩く手法(ファジング、カバレッジガイデッドファジング)を扱う。 test-catalog の手法カタログの一部。パーサー・デシリアライザ・入力検証など信頼できない 入力境界で「壊れない・止まらない・不変条件を保つ」ことを検証したい、または割り当てたい ときに使う。通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを 直接参照する。 |
| disable-model-invocation | true |
不正・極端・ランダムな入力を大量に流し込み、「壊れないこと」(クラッシュ・ハング・未処理例外・不変条件違反が起きないこと)を叩く系をまとめる。
性質や組合せで正しさを縛る系(PBT / コンビナトリアル)は generative-property.md に分けた。
ファジングは出力の正解を要求しない点が要で、判定は「落ちない・止まらない・不変条件を保つ」で済む。 だからこそ「何をもって十分叩いたか」(到達した分岐・育てたコーパス・打ち切り判定)を決めないと、回しただけで終わる。各項目は「概要」「目的/いつ使う」「TypeScript example」「落とし穴」「遂行手順(着手→完了)」「完了チェック(もれ確認)」「網羅設計での効かせ方」の構成で示す。
不正、極端、ランダムなバイト列や文字列を大量に流し込み、クラッシュ、ハング、assertion 違反、未処理例外を起こす入力を探す。
パーサー、デシリアライザ、入力検証、ファイル/プロトコル境界など「信頼できない入力」を受ける箇所の頑健性を確かめる。 判定は「壊れないこと」(落ちない、無限ループしない、不変条件を保つ)で済むので、出力の正解が要らないのが利点。 出力の意味的正しさまで問いたいなら、ファジングではなく PBT やメタモルフィックを使う。
fast-check をファザーとして使い、任意文字列でパーサーが例外を投げず必ず判定を返すことを確認する。
import { describe, it, expect } from "vitest";
import fc from "fast-check";
import { parseConfig } from "./config";
describe("parseConfig: fuzzing", () => {
it("never throws and always returns ok|error for any string", () => {
fc.assert(
fc.property(fc.string(), (raw) => {
const r = parseConfig(raw); // 例外を投げたらここで失敗扱い
expect(r.kind === "ok" || r.kind === "error").toBe(true);
}),
{ numRuns: 5000, seed: 1 }, // 打ち切り(試行回数)と再現用 seed を固定
);
});
});
ファジングの本体は「信頼できない入口を1つ決め、壊れの定義(オラクル)を据え、打ち切りまで叩く」ことだ。次の順で進める。
parseConfig・deserialize・decodeFrame など)を1つ選ぶ。境界をまたぐ複数関数を一度に叩かない(どこで壊れたか切り分けられなくなる)。r.kind が ok|error のいずれか、長さ・範囲・型の制約を満たす、など。ここを省くと黙って誤値を返すバグがすり抜ける(落とし穴)。fc.string()・fc.uint8Array() など、対象が実際に受けるバイト/文字空間を広く覆う生成器を選ぶ。狭い生成器(英数字のみ等)は異常系を踏まない。numRuns(試行回数)か wall-clock 時間で打ち切る。「何回(何分)叩いて壊れなければ緑とみなすか」を明示し、CI で回す回数と夜間で回す回数を分ける。grep -n "expect" <test> で、戻り値の不変条件(kind が ok|error 等)を assert しているか確認する。これが無いと誤値バグがすり抜ける。numRuns か時間制限が指定されているか。無ければ「十分叩いた」が無根拠。ファジングの網羅対象は入出力の対応ではなく、「信頼できない入力境界で壊れを起こす入力が存在しないこと」だ。
正解 oracle を持たないので、網羅は「到達した分岐」と「育てたコーパス」で近似する(完全な網羅は測れない、近似であると割り切る)。
壊れの定義(クラッシュ・ハング・不変条件違反)が網羅対象の集合を決める。不変条件を1つ足すごとに、ファジングが検出できる「壊れ」の種類が増える。
ゆえに頑健性の網羅を広げる手は、入力生成器を広げることと、不変条件を増やすことの2方向になる。
出力の意味的正しさ(値が仕様どおりか)はファジングの網羅対象外なので、そこは PBT・メタモルフィック(generative-property.md、oracle-relational.md)へ振る。
配分の原則は、信頼境界の「落ちなさ」はファジングで近似網羅し、意味的正しさは性質ベースに分担させることだ。
実行時のコードカバレッジを計測し、新しい経路を開拓した入力を「種」として残して変異させる。 ランダムな総当たりより遥かに速く深いパスへ到達する(AFL/libFuzzer 系の発想)。
パーサーやバイナリ処理など分岐が深く、素朴なランダム入力では奥まで届かない対象に使う。
JS/TS では @jazzer.js や jsfuzz がカバレッジ計装つきのファザーを提供する。
分岐が浅く入力空間も狭いなら、計装のコストに見合わないので通常のファジングや PBT で足りる。
@jazzer.js のファズターゲットの最小形(専用ランナー jazzer で起動し、コーパスを育てる)。
// fuzz/parse.fuzz.ts -> npx jazzer fuzz/parse.fuzz.ts corpus/ -- -max_total_time=60
import { FuzzedDataProvider } from "@jazzer.js/core";
import { parseConfig } from "../config";
export function fuzz(data: Buffer) {
const provider = new FuzzedDataProvider(data);
const raw = provider.consumeRemainingAsString();
const r = parseConfig(raw);
// 不変条件: 必ず判定が返る。破れたら throw してクラッシュ扱いにする
if (r.kind !== "ok" && r.kind !== "error") throw new Error("invalid result");
}
CGF はファジングに「カバレッジ計測によるコーパス育成」を足したものだ。到達分岐の計測と打ち切り判定が手順の中核になる。
@jazzer.js(libFuzzer ベース)や jsfuzz を入れ、対象モジュールがカバレッジ計装の対象に入るよう設定する。通常の vitest とは別ランナー・別エントリ(*.fuzz.ts)になる。fuzz(data: Buffer) で生バイトを受け、FuzzedDataProvider で対象の入力型へ変換し、対象を1回呼ぶ。ファジングと同じく不変条件違反は throw してクラッシュ扱いにする(壊れの定義を据える)。corpus/ を引数に渡し、ファザーがそこに新規経路を開いた入力を溜める。これを git か CI アーティファクトで保存し、回帰の種にする(捨てると毎回ゼロ探索)。corpus/ に置いてから走らせる。種があると分岐の深部へ早く届く。cov: / 新規 feature 検出)を見て、新規経路を開く入力が枯れる(カバレッジが伸びなくなる)まで走らせる。-max_total_time か -runs で1回の上限を切る。crash-*)を最小化(-minimize_crash=1 等)し、コーパスと回帰テストに固定する。最小化した入力を通常の例ベーステストにも落とし、計装無しでも再現できるようにする。corpus/ が保存(git/アーティファクト)され、次回の種として再利用されるか。捨てていれば毎回ゼロ探索で深部に届かない。throw でクラッシュ扱いになっているか。return で握り潰していないか。CGF の網羅対象は「到達したコードカバレッジ(分岐・パス)」そのものであり、これを最大化することが網羅の駆動力になる。 素朴なファジングがランダムに入力を撒くのに対し、CGF はカバレッジを報酬にして「まだ踏んでいない分岐を開く入力」を残し変異させるので、深い分岐を持つ対象で網羅が桁違いに伸びる。 ただし測れるのは構造カバレッジ(到達した分岐)であって、意味的正しさではない。網羅基準は「新規経路を開く入力が枯れる(カバレッジが頭打ち)まで探索し、育てたコーパスで近似」と置く。 コーパスは育てた網羅の保存形そのものなので、捨てると網羅がリセットされる。永続化が網羅の連続性を担保する。 壊れの定義(ファズターゲット内の不変条件)が、その網羅で何を検出できるかを決める。カバレッジを稼いでも不変条件が薄ければ「踏んだだけ」で終わる。 配分の原則は、分岐が深く素朴な乱数では奥へ届かない対象だけ CGF に寄せ、浅い対象は通常ファジング/PBT に留めることだ(計装コストに見合わない網羅は取らない)。
入力全体に成り立つ性質で縛る(PBT)、パラメータの組合せを covering array で覆う(コンビナトリアル)系は、generative-property.md にまとめた。
正解を直接持たないまま、別の参照や関係で正しさを判定する手法は、過去出力基準(スナップショット、承認テスト、仕様化テスト)を oracle-past-output.md、別実装基準(差分テスト)を oracle-differential.md、関係/モデル基準(メタモルフィックテスト、モデルベーステスト、形式検証連携)を oracle-relational.md にまとめた。
テストを書く道具としての LLM(AI/LLM 支援テスト生成)と、製品に組み込まれた非決定的出力そのものの検証(階層化品質設計)は、ai-nondeterministic.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 スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。