メニュー
要件の曖昧さを能動的に発見する対話的ブレインストーミングスキル。Issue Contract作成前に、Law/Term観点、境界条件、失敗モードから多角的質問を生成する。「要件を明確にして」「要件をブレストして」「要件の曖昧さをチェックして」「何が不明確か教えて」等、新機能開発の最初期（Issue Contract作成前）に使用。ELD Phase 1: Issueの前段階として自動実行される。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | eld-sense-requirements-brainstorming |
| description | 要件の曖昧さを能動的に発見する対話的ブレインストーミングスキル。Issue Contract作成前に、Law/Term観点、境界条件、失敗モードから多角的質問を生成する。「要件を明確にして」「要件をブレストして」「要件の曖昧さをチェックして」「何が不明確か教えて」等、新機能開発の最初期（Issue Contract作成前）に使用。ELD Phase 1: Issueの前段階として自動実行される。 |
要件の曖昧さを能動的に発見し、Issue Contract作成前に要件を対話的に明確化するスキル。 推測で進めるのではなく、Law/Term観点・境界条件・失敗モードから体系的に質問を生成する。
ユーザーの要求を読み、以下の質問カテゴリから最も重要な3つを選択:
質問カテゴリ:
1. Law/Term観点: 守るべき条件と語彙の定義
2. 境界条件: 入力の範囲、例外ケース、制約
3. 失敗モード: 何が壊れうるか、エラーハンドリング
4. 性能要件: レスポンスタイム、スループット、リソース制約
5. セキュリティ要件: 認証、認可、データ保護
6. 既存システムとの関係: 互換性、移行戦略、依存関係
選択基準:
選択したカテゴリごとに、具体的で答えやすい質問を生成:
質問設計パターン:
## [カテゴリ名]
### 質問1: [具体的な質問]
- なぜこれを聞くか: [Law/Term/境界のどれに関係するか]
- 例: [具体例を示して選択肢を提示]
### 質問2: [具体的な質問]
...
詳細な質問テンプレートは references/question-templates.md を参照。
ユーザーの回答から:
深掘りトリガー:
明確化した要件から Issue Contract を下書き:
Issue Contract:
目的 (Goal): [ビジネス価値と実現内容]
不変条件 (Invariants):
- [既存システムで守られている条件]
- [新規実装でも守るべき条件]
物差し (Acceptance Criteria):
- [検証可能な成功条件]
- [Evidence Ladderレベルを明記]
停止条件 (Stop Conditions):
- [予測と現実の継続的乖離]
- [観測不能な変更の増加]
- [ロールバック線の崩壊]
Law/Term候補:
Law:
- LAW-xxx: [守るべき条件の記述] (Severity: S0/S1/S2)
Term:
- TERM-yyy: [語彙の定義] (Type: Entity/Value/Context/Boundary)
未確定事項 (Open Questions):
- [まだ決まっていないこと]
- [追加調査が必要なこと]
抽出したLaw/Term候補を /eld-spec に引き継ぎ:
曖昧さは指摘して具体化を促す。例:
User: ユーザーが適切に認証されるようにして
Claude: 「適切に」の定義を明確にしたいです。
具体的には：
1. 認証方法: パスワード？OAuth？多要素認証？
2. 失敗時の挙動: リトライ回数制限は？アカウントロックは？
3. セッション管理: ログイン状態の保持期間は？
他の対話パターン（質問→回答→深掘り、境界条件の確認等）は references/dialogue-patterns.md を参照。
ユーザーの回答から以下をLaw候補として抽出:
抽出パターン:
- 「〜しなければならない」→ Invariant (S0/S1)
- 「〜の前に〜が必要」→ Precondition (S1)
- 「〜した後は〜が保証される」→ Postcondition (S1)
- 「〜してはいけない」→ Policy (S0/S1)
- 「〜の範囲内」→ Boundary constraint (S1/S2)
Severity判定:
S0: ビジネスクリティカル（違反で金銭損失/法令違反）
S1: 機能要件（違反で機能不全）
S2: 品質要件（違反で UX 低下）
抽出パターン:
- ドメイン固有の名詞 → Entity/Value Object
- 状態を表す語 → Context
- 範囲を表す語 → Boundary
例:
- "JWT トークン" → TERM-jwt-token (Value Object)
- "認証済みユーザー" → TERM-authenticated-user (Context)
- "有効期限内" → TERM-token-validity-period (Boundary)
詳細は references/law-term-discovery.md を参照。
以下をすべて満たしたら Phase 終了:
完了後、以下のスキルに引き継ぎ:
/eld-spec: Law/Term候補の詳細化・Card作成/eld-sense-planning: タスク分解（Issue Contract をもとに）デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）から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.