| name | x-designing-usecases |
| description | テストの抜け漏れを防ぐためにユースケースを設計するスキルです。 「ユースケースを書きたい」「テスト観点が足りているか確認して」「受け入れ条件を整理したい」 「テスト戦略を整理したい」「何をテストすればいいかわからない」のように使います。 対象 × インターフェースで系統分け（E: エンドユーザー / D: 開発者 / O: 運用者）し、 各UCに観点と適用される状況軸を紐づけて、テスト計画への入力となるUC表を作ります。 明示的に「ユースケース」と言われなくても、テスト観点・抜け漏れに関する相談が来たら積極的に起動します。 テスト計画とテストコードの生成は別スキル`x-designing-testcases`で扱います。
|
| allowed-tools | ["Read","Glob","Grep","AskUserQuestion","TaskCreate","TaskUpdate","TaskList"] |
designing-usecases
「対象者 × インターフェイス」で系統分けし、各系統に観点と適用される状況軸を紐づけたUC表を作ります。出力はx-designing-testcasesの入力となります。
核となる方針
系統分けは「対象者 × インターフェイス」で行う
対象者ごとに触れるインターフェイスが違うため、達成したいこと・観察可能性・失敗の意味・主たるテスト種別がすべて変わります。1つのユースケース表に複数系統を混在させてはいけません。
| 系統 | 対象者 | インターフェイス |
|---|
| E | エンドユーザー | UI（画面・操作・通知） |
| D | 開発者（消費者） | コードAPI（関数、props、型） |
| O | 運用者・管理者 | 管理画面 / CLI |
各系統の定義・観点チェックリスト・典型的な失敗モードは以下を読んでください。
| 系統 | reference |
|---|
| E | references/system-end-user.md |
| D | references/system-developer.md |
| O | references/system-operator.md |
非人間アクターはUCの主体にしない
外部システム / 時間 / ランタイム環境 / ネットワークは、各系統UCに横断的に作用する状況・制約として記述します。
| 状況軸ID | 軸 |
|---|
cond.external | 外部システム（API、Webhook、決済、認証） |
cond.time | 時間（TZ、DST、期限、TTL、放置） |
cond.runtime | ランタイム環境（ブラウザライフサイクル、SSR/CSR、ストレージ） |
cond.network | ネットワーク（オフライン、低速、中断） |
各状況軸の観点チェックリストと系統別の現れ方はreferences/conditions.mdを読んでください。
タスク登録（実行開始時に必ず実施）
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|
| 1 | タスク判定 | — |
| 2 | UC表のレビューまたは新規作成 | 1 |
タスク判定
| 入力 | タスク |
|---|
| 既存のUC表がある | タスクA: UC表のレビュー |
| ゼロから始める | タスクA': UC表の新規作成 |
判定が曖昧な場合は「主たる対象者は誰ですか？（エンドユーザー / 統合する開発者 / 社内オペレーター）」と確認します。
タスクA: UC表のレビュー
既存のUC表を入力として受け取ります。
ステップ
-
スコープ判定 — 対象システムのタイプを特定し、読むreferenceを決めます。
| 対象システムのタイプ | 読むreference |
|---|
| B2C / B2B プロダクト | system-end-user.md, system-operator.md, conditions.md, templates.md |
| コンポーネントライブラリ / SDK / APIサービス | system-developer.md, conditions.md, templates.md |
| 管理ツール / 内製運用システム | system-operator.md, conditions.md, templates.md |
| 全レイヤーを含む大型プロダクト | 全reference |
-
系統確認 — 各UCの系統が明示されているか確認します。明示なければ内容から推定して指摘します。
-
混在確認 — 1UCに複数系統が混在していないか確認します。混在していれば分割を提案します。
-
欠落系統の指摘 — 対象システムのスコープに対して欠けている系統があれば指摘します。
-
状況軸の確認 — 各UCにconditions.mdのチェックリストを当て、未カバーの状況軸を列挙します。
完了条件
完了条件を満たしたら結果をユーザーに提示し、承認を得てからx-designing-testcasesに引き渡します。
タスクA': UC表の新規作成
機能仕様または未整理の要件を入力として受け取り、UC表をゼロから作成します。
ステップ
- 対象機能の確認 — 機能名、解決したい課題、想定される利用者を確認します。曖昧なら対話で詰めます。
- 系統の列挙 — タスクAのステップ1と同じく、対象システムのタイプから関わる系統を列挙します。
- 系統ごとにUCを起こす — 各系統について
references/templates.mdのテンプレートにしたがってUCを記述します。
- 状況軸の付与 — 各UCに
references/conditions.mdから該当する状況軸を当てます。
- 重複・矛盾確認 — 系統間で重複した観察対象や矛盾する期待結果がないか確認します。
完了条件
完了条件を満たしたらUC表をユーザーに提示し、承認を得てからx-designing-testcasesに引き渡します。
引き渡しスキーマ
各UCがreferences/templates.mdのスキーマを満たした状態でx-designing-testcasesに引き渡します。
共通の落とし穴
| 落とし穴 | 対処 |
|---|
| 「対象者: エンドユーザー / 開発者」だけで分類する | 状況軸（cond.xxx）の記述場所がなくなります。状況軸を必ず併用してください。 |
| 1UCに複数系統を混ぜる | UI操作のステップとAPI呼び出しの戻り値が同じUCに書かれていたら必ず分割します。 |
| 状況軸を全UCに重複コピペする | cond.externalのHTTP 5xx観点は、共通仕様としてconditions.mdを参照する形で十分です。 |
| 系統Dで型で済むものを観察対象にする | 型レベルで防げるものはUCの観察対象に書きません（実装時に自然に型で担保されます）。 |
| 系統Oを忘れる | B2Cプロダクトでも運用業務は必ず存在します。スコープに入るかを最初に確認してください。 |
| 「観察可能な期待結果」に内部状態を書く | UCの観察対象は系統に対応するインターフェイスから見えるものに限定します。 |
