Derive test cases
Skill idylle-cynique/solo-dev-skills/skills/derive-test-cases
Claude Code / GitHub Copilot 等向けエージェントスキル集（gh skill installで導入可能）
npx -y skills add idylle-cynique/solo-dev-skills --skill derive-test-casesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
分岐・条件分岐を持つ実装の各分岐を網羅する形で、テストケースを 「#, テストケース, 検証内容, 期待する結果」の4列Markdownテーブルとして導出するスキル。 既存の実装資料（実装計画・ダイアグラム・仕様書等）が見つかればそれを使い、無ければブランチのコミット・diffを直接読んで対応するテストケースを導出する。 テストケースを作ってほしい、分岐を網羅するテストを洗い出したい、と言われたときは明示されていなくても積極的にこのスキルを参照すること。
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.6 KB, as published. Nobody here has run it
以下の手順で入力源を決定し、テストケースをMarkdownテーブルとして出力してください。
入力の解決順序
対象が引数で明示されていればそれに従う。省略された場合は、以下の優先順で入力源を決定する。
- 既存の実装資料を確認する: 関連するIssue番号が分かる場合は
.vscode/docs/tasks/<issue番号>/を、不明な場合は.vscode/docs/plans/を確認する（Glob/Readで探索）。設計ドキュメント・ フローチャート・シーケンス図等（design-diagramの出力を含む）が見つかれば、それを入力とする。 資料が分岐を含まない（ER図のみ等）場合は、次点として2を試す。 - 実装資料が無い、または分岐情報を含まない場合、ブランチのcommit/diffを確認する:
git log --oneline <base>..HEAD（<base>はデフォルトブランチ。不明ならmain）で 現在のブランチが積んでいるコミットを確認するgit diff <base>...HEADで変更内容を把握する- 変更された箇所のコードを実際に
Readし、追加・変更された条件分岐（if/case/早期return/exit等）を直接分析する。既存の分岐で今回のdiffが動作を変えていない箇所は対象外とする （今回の変更に対応するテストケースを作ることが目的のため）。ただし変更が既存の分岐の前提を 壊していないか確認する意味で、影響を受ける既存分岐を候補に含めてもよい
- どちらも得られない場合（対象が不明瞭で、実装資料もdiffも特定できない場合）は、対象を明示する よう一言確認してから進める。
1. 分岐の列挙
入力源に応じて以下のように分岐を洗い出す。
- 実装資料（ダイアグラム含む）が入力の場合: 処理順（フローチャートなら上から下、シーケンス図
なら時系列順）に辿り、分岐ノード・条件分岐ブロック（
alt/opt等）ごとに各エッジ・各ケースを 1つのテストケース候補とする - commit/diffが入力の場合: 変更されたファイルごとに、追加・変更された分岐を1つずつ特定する
いずれの入力源でも、共通して以下を候補に含める。
- すべての終端点（
exit/return/エラー）も、そこに至る条件を1つのテストケース候補とする - ループがある場合は「ループを0回スキップする」「1回だけ処理する」「複数回のうち先頭でだけ終了条件を 満たす」などループ特有のケースも候補に含める
- 単純な分岐の組み合わせ漏れがないか確認する（例:「条件Aかつ条件B」のような複合違反ケース）
抜け漏れを防ぐため、分岐点の数と終端点の数を数え、テストケース数がそれと整合するか確認する （1分岐＝最低2ケースが目安。ただし同一分岐から派生する複合ケースはこの限りではない）。
2. テーブルの作成
以下の4列形式で出力する。列の追加・省略はしない。
| # | テストケース | 検証内容 | 期待する結果 |
|---|---|---|---|
| 1 | <何を確認するテストか、短い名前> | <どういう入力・状態でテストを実行するか> | <exit code・出力メッセージなど、具体的に確認する内容> |
- 「検証内容」には具体的な入力条件を書く（「◯◯が空の場合」ではなく「
assigneesが空配列の場合」など、 実際のデータ形状が分かる粒度で書く） - 「期待する結果」には、
exit codeや出力に含まれるべき文字列など、テストのassertionにそのまま 転記できる具体性で書く - テーブルの行順は入力源の処理順（ダイアグラムの処理順、またはdiffのファイル順→コード上の出現順） に揃える
3. 既存テストとの突き合わせ（対象コードにテストが存在する場合）
対象コードに対応するテストファイルが既に存在する場合は、Grepでテスト関数名・assertion文字列を
突き合わせ、導出したテストケースのうちどれが実装済みで、どれが未実装（カバレッジの穴）かを確認する。
未実装のケースがあれば、テーブルの後に以下の形式で報告する。意図的にスコープ外とされたケース （設計判断でテスト対象外にしたことが分かっている場合）と、単純な実装漏れの可能性があるケースを 区別して書く。
## 既存テストスイートとの対応
`<テストディレクトリ>` には現在<N>件のテストが実装済みで、上表のうち **#X・#Y は未実装**。
- **#X（<ケース名>）**: <意図的にスコープ外とした理由、または実装漏れの可能性>
4. 出力
出力先: 関連Issueがある場合は .vscode/docs/tasks/<issue番号>/<対象名>-test-cases.md、
Issueが不明な場合は .vscode/docs/plans/<対象名>-test-cases.md。
出力例は examples/sample.md を参照。
完了報告
- 入力源として使ったもの（実装資料/ダイアグラムのパス、またはdiffの対象コミット範囲）
- 生成したファイルのパス
- 導出したテストケース数
- 既存テストとの突き合わせを行った場合は、未実装ケースの件数と概要