菜单
要求トレーサビリティ（REQ→TCND→TEST）とカバレッジモデルによりテスト設計の抜け漏れを防止する監査スキル。モデル化・複数視点監査で体系的に検証する。Use when: テスト設計、テスト計画作成、QA開始前、「テスト漏れがないか不安」と感じた時
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。
iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。
Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。
Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.
Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.
Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.
基于 SOC 职业分类
| name | test-design-audit |
| description | 要求トレーサビリティ（REQ→TCND→TEST）とカバレッジモデルによりテスト設計の抜け漏れを防止する監査スキル。モデル化・複数視点監査で体系的に検証する。Use when: テスト設計、テスト計画作成、QA開始前、「テスト漏れがないか不安」と感じた時 |
生成AIの限界を理解する：AIは「それらしい網羅」を"生成"するのは得意だが、「何が未生成か」を"証明"するのは苦手。
対策：列挙前に「モデル化」と「監査」を挿入し、抜けを"見える化"する。
現実には状態空間・入力空間・環境差分が巨大で"全組み合わせを全件テスト"は成立しない。 実務的な「抜け漏れがない」の定義：
Phase 0: コンテキストパック収集
↓
Phase 1: 要求の棚卸し（REQ-xxx）
↓
Phase 2: モデル化（5つのモデル）
↓
Phase 3: カバレッジ基準策定
↓
Phase 4: テスト条件ツリー（TCND-xxx）
↓
Phase 5: 監査（複数視点）
↓
Phase 6: テスト項目生成（TEST-xxx）
↓
Phase 7: トレーサビリティ検証
↓
Phase 8: 差分運用
AIに渡す情報を固定する。情報が散らばるとモデルが不安定になり抜けが増える。
| カテゴリ | 収集内容 |
|---|---|
| システム概要 | 何をするシステムか |
| 対象範囲 | スコープ内/スコープ外の明示 |
| ユースケース | 主要ユーザーフロー |
| 依存 | 外部API、決済、認証、Push、DB、OS機能 |
| データ制約 | 入力バリデーション、桁、形式 |
| 権限・ロール | ユーザー種別とアクセス制御 |
| 非機能 | 性能、セキュリティ、可用性、監査ログ、アクセシビリティ |
| 運用 | 障害時対応、監視、リリース、バックアウト |
| 既知障害 | 過去のインシデント、ヒヤリハット |
| 受入基準 | Doneの定義 |
警告: ここが薄いとAIは「一般論のテスト」になり、固有リスクを取り逃がす。
目的: 要求を「テスト可能な形」に変換する。
| REQ ID | 種類 | 要求概要 | 受入条件（観測可能） |
|--------|------|---------|-------------------|
| REQ-001 | 機能 | ログイン機能 | 正しい資格情報でセッション発行 |
| REQ-002 | 非機能 | レスポンス2秒以内 | 95%タイルで2秒以下 |
| REQ-003 | 制約 | パスワード8文字以上 | 7文字以下でエラー |
要求一覧とは別に「不明点・矛盾・仮定」セクションを設ける。これがないと仮定が埋め込まれたまま進む。
核心: テストは列挙ではなく、モデルから導出する。
詳細テンプレートは references/model-templates.md を参照。
機能 → サブ機能 → 操作/イベント → 期待結果
主要状態と遷移イベントを明確化。
例：未ログイン → ログイン中 → トークン期限切れ → 退会済み
制約: 不正な状態遷移（「退会済み→ログイン中」は不可など）を明示する。
エンティティ、属性、制約、整合性、更新規則。PIIや秘匿データの扱い。
API一覧、リクエスト/レスポンス、エラーコード、リトライ方針、タイムアウト、冪等性。
契約: API契約を事前条件（入力制約）/事後条件（出力保証）として明示する。
失敗モード → 影響 → 検出方法 → 予防/緩和 → テスト観点
「何を満たすと網羅と言えるか」を明示。これがないとAIは"それっぽい数"で止まる。
詳細は references/coverage-criteria.md を参照。
| 基準 | 定義 |
|---|---|
| 要求カバレッジ | 全REQに対して少なくとも1つのTCND |
| 状態遷移カバレッジ | 主要遷移（正常/異常）をすべて通す |
| 入力空間カバレッジ | 同値分割＋境界値 |
| エラー網羅 | 外部IFの代表的失敗（timeout/5xx/4xx/不正payload） |
| 品質特性カバレッジ | 性能・セキュリティ・可用性・監査ログ・アクセシビリティ |
| 環境カバレッジ | OS/端末/ネットワーク/言語/権限（必要な範囲） |
テスト項目を直接書かせず、まずテスト条件の木を作らせる。
Feature A
├── 正常系
│ ├── TCND-001: 基本フロー成功
│ └── TCND-002: オプション付きフロー
├── 入力バリデーション
│ ├── TCND-003: 必須項目欠落
│ └── TCND-004: 形式不正（境界値）
├── 状態依存
│ ├── TCND-005: 状態S1からの操作
│ └── TCND-006: 状態S2からの操作
├── 外部IF失敗
│ ├── TCND-007: timeout
│ └── TCND-008: 5xx応答
├── セキュリティ
│ ├── TCND-009: 権限不足
│ └── TCND-010: 不正操作
├── 性能/負荷
│ └── TCND-011: 同時接続100件
└── 監査ログ
└── TCND-012: 操作記録確認
TCND-xxx のIDを付与(UNKNOWN) ラベルをつけて残す（消さない）核心: 生成AIを「批判側」に回す。役割を変えると見つかる抜けが増える。
あなたはテスト監査人（生成した本人ではない体）。
以下のテスト条件ツリーを監査し、抜け漏れの可能性を列挙せよ。
詳細チェックリストは references/audit-checklist.md を参照。
必須観点:
監査は最低2回、異なる視点で行う：
ツリーの「葉」から生成する。葉IDがあるので抜けが追える。
| TEST ID | TCND | REQ | 前提条件 | 入力 | 期待結果 |
|---------|------|-----|---------|-----|---------|
| TEST-001 | TCND-001 | REQ-001 | 未ログイン状態 | 有効なID/PW | セッション発行 |
| TEST-002 | TCND-003 | REQ-003 | - | 7文字PW | エラー表示 |
| TEST-003 | TCND-007 | REQ-004 | 外部API停止中 | 任意 | フォールバック動作 |
(UNKNOWN) はテストを捏造せず、質問・前提の形で残す| REQ ID | TCND | TEST | ステータス |
|--------|------|------|----------|
| REQ-001 | TCND-001, TCND-002 | TEST-001, TEST-002 | カバー済 |
| REQ-002 | - | - | **未対応** |
| REQ-003 | TCND-003 | TEST-003 | カバー済 |
未対応 = REQに紐づくTCND/TESTがない → 抜け確定TESTのみ存在 = REQ紐づきなし → 探索テストか不要かを判断仕様変更時に再発しないための運用。
requirements.md: 要求一覧（REQ-xxx）+ 不明点・仮定models/: 5つのモデル（Feature tree、状態、データ、外部IF、リスク）coverage-criteria.md: このプロジェクトのカバレッジ基準test-conditions.md: テスト条件ツリー（TCND-xxx）audit-report.md: 監査結果（抜け候補と対応）test-cases.md: テスト項目一覧（TEST-xxx）traceability.md: 要求↔テスト対応表references/model-templates.md: モデル化テンプレートreferences/coverage-criteria.md: カバレッジ基準詳細references/audit-checklist.md: 監査チェックリスト/eld-ground verify も参照可能