AgentSkillsCN

eld-sense-requirements-brainstorming

主动发掘需求中的模糊之处，运用互动式头脑风暴技能。 在Issue Contract创建前，从Law/Term视角、边界条件以及失败模式出发，生成多角度的提问与思考。 触发条件： - 当您需要“明确需求”“对需求进行头脑风暴”“检查需求中的模糊之处”时； - 在新功能开发的早期阶段（Issue Contract创建前）； - 当您需要“告诉我哪些地方还不清楚”“确认前提条件”时； - 在ELD Phase 1：Issue的前置阶段自动执行。

SKILL.md
--- frontmatter
name: eld-sense-requirements-brainstorming
context: fork
description: |
  要件の曖昧さを能動的に発見する対話的ブレインストーミングスキル。
  Issue Contract作成前に、Law/Term観点、境界条件、失敗モードから多角的質問を生成。

  トリガー条件:
  - 「要件を明確にして」「要件をブレストして」「要件の曖昧さをチェックして」
  - 新機能開発の最初期（Issue Contract作成前）
  - 「何が不明確か教えて」「前提条件を確認して」
  - ELD Phase 1: Issue の前段階として自動実行

ELD Sense: Requirements Brainstorming

要件の曖昧さを能動的に発見し、Issue Contract作成前に要件を対話的に明確化するスキル。 推測で進めるのではなく、Law/Term観点・境界条件・失敗モードから体系的に質問を生成する。

核心原則

  1. •Epistemic Humility: 曖昧さを見つけたら必ず質問する。推測で埋めない
  2. •Law/Term First: 要件をLaw（守るべき条件）とTerm（語彙）の観点で整理
  3. •Failure Mode Driven: 「何が壊れうるか」から逆算して要件を明確化
  4. •Progressive Disclosure: 段階的質問で認知負荷を下げる

実行フロー

Phase 1: 初期理解と質問カテゴリ選択

ユーザーの要求を読み、以下の質問カテゴリから最も重要な3つを選択:

yaml
質問カテゴリ:
  1. Law/Term観点: 守るべき条件と語彙の定義
  2. 境界条件: 入力の範囲、例外ケース、制約
  3. 失敗モード: 何が壊れうるか、エラーハンドリング
  4. 性能要件: レスポンスタイム、スループット、リソース制約
  5. セキュリティ要件: 認証、認可、データ保護
  6. 既存システムとの関係: 互換性、移行戦略、依存関係

選択基準:

  • •ユーザーの要求で言及されていない領域を優先
  • •リスクが高い領域（セキュリティ、失敗モード）を優先
  • •曖昧さが多い領域を優先

Phase 2: 段階的質問生成

選択したカテゴリごとに、具体的で答えやすい質問を生成:

質問設計パターン:

markdown
## [カテゴリ名]

### 質問1: [具体的な質問]
- なぜこれを聞くか: [Law/Term/境界のどれに関係するか]
- 例: [具体例を示して選択肢を提示]

### 質問2: [具体的な質問]
...

詳細な質問テンプレートは references/question-templates.md を参照。

Phase 3: 回答収集と深掘り

ユーザーの回答から:

  1. •明確になった点を記録
  2. •まだ曖昧な点を特定し、追加質問
  3. •Law/Term候補を抽出

深掘りトリガー:

  • •回答が抽象的すぎる場合（「適切に」「柔軟に」など）
  • •例外ケースが不明確な場合
  • •複数の解釈が可能な場合

Phase 4: Issue Contract下書き生成

明確化した要件から Issue Contract を下書き:

yaml
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):
    - [まだ決まっていないこと]
    - [追加調査が必要なこと]

Phase 5: Law/Term候補の引き継ぎ

抽出したLaw/Term候補を /eld-model-law-discovery に引き継ぎ:

  • •Law候補: 守るべき条件（Invariant/Precondition/Postcondition/Policy）
  • •Term候補: ドメイン語彙（Entity/Value Object/Context/Boundary）

対話パターン

パターン1: 質問→回答→深掘り

code
Claude: 認証機能について3つ質問させてください。

## 1. セキュリティ要件
### トークンの有効期限はどうしますか？
- なぜこれを聞くか: LAW-token-expiry の定義に必要
- 例:
  - 短時間（15分）+ リフレッシュトークン
  - 中期間（1時間）
  - 長期間（24時間）

User: 1時間で

Claude: 了解です。では追加で：
- 1時間経過後のユーザー体験はどうしますか？
  - 自動ログアウト？
  - リフレッシュトークンで自動更新？

パターン2: 曖昧さの指摘

code
User: ユーザーが適切に認証されるようにして

Claude: 「適切に」の定義を明確にしたいです。

具体的には：
1. 認証方法: パスワード？OAuth？多要素認証？
2. 失敗時の挙動: リトライ回数制限は？アカウントロックは？
3. セッション管理: ログイン状態の保持期間は？

パターン3: 境界条件の確認

code
Claude: 境界条件を確認させてください。

## 入力の範囲
- ユーザー名: 最小/最大文字数は？使用可能文字は？
- パスワード: 複雑さ要件は？

## 例外ケース
- 既に同じメールアドレスが存在する場合は？
- ネットワークタイムアウト時は？

詳細な対話パターンは references/dialogue-patterns.md を参照。

Law/Term発見ガイドライン

Law候補の抽出パターン

ユーザーの回答から以下をLaw候補として抽出:

yaml
抽出パターン:
  - 「〜しなければならない」→ Invariant (S0/S1)
  - 「〜の前に〜が必要」→ Precondition (S1)
  - 「〜した後は〜が保証される」→ Postcondition (S1)
  - 「〜してはいけない」→ Policy (S0/S1)
  - 「〜の範囲内」→ Boundary constraint (S1/S2)

Severity判定:
  S0: ビジネスクリティカル（違反で金銭損失/法令違反）
  S1: 機能要件（違反で機能不全）
  S2: 品質要件（違反で UX 低下）

Term候補の抽出パターン

yaml
抽出パターン:
  - ドメイン固有の名詞 → 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 を参照。

品質優先原則（Superpowers統合）

核心原則

  1. •Epistemic Humility: 推測を事実として扱わない。unknownと言う勇気を持つ
  2. •Evidence First: 結論ではなく因果と証拠を中心にする
  3. •Minimal Change: 最小単位で変更し、即時検証する
  4. •Grounded Laws: Lawは検証可能・観測可能でなければならない
  5. •Source of Truth: 真実は常に現在のコード。要約はインデックス

「速さより質」の実践

  • •要件の曖昧さによる手戻りを根本から排除
  • •テストなし実装を許さない
  • •観測不能な変更を防ぐ

完了条件

以下をすべて満たしたら Phase 終了:

  • • 選択した3つの質問カテゴリすべてで質問を完了
  • • ユーザーの回答がすべて具体的（抽象語が解消されている）
  • • Issue Contract 下書きが作成済み
  • • Law/Term候補が少なくとも3つ以上抽出済み
  • • 未確定事項が明示されている

次のステップ

完了後、以下のスキルに引き継ぎ:

  1. •/eld-model-law-discovery: Law/Term候補の詳細化
  2. •/eld-sense-task-decomposition: タスク分解（Issue Contract をもとに）

リファレンス

  • •references/question-templates.md - 質問カテゴリ別テンプレート集
  • •references/dialogue-patterns.md - 対話フローパターン詳細
  • •references/law-term-discovery.md - Law/Term発見の詳細ガイド

使用例

code
User: ユーザー認証機能を追加したい

Claude: 要件を明確にするため、3つの観点で質問させてください。

## 1. Law/Term観点（守るべき条件と語彙）
### 認証方式は何を想定していますか？
- なぜこれを聞くか: TERM-authentication-method の定義と、LAW-auth-security の基準が決まります
- 例:
  - パスワードのみ
  - OAuth2.0（Google/GitHub等）
  - 多要素認証（MFA）

### トークンの有効期限はどうしますか？
- なぜこれを聞くか: LAW-token-expiry の定義に必要
- 例: 15分/1時間/24時間

## 2. 失敗モード（何が壊れうるか）
### 認証失敗時の挙動は？
- なぜこれを聞くか: LAW-failed-login-limit の定義
- 例:
  - 3回失敗でアカウントロック
  - 失敗回数の記録のみ
  - 失敗時に追加の検証（CAPTCHA等）

### セッション期限切れ時のUXは？
- なぜこれを聞くか: 境界条件とエラーハンドリングの設計
- 例:
  - 自動ログアウト
  - リフレッシュトークンで自動延長
  - 警告表示後に再ログイン要求

## 3. 既存システムとの関係
### 既存の認証機構はありますか？
- なぜこれを聞くか: 移行戦略と不変条件の確認
- 例:
  - なし（新規実装）
  - Basic認証あり（置き換え）
  - 外部プロバイダあり（統合）

どこから回答しますか？

停止条件

以下が発生したら即座に停止し、追加計測またはスコープ縮小：

  • •予測と現実の継続的乖離（想定外テスト失敗3回以上）
  • •観測不能な変更の増加（物差しで検証できない変更）
  • •ロールバック線の崩壊（戻せない変更の発生）