blueprint-discovery

ブループリントの検出

ブループリントのワークフローのステップ 1～5（アイデアの具体化、調査判断シグナル、インタビューの判断、受け入れ条件の収集、機能の分類）を処理します。

入力

feature_description: string  # Raw feature description from user

1. アイデアの具体化

詳細な検出に入る前に、簡単に内容を確認します。的を絞った質問を 1～3 個行い、早い段階で誤解を解消します。

次の場合に開始します：

• feature_description が 100 文字未満
• 不確かさを示す表現を含む：「たぶん」、「おそらく」、「～のようなもの」、「～だと思います」、「よくわかりません」
• 中核となる要素が不足している：明確な動詞、または明確な主語がない

次の場合はスキップします：

• 説明が詳細である（明確な意図があり、200 文字を超える）
• ユーザーが「続けて」または「具体化をスキップ」と言っている
• 再現手順のあるバグ修正

開始する場合：

AskUserQuestion:
  question: "Quick check - what's the primary goal?"
  header: "Goal"
  options:
    - label: "Add new capability"
      description: "Feature that doesn't exist yet"
    - label: "Fix broken behavior"
      description: "Something that should work but doesn't"
    - label: "Improve existing feature"
      description: "Enhancement to current functionality"
    - label: "Refactor/cleanup"
      description: "Better code without behavior change"

フォローアップ（回答から不足点がわかった場合）：

If goal == "Add new capability":
  AskUserQuestion:
    question: "Who will use this and when?"
    header: "Context"
    options:
      - label: "End users in the app"
      - label: "Admins/internal team"
      - label: "Developers/API consumers"
      - label: "Automated systems"

If goal == "Fix broken behavior":
  AskUserQuestion:
    question: "How does it fail?"
    header: "Symptom"
    options:
      - label: "Error/crash"
      - label: "Wrong output"
      - label: "Missing data"
      - label: "Performance issue"

質問は合計 3 個までです。 具体化の後：

refined_description = original + goal + context/symptom (if asked)

スキップの選択肢を提示します：

「承知しました：{refined_description}。このまま進めますか、それともさらに詳しく確認しますか？」

2. 調査判断シグナル

具体化の際に、blueprint-research で調査の要否を判断するためのシグナルを集めます。

会話から推測します：

シグナル	検出方法
user_familiarity	既存コードの例を挙げているか？ファイルの場所を把握しているか？ → high
user_intent	「すぐ直したい」、「今日中に出す」 → speed ／「正しく仕上げたい」、「まず調査したい」 → thoroughness
topic_risk	キーワード：auth、payment、stripe、security、encrypt、API key、webhook → high
uncertainty_level	「方法がわからない」、「最善の方法は何か」、選択肢を検討している → high

シグナルが不明確な場合は、簡単に確認します：

AskUserQuestion:
  question: "What matters more for this task?"
  header: "Priority"
  options:
    - label: "Get it done fast"
      description: "Good enough solution, ship quickly"
    - label: "Get it done right"
      description: "Research best practices first"

調査フェーズ用にシグナルを保存します。

3. インタビューの判断

次の場合はインタビューを提案します：

• 機能の説明が 2 文未満
• 不確かさを示す語句を含む：「たぶん」、「おそらく」、「～のようなもの」、「よくわかりません」
• 複数の関係者またはシステムが関わる
• ユーザーが迷っている様子がある

次の場合はインタビューをスキップします：

• 明確な再現手順のあるバグ修正
• 小規模で明確に定義されたタスク（対象ファイルが 3 個未満と見込まれる）
• 既存の仕様書／PRD が参照されている機能

インタビューを提案する場合：

AskUserQuestion:
  question: "This feature could benefit from a requirements interview. Explore in depth first?"
  options:
    - "Yes, interview me first" → Invoke /interview with feature_description
    - "No, proceed to planning" → Continue

4. 受け入れ条件

必須：「完了」とは何を意味するか尋ねます。

受け入れ条件（AC）では、機能の動作のみを記述します。品質ゲート（テスト、lint、レビュー）はほかのエージェントが処理します。

AskUserQuestion:
  question: "What behavior must work for this feature to be done?"
  header: "Done when"
  multiSelect: true
  options:
    - label: "User can perform action"
      description: "Feature enables a specific user action"
    - label: "System responds correctly"
      description: "API/backend behaves as expected"
    - label: "UI displays properly"
      description: "Visual elements render correctly"
    - label: "Data is persisted"
      description: "Changes are saved to database"

適切な AC の例：

• 「認証済みユーザーがログインでき、ダッシュボードにリダイレクトされる」
• 「フォームは送信前にメールアドレスの形式を検証する」
• 「存在しないリソースに対して API が 404 を返す」

適切でない AC の例（ほかで処理）：

• 「テストが通る」→ always-works-verifier
• 「コードがレビュー済み」→ quality-gate
• 「lint エラーがない」→ slop-remover

各条件の検証方法を記録します：

条件	検証方法
ユーザーがログインできる	curl -X POST /login または手動
フォームが検証する	rspec spec/features/signup_spec.rb
API が 404 を返す	curl /api/nonexistent

5. 機能の分類

種類	検出キーワード	アクション
UI	page、component、form、button、modal、design、view、template	デザインシステムを確認
DevOps	terraform、ansible、infrastructure、cloud、docker、deploy、server	devops-plan に委任
API	endpoint、route、controller、request、response、REST、GraphQL	標準フロー
Data	migration、model、schema、database、query	標準フロー

UI 機能のフロー：

1. 設定を読み込みます：config_read("design_system_path")
2. 空の場合は、docs/design/design-system.md を確認します
3. デザインシステムがない場合は、最初に Skill("ux-brief") を提案します

DevOps 機能のフロー：

Skill(skill: "majestic-devops:devops-plan")

6. リポジトリの分析（オンボーディング時のコンテキスト）

不慣れなコードベースで作業する場合は、機能の計画を立てる前に、構造に関するコンテキストを収集します。

調査領域

領域	確認項目
アーキテクチャ	ARCHITECTURE.md、README.md、CONTRIBUTING.md、CLAUDE.md、AGENTS.md
Issue／PR のパターン	.github/PULL_REQUEST_TEMPLATE*、.github/ISSUE_TEMPLATE/
貢献ガイドライン	コーディング標準、テスト要件、レビュー手順
コードベースのパターン	命名規則、モジュールの境界、実装パターン

構造解析ツール

• テキスト検索だけでは不十分な場合は、Bash 経由で ast-grep を使用して構文を考慮した構造マッチングを行います。

  ast-grep --pattern 'class $NAME < ApplicationRecord' --lang ruby
  

• 複数の情報源にわたって発見事項を照合します
• 推測したパターンより公式ドキュメントを優先します
• 不整合やドキュメントの不足を記録します

リポジトリ分析の出力

## Repository Research Summary

### Architecture & Structure
- Project organization and tech stack
- Key architectural decisions

### Conventions
- Issue/PR formatting and labels
- Coding standards and testing requirements

### Implementation Patterns
- Common code patterns and naming conventions
- Project-specific practices

### Recommendations
- How to align with project conventions
- Areas needing clarification

出力

discovery_result:
  refined_description: string  # Original + refinement context
  refinement_skipped: boolean
  interview_conducted: boolean
  interview_output: string | null  # If interview was run
  acceptance_criteria:
    - criterion: string
      verification: string
  feature_type: "ui" | "devops" | "api" | "data" | "general"
  design_system_path: string | null  # For UI features
  # Research decision signals (for blueprint-research)
  user_familiarity: high | medium | low
  user_intent: speed | thoroughness
  topic_risk: high | medium | low
  uncertainty_level: high | medium | low
  ready_for_research: boolean