hymme

内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 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 スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

期待値を1つずつ手で用意できないとき、正しいと信じられる別実装(参照実装・旧実装・別ライブラリ)と 出力を突き合わせる差分テスト(Differential Testing)を扱う。test-catalog の手法カタログの一部。 参照実装の独立性確認、入力空間の共通化、出力差ゼロの assert、浮動小数の許容誤差比較、 移行完了までの併走運用を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。

機能の正しさより外側にある、プロセス運用・静的検査・分類に収まりにくい観点を扱う。 test-catalog の手法カタログの一部。群B(BDD/Gherkin、ATDD、CI自動実行、シフトレフト/シフトライト、 カナリアリリース、ブルーグリーン/A-B、フィーチャーフラグ段階検証、合成監視、 ミューテーション/カバレッジのCIゲート、テストデータ管理、フレークテスト対策)、 群C(静的解析Linter/型チェッカ、コードレビュー、複雑度メトリクス)、 群D(冪等性テスト、並行性/レースコンディションテスト、境界外/極値・ネガティブテスト) を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。

レビュー指摘・自力検知した失敗への対応ワークフロー。PR のレビューコメントや人間からの指摘を受けて修正するとき、「レビュー指摘に対応して」「レビューコメントもらった」「指摘を直して」と頼まれたら必ず使う。レビュー経由でなくても、再発しうる失敗(CI の赤、真因を特定したバグ、運用事故)を自分で踏んで直した直後にも同じフローを回す。指摘された箇所だけ直して終わらせない——なぜ事前のセルフレビュー(diff-review)で見つけられなかったかを分析し、同種の穴を差分全体から水平展開で探し、観点をレンズ基準・hook・テスト等のどこかへ埋め込み、lessons に記録する。同じ種類の指摘を二度もらうのは学習しなかったという意思表示。

作業ブランチの diff を複数観点(レンズ)で並列レビューするオーケストレーションスキル。「レビューして」「diff をレビュー」「〇〇観点で見て」などユーザーが明示的にコードレビューを依頼したときに必ず使用する。決定論スクリプトで差分を収集し、レンズごとに diff-reviewer サブエージェントを並列起動して結果を統合報告する。コードの修正は行わない。

進捗台帳と計画・引き継ぎ文書の運用ルール。todo・計画書・テストリスト・STATUS 等のチェックボックス付き文書を作る/更新する、「台帳を更新して」「進捗をまとめて」「引き継ぎ文書を書いて」「todo を整理して」と頼まれる、作業完了で台帳を消し込む、スナップショット文書(STATUS/RESUME)を発行する、といった場面で参照する。記法の凡例を一本化し、消し込み先を1ファイルに固定し、完了主張に証跡ポインタを義務付け、完了文書を closed で閉じる。台帳が緑を偽らない・履歴が消えない・読み手が考古学をしないための規範。コミット粒度は commit-flow、教訓の記録は review-feedback が担う。

Pull Request / Merge Request を作成するときに必ず参照する。`gh pr create`/`glab mr create` で PR/MR を作る、コミット済みの作業をレビューに出す、並列・stacked 作業の各ブランチで PR を起こす、といった場面で使う。リポジトリの pull_request_template/merge_request_template を決定論スクリプトで検出して優先し、テンプレの骨組み（見出し・チェックリスト・順序）を改変せず入力箇所を埋めるだけにする（作成前に骨組み照合ゲートで機械検証）。無ければ汎用観点で本文を構成。作成前に diff-review でのセルフレビュー反復（must ゼロまで）を必須とし、証跡を hook が検査する。本文の素材は対象リポジトリの git 差分のみに限定し、他リポジトリ・他タスクの内容を混入させない。draft 既定・作成前にユーザー承認。未 push のときは AskUserQuestion で承認を取ってから push。GitHub(gh) 基本、GitLab(glab) 等にも対応。

GitHub Actions の CI 失敗を調査するスキル。失敗した run / PR / job の URL（例: https://github.com/OWNER/REPO/actions/runs/RUNID、…/pull/PR、…/job/JOBID）や run_id・PR 番号を貼られて「このCIが失敗している、原因を調査して」「ビルド/テストがコケた、なぜ落ちたか調べて」「workflow が failed、修正案を出して」「job のログを見て」と頼まれたら必ず使う。WebFetch では github.com のログは取れない（HTML しか返らずログは取れない）ため、gh（`gh run view --log-failed` / `gh run view --job` / `gh pr checks` / `gh api`）で失敗ジョブ・ステップと失敗ステップのログだけを決定論スクリプトで収集し、失敗原因を特定して修正案を提示する。GitHub Actions 以外（GitLab CI 等）や、URL がログではなくソース閲覧目的のときは対象外。GitHub(gh) 前提。`/gh-ci-investigate` で明示起動も可。

テスト実行時の絞り込み運用ルール。プロジェクト全体テストではなく修正範囲に絞ったテスト実行を行う。 `gradlew test`/`pytest`/`jest`/`go test`等のテストランナーを実行するとき、テスト実行コマンドを 組み立てるときに必ず参照する。コミット差分や修正ファイルから対象テストを特定する手順を含む。

loop-engineering の 0 段(抽出ループ)。元仕様(RFC、標準、自然言語の要求、既存コード)から要件を 採番チェックリスト台帳へ網羅的に抜き出し、トレーサビリティ・マトリクスを立てる。 「要件を抽出して」「仕様から要件に落として」「抽出台帳」「トレーサビリティ」と言われたとき、 または loop-engineering ルーターから 0 段として委譲されたときに使用する。 後続の loopeng-formalize(EARS/TLA+)はこの台帳が完成(全 ID `[x]`・欠番なし)してからでないと進めない。 通常は loop-engineering ルーターの判断(2 問ゲート)を通ってから使う。

loop-engineering の外ループ(要求形式化)。抽出済みの要件を EARS 記法 + 状態/ドメインモデルへ構造化し、 TLA+ spec(<Name>.tla / <Name>.cfg)と Gherkin の骨格(<Name>.feature)に落とす。 「EARS に落として」「状態モデルを作って」「TLA+ spec を書いて」「要求を形式化」と言われたとき、 または loop-engineering ルーターから外ループとして委譲されたときに使用する。 前提: loopeng-extract の抽出台帳(tasks/loopeng/<Name>.extract.md)が完成(全 ID `[x]`・欠番なし)していること。 無ければ先に loopeng-extract へ戻る。通常は loop-engineering ルーターの判断を通ってから使う。

loop-engineering の内ループ(受け入れ仕様化)。TLC の反例トレースを Gherkin の Scenario へ機械変換し、 設計が固まったら正常系の受け入れシナリオを足して実装のテストへ橋渡しする。 「反例を Gherkin に」「受け入れ仕様に落として」「feature ファイルにして」と言われたとき、 または loop-engineering ルーターから内ループとして委譲されたときに使用する。 前提: loopeng-modelcheck の TLC 実行結果(反例トレース、または No error)があること。 無ければ先に loopeng-modelcheck へ戻る。通常は loop-engineering ルーターの判断を通ってから使う。

test-design の 0 段(振る舞い抽出)。対象(機能、モジュール、API、PR 差分)から「テストすべき振る舞い」を T-ID 採番チェックリスト台帳(tasks/test-design/<対象名>.md)へ網羅的に出し切る。 「テストすべき振る舞いを洗い出して」「テスト観点を出して」「T-ID 台帳」と言われたとき、 または test-design ルーターから 0 段として委譲されたときに使用する。既存テストのレビューでも 最初にこの台帳を作る(台帳を両向きに読んで抜け・根拠なしテストを見つける)。 後続の test-catalog(手法選定)はこの台帳が完成(全 T-ID `[x]`・欠番なし)してからでないと進めない。 通常は test-design ルーター経由で使う。

test-design の橋渡しと固定の工程。手法割り当て済みの T-ID 台帳を実装(coder の TDD / loop-engineering / formal-verification)へ渡し、実行ゲート(網羅逆引き・緑・flaky・mutation)で 完了を検証し、緑にしたテストを回帰として CI に固定する。 「テストの実装に渡して」「テストが全部書けたか確認して」「回帰に固定して」と言われたとき、 または test-design ルーターから最終工程として委譲されたときに使用する。 前提: test-catalog で全 T-ID に手法が割り当て済みであること。無ければ先に test-catalog (台帳自体が無ければ test-extract)へ戻る。通常は test-design ルーター経由で使う。

test-design の手法選定工程。テスト手法カタログ(個別スキル 40 本)への索引と、 T-ID 台帳の各振る舞いに手法を割り当てるワークフロー。 「どのテスト手法を使うべきか」、または手法名(同値分割、境界値、ドメイン分析、デシジョンテーブル、 状態遷移、ペアワイズ、直交表、T-way、判定/条件網羅、MC/DC、基底パス、構文テスト、contract/Pact、 property based、mutation、メタモルフィック、ゴールデン、承認、仕様化テスト、チェックリストベース、 テストダブル、LLM・非決定的出力のテスト、EARS)を挙げられたとき、 「テストが flaky」「期待値が用意しにくい」「テストが脆い」の困りごとから手法を探すとき、 または test-design ルーターから手法選定として委譲されたときに使用する。 前提: test-extract の T-ID 台帳(tasks/test-design/<対象名>.md)が完成していること。 無ければ先に test-extract へ戻る(単発の手法質問なら台帳なしで索引だけ引いてよい)。

LLM/生成モデルが関わるテストを2局面(テストを書く道具としてのAI活用、製品に組み込まれた非決定的出力そのものの検証)で扱う。 test-catalog の手法カタログの一部。AI/LLM 支援テスト生成(観点出し、偽陽性/偽陰性対策)、 非決定的出力システムのテスト(階層化品質設計、入口/中央/出口層、スキーマ強制、メタモルフィック、複数サンプリング合意) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

条件の論理関係や入力の多次元構造から、組合せを縮約してテストを導くブラックボックス技法群。 test-catalog の手法カタログの一部。原因結果グラフ(Cause-Effect Graph、AND/OR/NOTでデシジョンテーブルを機械導出)、 クラシフィケーションツリー法(Classification Tree Method、分類軸を同値クラスへ細分し葉の組合せを選ぶ) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

独立した因子が多く全組合せが爆発するとき、因子の被覆や均等割付でケース数を縮約するブラックボックス技法群。 test-catalog の手法カタログの一部。ペアワイズ(Pairwise/All-pairs、全ペアを最低1回被覆)、 直交表(Orthogonal Array、全ペアを同回数で均等割付し主効果まで読む)、 T-way テスト(t個組の高次組合せと制約付き covering array) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

内部実装を見ず、振る舞いが過去の履歴に依存する対象からテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。状態遷移テスト(State Transition、0-switch/N-switch、禁止仕様からの許可/禁止列導出)、 CRUD/エンティティライフサイクルテスト(CRUD/Entity Lifecycle、操作間の整合、削除後の参照) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

仕様の構造から機械的に導くのではなく、経験・過去の欠陥をチェックリストに外部化して消し込むブラックボックス技法群。 test-catalog の手法カタログの一部。チェックリストベーステスト(Checklist-based Testing、満たすべき確認事項を体系的に消し込む)、 エラー推測(Error Guessing、空・null・巨大値・特殊文字・重複・並行など壊れそうな入力を経験と直感で狙い撃つ) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

仕様の構造から機械的に導くのではなく、乱数と即興で対象を揺さぶって欠陥を狙うブラックボックス技法群。 test-catalog の手法カタログの一部。ランダム/アドホックファジング(Random/Ad Hoc Fuzzing、固定seedで不変条件だけ見張る軽量ファジング)、 探索的テスト(Exploratory Testing、チャーターとセッションノートで設計と実行を同時進行)、 アドホックテスト(Ad Hoc Testing、事前設計も記録も持たない最も非形式的な確認) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

仕様の構造から機械的に導くのではなく、業務フローや利用の物語から欠陥を狙うブラックボックス技法群。 test-catalog の手法カタログの一部。ユースケーステスト(Use Case Testing、主成功/代替/例外フローを1本ずつ写す)、 シナリオテスト(Scenario Testing、複数ユースケースをまたぐ現実的な経路を通しで検証)、 構文テスト(Syntax Testing、文法production を1箇所だけ壊す欠落/余分/順序入替/型違反) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

テストが flaky になる要因のうち、外部サービスとの通信と実時間の経過待ちに由来するものへの体系的対策。 test-catalog の手法カタログの一部。外部ネットワーク(実通信への依存をネット遮断で炙り出し、テストダブルで応答を固定する封じ込め)、 タイマー・sleep(固定sleep依存を負荷環境で炙り出し、フェイクタイマーや条件待ちへの置き換え) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

テストが flaky になる原因のうち、値そのものが実行ごとに変わる非決定性(時刻/now・Date、 乱数・UUID、浮動小数の丸め誤差)を検出・封じ込めする手法を扱う。 test-catalog の手法カタログの一部。時刻依存の境界固定、乱数/UUID の注入とseed反復、 浮動小数の許容誤差比較(toBeCloseTo)を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。

期待値(oracle)を用意しにくい対象の頑健性を、機械生成した不正・極端・ランダムな入力を 大量に流し込んで叩く手法(ファジング、カバレッジガイデッドファジング)を扱う。 test-catalog の手法カタログの一部。パーサー・デシリアライザ・入力検証など信頼できない 入力境界で「壊れない・止まらない・不変条件を保つ」ことを検証したい、または割り当てたい ときに使う。通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを 直接参照する。

期待値(oracle)を用意しにくい対象を、入力全体に成り立つ性質やパラメータの組合せで 縛る生成テスト(プロパティベーステスト/PBT、コンビナトリアルテスト)を扱う。 test-catalog の手法カタログの一部。往復(round-trip)・不変条件・メタモルフィック関係 ・既知オラクル一致による性質の列挙、pairwise/t-way covering array による組合せ縮約を 検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

良い単体テストの基本規範(Khorikov『単体テストの考え方/使い方』準拠)を扱う。 test-catalog の手法カタログの一部。古典学派とロンドン学派の使い分け、観察可能な 振る舞いのテスト、良いテストの4本柱(退行保護・リファクタリング耐性・高速フィード バック・保守性)、出力ベース/状態ベース/コミュニケーションベースの検証スタイルの 優先順位を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの 索引経由で手法が選定された後にこのスキルを直接参照する。

テストの粒度選択のうち、システム全体を外から見る運用確認の層(スモークテスト、 サニティテスト、回帰テスト)を扱う。 test-catalog の手法カタログの一部。デプロイ直後の致命傷即検知、小さな修正後の 変更箇所の狭い確認、過去バグの再発防止と継続的な退行防止を検証したい、または 割り当てたいときに使う。通常は test-catalog スキルの索引経由で手法が選定された 後にこのスキルを直接参照する。

テストの粒度選択のうち、サービスを独立にデプロイ可能な箱とみなすサービス間の層 (コンポーネントテスト、コントラクトテスト/Consumer-Driven Contract/Pact、 API スキーマ検証)を扱う。 test-catalog の手法カタログの一部。外部依存だけスタブ化した箱単体の振る舞い検証、 消費側駆動の契約テストによるサービス間互換性の保証、OpenAPI/JSON Schema への構造 準拠を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引 経由で手法が選定された後にこのスキルを直接参照する。

テストの粒度選択のうち、1サービス内部の層(単体テスト/Unit Test、結合テスト/ Integration Test)を扱う。 test-catalog の手法カタログの一部。依存を切り離した最小単位のロジック・分岐・境界 ・例外の網羅、複数モジュールや実依存(DB、キュー、別サービス)との接続部のずれの 検証を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引 経由で手法が選定された後にこのスキルを直接参照する。

テストの粒度選択のうち、システム全体を外から見る広域確認の層(システムテスト、 E2Eテスト、受け入れテスト/UAT)を扱う。 test-catalog の手法カタログの一部。複数サービス・DB・設定が組み合わさった本番に 近い構成での機能/性能/セキュリティ要件の検証、実ブラウザでの主要ユーザーフロー の通し確認、ビジネス側と合意した受け入れ基準へのトレーサビリティを検証したい、 または割り当てたいときに使う。通常は test-catalog スキルの索引経由で手法が選定 された後にこのスキルを直接参照する。

test-catalog の手法カタログの一部。テストの強さを測る(mutation、ミューテーションテスト、 テストの欠陥検出力、Killed/Survived/No coverage、Mutation Score、Stryker)ことを検証したい ときに使う。カバレッジ率が高いのにバグが漏れる状況の正体を暴く、アサーション不足を見つける ときに使う。通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。

非機能のうち「正しく・安全に・誰にでも動くか」を性質の充足(違反0件、契約破壊なし等) で確かめる品質保証系の観点を扱う。 test-catalog の手法カタログの一部。セキュリティテスト、ペネトレーションテスト、 DAST/SAST/IAST、SCA(依存脆弱性)、ユーザビリティ、アクセシビリティ(a11y/WCAG)、 クロスブラウザ互換性、i18n/l10n、信頼性(MTBF)、可用性フェイルオーバ、 カオスエンジニアリング、回復性、コントラクトテスト(Consumer-Driven Contract/Pact) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

過負荷や依存劣化を封じ込める仕組みが設計どおり働くか、スキーマ移行・データ変換が情報を保存するかを 障害注入と不変条件で確かめる観点を扱う。test-catalog の手法カタログの一部。 バルクヘッド(隔離)、レートリミット、サーキットブレーカ(状態遷移の全遷移と復帰経路)、 データ品質/マイグレーション整合テスト(往復一致、行数保存、必須列の非NULL、集計一致) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。

期待値を1つずつ手で用意できないとき、システムの振る舞いを抽象モデル(状態機械など)で表し、 そこからテスト系列(操作の列)を自動生成して実システムと突き合わせるモデルベーステスト (Model-Based Testing)を扱う。test-catalog の手法カタログの一部。 抽象モデルの定義、fast-check の commands によるステートフル PBT、 状態・遷移の網羅確認、モデルの素朴さの維持を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。