Scope Festina Lente Task

<purpose> 技術的な決定に焦点を当てた反復的な会話型 Q&A を通じて機能仕様書を作成し、その後 Scoped に移行します。 </purpose> <context> <note> - **`.claude/skills/festina-*/`** — インストール済みの festina スキル — 読み取り専用 - **`.festinalente/`** — プロジェクトデータと設定 — 読み取り/書き込み - **`.festinalente/tasks/{id}/`** — `task.xml`、`spec.xml`、`plan.xml` を含むタスクフォルダ - **`.festinalente/quick/{id}/`** — `quick.xml` を含むクイックタスクフォルダ (/festina-quick 用) - **`.festinalente/scripts/`** — festina 操作用ヘルパースクリプト - **`.festinalente/templates/`** — ドキュメントテンプレート - **`.festinalente/workflow.yaml`** — ワークフロー設定 (列、ラベル、遷移) - **`.festinalente/directives/`** — ユーザー定義ディレクティブ (スキル用カスタム指示) </note>

<note>これらのスクリプトを使用してファイルを確実に検索します:</note>

<command description="ID でタスクを検索 (パスとメタデータを含む JSON を返す)">node .festinalente/scripts/festinalente.cjs find-task {id}</command>

<command description="現在の日時を取得 (iso と date 形式を含む JSON を返す)">node .festinalente/scripts/festinalente.cjs get-date-time</command>

<command description="スキル設定を取得 (ディレクティブを含む JSON を返す)">node .festinalente/scripts/festinalente.cjs get-skill-config {skill}</command> <example_code lang="json"> { "skill": "festina-check", "directives": [ { "name": "code-review", "path": ".festinalente/directives/code-review.xml", "exists": true } ] } </example_code>

<command description="プロジェクト ID でプロジェクトを検索 (パス、id、title、status、taskCount を含む JSON を返す)">node .festinalente/scripts/festinalente.cjs find-project {id}</command>

<command description="タスクのプロジェクト内の兄弟タスクを取得 (コンパクト JSON: projectId, projectTitle, siblings[])">node .festinalente/scripts/festinalente.cjs get-project-siblings {task-id}</command>

<note>これらのスクリプトを使用して製品ドキュメントを操作します:</note>

<command description="キーワードで製品ドキュメントを検索 (関連度順にソートされた JSON を返す)">node .festinalente/scripts/festinalente.cjs search-product keyword1 keyword2 ...</command> <command description="最小スコア閾値付き">node .festinalente/scripts/festinalente.cjs search-product password reset --min-score=0.3</command> <note>スコア解釈: ≥0.5 = 強いマッチ | 0.3-0.5 = 可能性のあるマッチ | <0.3 = 弱いマッチ | 結果なし = おそらく新機能</note>

<note>パスルール: ID auth/login → パス .festinalente/product/auth/login.md</note>

<note>これらのスクリプトを使用してエンジニアリングドキュメントを操作します:</note>

<command description="キーワードでエンジニアリングドキュメントを検索 (関連度順にソートされた JSON を返す)">node .festinalente/scripts/festinalente.cjs search-engineering keyword1 keyword2 ...</command> <command description="最小スコア閾値付き">node .festinalente/scripts/festinalente.cjs search-engineering middleware pattern --min-score=0.3</command> <note>スコア解釈: ≥0.5 = 強いマッチ | 0.3-0.5 = 可能性のあるマッチ | <0.3 = 弱いマッチ | 結果なし = おそらく新しいパターン/システム</note>

<note>パスルール:

• overview → .festinalente/engineering/overview.md
• systems/auth → .festinalente/engineering/systems/auth/_index.md
• systems/auth/validator → .festinalente/engineering/systems/auth/validator.md
• patterns/acyclic-arch → .festinalente/engineering/patterns/acyclic-arch.md
• conventions/file-naming → .festinalente/engineering/conventions/file-naming.md </note>

<note>列遷移: backlog → scoped</note> <note>列定義と有効な遷移については .festinalente/workflow.yaml を参照してください</note> </context>

<prohibited> - Q&A ダイアログの前にコードベース調査をスキップしないこと - 既存パターンを理解せずに仕様書を作成しないこと </prohibited> <process> <step name="load_workflow"> <action>列定義、ラベル、優先度、遷移について `.festinalente/workflow.yaml` を読み取ります</action> <note>このスキル全体でこれらの値を使用します</note> </step> <step name="get_task_id" outputs="taskId"> <branch condition="$ARGUMENTS が提供されている"> <action>$ARGUMENTS を taskId として使用します</action> </branch> <branch condition="$ARGUMENTS が提供されていない"> <action>`.festinalente/tasks/` から `backlog` ステータスのタスクを一覧表示します</action> <action>AskUserQuestion ツールを以下のように使用します: - header: "Task" - question: "どのタスクをスコープしたいですか?" - options: タスク一覧から構築 (最も関連性の高い最大 4 つのタスク)、各タスクに: - label: "{taskId}: {短いタイトル}" (必要に応じてタイトルを切り詰め) - description: "優先度: {priority} | {説明の最初の ~50 文字}" - multiSelect: false </action> <note>ユーザーは「その他」を選択してタスク ID を直接入力できます</note> </branch> </step> <step name="read_task_file" outputs="taskPath, title, acceptanceCriteria, status, affects, engineering"> <command>node .festinalente/scripts/festinalente.cjs find-task {taskId}</command> <action>JSON 出力の `path` からファイルを読み取ります</action> <action>XML を解析します</action> <validate>ステータスが `backlog` であることを確認します</validate> <branch condition="ステータスが backlog ではない"> <output>タスクは {status} ステータスです。期待値: backlog。</output> <action>AskUserQuestion ツールを以下のように使用します: - header: "続行しますか?" - question: "タスクは {status} ステータスです。それでもスコープを続行しますか?" - options: - label: "はい", description: "予期しないステータスにもかかわらずスコープを進めます" - label: "いいえ", description: "キャンセルしてタスクステータスを最初に確認します" - multiSelect: false </action> </branch> <action>問題、価値、受け入れ基準、affects、engineering フィールドを参照用に抽出します</action> <branch condition="タスクが見つからない"> <output>エラー: タスクが見つかりません</output> <action>終了します</action> </branch> </step> <step name="load_project_context" outputs="projectContext, siblingTasks" when="タスクに空でない project-id 属性がある"> <note>AC-D7: このステップは、タスクがプロジェクトに属する場合にのみ実行されます。スタンドアロンタスクの場合は完全にスキップしてください。</note>

<branch condition="タスクに空でない project-id 属性がある">
  <command description="親プロジェクトを検索">node .festinalente/scripts/festinalente.cjs find-project {project-id}</command>
  <action>返されたパスのプロジェクト.xml ファイルを読み取り、より大きな目標、要件、スコープを理解します</action>
  <action>後で追跡可能性のためにプロジェクト要件リストを保存します (AC-D4)</action>

  <command description="兄弟タスクを取得 (コンパクトデータ、AC-D6)">node .festinalente/scripts/festinalente.cjs get-project-siblings {taskId}</command>
  <action>兄弟タスクリストを保存: 各兄弟の id、title、status、description</action>
  <action>プロジェクト内の他のタスクが処理する内容を認識できます (AC-D3)</action>

  <output_variable>projectContext: {
    projectId: {project-id},
    projectTitle: {project.xml からのタイトル},
    projectGoal: {project.xml からの目標},
    projectRequirements: [{id, text} から project.xml 要件],
    projectScope: {project.xml からのスコープ}
  }</output_variable>
  <output_variable>siblingTasks: [{id, title, status, description}]</output_variable>
</branch>

<branch condition="タスクに project-id がないか project-id が空">
  <action>スキップ — スタンドアロンタスク、プロジェクトコンテキスト不要 (AC-D7)</action>
</branch>

</step> <step name="load_directives"> <command>node .festinalente/scripts/festinalente.cjs get-skill-config festina-scope</command> <action>JSON 出力を解析します</action>

<branch condition="directives.length > 0">
  <warning>ディレクティブは必須です。それに従わなければなりません。</warning>
  <action>`exists` が `true` である各ディレクティブについて:</action>
  <action>`path` の ディレクティブ XML ファイルを読み取ります</action>
  <action>以下を解析して適用します:</action>
  <action>- `<context>` 原則: 継続的な考え方として維持します</action>
  <note>`context` 原則の `keywords` 属性は LLM 関連性のためのメタデータです — キーワードを使用して原則が現在の作業に適用される時期を認識します。</note>
  <action>- `<process>` ルール (phase 属性が、カンマで分割され、トリミングされ、exact 要素として「scope」を含む場合) — 例: phase="plan,implement" は「plan」と「implement」に一致しますが「plan-review」には一致しません: 要件として従います</action>
  <action>- `<override>` セクション (phase 属性が、カンマで分割され、トリミングされ、exact 要素として「scope」を含む場合): ステップ置換を適用します</action>
  <action>- `<verification>` コマンド: /festina-plan がタスク &lt;verify&gt; 要素を生成するために使用し、/festina-implement がステップチェックを実行するために使用します。他のスキルはこのセクションを無視できます。</action>

  <branch condition="ディレクティブに phase=scope の <override> セクションがある">
    <output>
**ディレクティブ上書きがアクティブ: {directive.name}**

以下のスキルステップが、このディレクティブによって置換されます:

{各 &lt;skip&gt; 要素について:}
**ステップをスキップ: `{step}`** — このステップに到達したときは、このステップを実行しないでください。

**置換:** 代わりにディレクティブルール {override.instead.rules} を実行します。

**理由:** {override.reason}

**重要:** スキルの &lt;process&gt; 内のスキップされたステップに到達したときは、
それを完全にスキップして、代わりにディレクティブの置換ルールに従わなければなりません。
    </output>
  </branch>
  <note>`<validation>` チェックは directive_compliance ステップで実行されます</note>
  <note>`<examples>` は違反が見つかった場合に表示されます</note>
  <note>ディレクティブは config.yaml 配列順でロードされます。ロードされたすべてのディレクティブからの一致するすべての phase ルールが加算的に適用されます。同じ phase をオーバーライドする 2 つのディレクティブをマッピングするのを避けてください。</note>
</branch>

<example_code lang="json">
{
  "skill": "festina-scope",
  "directives": [
    { "name": "architecture", "path": ".festinalente/directives/architecture.xml", "exists": true }
  ]
}
</example_code>

</step> <step name="detect_brownfield" outputs="specFormat"> <note>タスクが既存の製品ドキュメントに影響を与える (brownfield) か、完全に新しい (greenfield) かを検出します。</note>

<branch condition="タスクに製品ドキュメント参照を含む affects フィールドがある">
  <action>影響を受けた製品ドキュメントのいずれかが存在し、実質的なコンテンツ (スタブではない) を含むかどうかを確認します</action>
  <branch condition="既存の非スタブ製品ドキュメントが見つかった">
    <action>specFormat = "delta" を設定します</action>
    <output>Brownfield 変更を検出 (affects: {影響を受けたドキュメント ID のリスト})。delta 仕様形式を使用しています。</output>
  </branch>
  <branch condition="すべての影響を受けたドキュメントがスタブまたはない">
    <action>specFormat = "full" を設定します</action>
    <output>影響を受けたドキュメントはスタブまたは見つかりません。完全な仕様形式を使用しています。</output>
  </branch>
</branch>

<branch condition="タスクに affects フィールドがない">
  <action>specFormat = "full" を設定します</action>
</branch>

</step> <step name="run_reconnaissance" outputs="reconFindings"> <note>常に最初に偵察を実行 — 深さの決定前に参照ドキュメントを読みます</note> <note>偵察はメインコンテキストで実行されます (エージェントではなく)。サブエージェントはサブエージェントを生成できないため</note>

<action name="read_product_context">
  <branch condition="タスクに `affects` フィールドがある">
    <action>各 ID について、`.festinalente/product/{id}.md` を読み取ります</action>
    <action>抽出: 現在の動作、制約、ユーザーフロー、機能の相互作用</action>
  </branch>
</action>

<action name="read_engineering_context">
  <branch condition="タスクに `engineering` フィールドがある">
    <action>各 ID について、ID からパスルールを使用してエンジニアリングドキュメントを読み取ります</action>
    <action>抽出: 従うべきパターン、規約、システムの相互作用</action>
  </branch>
</action>

<action name="identify_focus_areas">
  <action>読み取ったドキュメントに基づいて、より深く探索する必要がある領域を決定します:</action>
  <action>- 製品ドキュメントが存在する場合: productFocus = {docIds, keyTerms, relatedFeatures}</action>
  <action>- エンジニアリングドキュメントが存在する場合: engineeringFocus = {patterns, fileRefs, systemBoundaries}</action>
</action>

<branch condition="affects がなく、エンジニアリングドキュメントも読み取られていない">
  <note>フォールバック: タスクコンテンツからフォーカス領域を抽出します</note>
  <action>タスクのタイトル、説明、受け入れ基準からキーワードを抽出します</action>
  <action>Grep を使用してキーワードに基づいて関連ファイルを検索します</action>
  <action>grep 結果から初期 focusAreas を構築します</action>
</branch>

<output_variable>reconFindings: {
  productContext: {読み取ったドキュメント、主な洞察},
  engineeringContext: {見つかったパターン、ファイル参照},
  focusAreas: [{area, reason, grepPatterns, filePaths}]
}</output_variable>

</step> <step name="recommend_depth" outputs="researchDepth"> <note>偵察の結果を評価し、Quick または Deep 調査の深さを推奨します</note>

<action name="assess_signals">
  <note>偵察から観察可能な信号を評価します:</note>
  <action>影響を受ける可能性のあるファイル数をカウント (focusAreas ファイルパスと grep 結果から)</action>
  <action>触れられる個別のシステム/モジュール数をカウント</action>
  <action>パターン明確度を評価 (既存パターンは明白か不明確か?)</action>
  <action>横断的な関心事を確認 (変更は複数のドメインにまたがるか?)</action>
</action>

<action name="determine_recommendation">
  <note>以下の場合は Quick を推奨します:</note>
  <action>- 影響を受けるファイル数が少ない (1-3 個) 単一のモジュール/システム内</action>
  <action>- パターンが明白である (特定のファイル:行参照が見つかった)</action>
  <action>- 横断的な関心事がない</action>
  <action>- タスク説明は偵察だけから十分に理解できている</action>

  <note>以下の場合は Deep を推奨します:</note>
  <action>- 影響を受けるファイル数が多い (4 個以上) または複数のシステム/モジュール</action>
  <action>- パターンが不明確である (参照実装が見つからない)</action>
  <action>- 横断的な関心事がある (変更は auth + UI + API など複数にまたがる)</action>
  <action>- 変更の広い表面積または不慣れなコードベース領域</action>
</action>

<action>researchDepth = {recommended} を設定します</action>
<output>偵察に基づいて、{Quick|Deep} 調査を使用しています。理由: {見つかった信号の 1-2 文の要約}。</output>

</step> <step name="structured_research" outputs="researchFindings"> <branch condition="researchDepth が 'Quick'"> <note>順序付き調査 - より高速、より少ないトークン</note>

  <substep name="research_product_context">
    <note>偵察は既に影響を受けた製品ドキュメントを読み取っています。追加ドキュメントのみを検索します。</note>
    <action>reconFindings にまだ含まれていない追加の関連製品ドキュメントを検索します</action>
    <command>node .festinalente/scripts/festinalente.cjs search-product {タイトルと説明からのキーワード}</command>
    <note>検索結果には、関連ドキュメントの tldr プレビューを含む `relatedDocs` が含まれています。

関連ドキュメントの完全なコンテンツを読み取るのは、それらの tldr がこのタスクへの関連性を示唆する場合のみです。 コンテキストウィンドウを保存するために、2-3 個以下の関連ドキュメントの読み込みを避けます。</note> <branch condition="reconFindings.productContext にまだ含まれていないスコア ≥ 0.3 のドキュメントが見つかった"> <action>偵察中に既に読み取られていない上位マッチを読み取ります</action> </branch> <output_variable>productFindings: reconFindings.productContext + 追加ドキュメント</output_variable> </substep>

  <substep name="research_engineering_patterns">
    <note>偵察は既に参照されたエンジニアリングドキュメントを読み取っています。追加パターンのみを検索します。</note>
    <action>reconFindings にまだ含まれていない追加の関連エンジニアリングドキュメントを検索します</action>
    <command>node .festinalente/scripts/festinalente.cjs search-engineering {技術キーワード}</command>
    <note>検索結果には、関連ドキュメントの tldr プレビューを含む `relatedDocs` が含まれています。

関連ドキュメントの完全なコンテンツを読み取るのは、それらの tldr がこのタスクへの関連性を示唆する場合のみです。 コンテキストウィンドウを保存するために、2-3 個以下の関連ドキュメントの読み込みを避けます。</note> <branch condition="reconFindings.engineeringContext にまだ含まれていないスコア ≥ 0.3 のドキュメントが見つかった"> <action>偵察中に既に読み取られていない上位マッチを読み取ります</action> </branch> <output_variable>engineeringFindings: reconFindings.engineeringContext + 追加パターン</output_variable> </substep>

  <substep name="research_codebase_architecture">
    <note>参照として使用するための同様の実装を見つけます。</note>
    <action>タスク説明に基づいて影響を受ける可能性のあるファイルを検索するために Glob を使用します</action>
    <action>Grep を使用して同様の実装、関連関数、タイプを検索します</action>
    <action>既存パターンをファイル:行参照で理解するために主要ファイルを読み取ります</action>
    <output_variable>codebaseFindings: {component, filePath, relevance} のリスト</output_variable>
  </substep>

  <substep name="research_pitfalls">
    <note>回避すべき既知の問題と制約を特定します。</note>
    <action>影響を受ける領域でエラーハンドリングパターンを検索します</action>
    <action>関連するコードで TODO/FIXME/HACK コメントを探します</action>
    <action>記述されている制約またはエッジケースについてエンジニアリングドキュメントを確認します</action>

    <note>見つかった各ピットフォールを分類します:</note>
    <action>各ピットフォールについて、カテゴリを決定します:
      - "decision": 複数の有効なアプローチが存在、トレードオフが関係、ユーザーの選好が重要
      - "fyi": 唯一の合理的なアプローチ、明白/標準的な軽減策、認識すべき制約</action>
    <action>"decision" ピットフォール: 提案された軽減オプション 2-4 個を生成します</action>
    <action>"fyi" ピットフォール: 単一の推奨軽減策を提供します</action>

    <output_variable>pitfallFindings: {issue, impact, category, suggestedMitigations[]} のリスト</output_variable>
  </substep>
</branch>

<branch condition="researchDepth が 'Deep'">
  <substep name="determine_agents">
    <note>偵察結果に基づいて必要なエージェントのみを生成します</note>
    <action>agentsToSpawn = []</action>

    <branch condition="reconFindings.focusAreas に製品関連領域が含まれているか、製品ドキュメントが読み取られていない">
      <action>Product Context Researcher をagentsToSpawn に追加します</action>
    </branch>

    <branch condition="reconFindings.focusAreas にエンジニアリング関連領域が含まれているか、エンジニアリングドキュメントが読み取られていない">
      <action>Pattern Finder をagentsToSpawn に追加します</action>
    </branch>

    <branch condition="reconFindings.focusAreas にコードベース関連領域が含まれている">
      <action>Codebase Analyzer をagentsToSpawn に追加します</action>
      <note>実装作業が必要な場合は常に含めます</note>
    </branch>

    <branch condition="常に">
      <action>Pitfall Detector をagentsToSpawn に追加します</action>
      <note>ピットフォール検出は常に価値がありますが、フォーカスされたスコープを持ちます</note>
    </branch>

    <branch condition="agentsToSpawn が空">
      <note>エッジケース: 偵察がすべてを見つけた、エージェント不要</note>
      <action>synthesize_research ステップにスキップ、偵察結果のみを使用します</action>
    </branch>
  </substep>

  <note>**重要: Task ツールを使用して、選択されたエージェントを並列にスポーンします**</note>
  <action>1 つのメッセージで Task ツールを agentsToSpawn のエージェントに使用して並列性を実現します</action>

  <parallel>
    <agent name="Product Context Researcher" subagent_type="Explore">
      <description>製品ドキュメントと制約を検索</description>
      <prompt>

タスク用に製品コンテキストを調査: "{title}"

偵察コンテキスト (ここから開始): {reconFindings.productContext.summary} 既に読み取ったドキュメント: {reconFindings.productContext.docs}

焦点を当てる: {製品関連の各 focusArea について:}

• {area}: {grepPatterns} を検索、{filePaths} のようなファイルを確認

タスク詳細:

• 問題: {problem}
• 価値: {value}
• 受け入れ基準: {acceptanceCriteria}

あなたの仕事:

1. 偵察で既に読み取られていない追加の製品ドキュメントを検索します
2. 上で特定された領域に焦点を当てます
3. 現在の動作、制約、ユーザーフロー、機能の相互作用を特定します

見つかった関連ドキュメントごとに、以下を提供します:

• docId: ドキュメント ID
• keyInsight: このドキュメントがタスクとどのように関連するか (1-2 文)
• constraints: これが実装に課す制約

構造化されたリストとして出力します。 </prompt> </agent>

    <agent name="Pattern Finder" subagent_type="Explore">
      <description>従うべきエンジニアリングパターンを検索</description>
      <prompt>

タスク用にエンジニアリングパターンを検索: "{title}"

偵察コンテキスト (ここから開始): {reconFindings.engineeringContext.summary} 既に読み取ったドキュメント: {reconFindings.engineeringContext.docs}

焦点を当てる: {エンジニアリング関連の各 focusArea について:}

• {area}: {fileRefs} のパターンを確認、{patterns} を探索

タスク詳細:

• 問題: {problem}
• 価値: {value}

あなたの仕事:

1. 偵察で既に見つかっていない追加のエンジニアリングパターンを検索します
2. 上で特定された領域に焦点を当てます
3. 従う確立されたパターンと規約を見つけます

見つかった各パターンについて、以下を提供します:

• pattern: パターンの名前
• description: それが何を行い、このタスクにどのように適用されるか
• reference: ファイルパスと行番号 (例: src/utils/api.ts:42)
• usage: このパターンをタスクに適用する方法

構造化されたリストとして出力します。 </prompt> </agent>

    <agent name="Codebase Analyzer" subagent_type="Explore">
      <description>同様の実装を検索</description>
      <prompt>

タスク用にコードベースを分析: "{title}"

偵察コンテキスト (ここから開始): {reconFindings.engineeringContext.fileReferences}

焦点を当てる: {コードベース関連の各 focusArea について:}

• {area}: {filePaths} を調査、{grepPatterns} を grep

タスク詳細:

• 問題: {problem}
• 価値: {value}
• 受け入れ基準: {acceptanceCriteria}

あなたの仕事:

1. 偵察コンテキストのファイル参照から開始します
2. Glob を使用して偵察フォーカス領域に基づいて関連ファイルを検索します
3. Grep を使用して同様の実装を検索します
4. 既存パターンを理解するために主要ファイルを読み取ります

見つかった各項目について、以下を提供します:

• component: コンポーネント/機能の名前
• filePath: 完全なファイルパス
• relevance: これがなぜ関連しているか (1-2 文)
• pattern: これが実演するパターン (ファイル:行参照付き)

また、次の概要を提供します:

• 修正する可能性のあるファイル
• 作成する可能性のあるファイル
• 理解するべき主要な関数/タイプ

構造化されたリストとして出力します。 </prompt> </agent>

    <agent name="Pitfall Detector" subagent_type="Explore">
      <description>既知の問題と制約を検索</description>
      <prompt>

タスク用にピットフォールと制約を検索: "{title}"

偵察コンテキスト (ここから開始): 読み取った製品ドキュメント: {reconFindings.productContext.docs} 読み取ったエンジニアリングドキュメント: {reconFindings.engineeringContext.docs}

焦点を当てる: {各 focusArea について:}

• {area}: {filePaths} でピットフォールを確認

タスク詳細:

• 問題: {problem}
• 価値: {value}
• 受け入れ基準: {acceptanceCriteria}

あなたの仕事:

1. 偵察で特定された領域に焦点を当てます。コードベース全体ではありません
2. フォーカス領域でエラーハンドリングパターンを検索します
3. 関連するコードで TODO/FIXME/HACK コメントを探します
4. 同様の実装でエッジケースまたは既知の問題を確認します

見つかった各ピットフォールについて、以下を提供します:

• issue: 問題は何か
• location: 見つかった場所 (ファイル:行またはドキュメント参照)
• impact: このタスクにとってなぜ重要か
• category: "decision" または "fyi"
  • "decision" を使用する場合: 複数の有効なアプローチが存在、トレードオフが関係、ユーザーの選好が重要
  • "fyi" を使用する場合: 唯一の合理的なアプローチ、明白/標準的な軽減策
• suggestedMitigations: アプローチの配列
  • "decision" の場合: ユーザーが選択できる 2-4 個のオプションを提供します
  • "fyi" の場合: 単一の推奨軽減策を提供します

構造化されたリストとして出力します。 </prompt> </agent> </parallel>

  <action>選択されたエージェントが完了するのを待ちます</action>
</branch>

</step> <step name="synthesize_research" outputs="synthesis"> <note>すべての調査結果を構造化された概要に統合します。</note> <note>実行前にユーザーに承認を求めるために提示します。Q&A に進む前に。</note>

<branch condition="researchDepth が 'Deep'">
  <action>reconFindings をベースコンテキストとして含めます</action>
  <action>スポーンされたエージェントの出力を組み合わせます (4 つすべてではなく、必要なもののみ)</action>
  <action>偵察でカバーされたが、エージェントがスポーンされなかった領域の場合: 偵察結果を直接使用します</action>
  <action>重複する結果を削除します (同じファイル/パターンが偵察とエージェントで言及される)</action>
  <action>これらのルールを使用して競合を解決します:</action>
  <rule>偵察とエージェントが同じ領域を特定した場合、エージェントの詳細な結果を優先します</rule>
  <rule>Product Context と Codebase Analyzer が異なる影響を受ける領域を特定した場合、両方を含めます</rule>
  <rule>Pattern Finder と Codebase Analyzer が同じパターンを見つけた場合、Pattern Finder の説明を使用します</rule>
  <rule>Pitfall Detector が他のエージェントと矛盾する場合、未解決の問題としてフラグを立てます</rule>
</branch>

<branch condition="researchDepth が 'Quick'">
  <action>reconFindings をベースコンテキストとして含めます</action>
  <action>すべてのシーケンシャル調査サブステップからの結果を統合します</action>
</branch>

<output>

調査の統合

製品コンテキスト

{読み取られた各製品ドキュメントと、このタスクへの主な洞察を列挙します}

• {docId}: {主な洞察 - このドキュメントがこのタスクとどのように関連するか}

エンジニアリングパターン

{従うべき見つかったパターンを列挙します}

• {pattern-name}: {どのように適用されるか} — リファレンス: {file}:{line}

コードベースアーキテクチャ

{見つかった同様の実装を列挙します}

• {component/feature}: {file} — {このタスクに関連するそれが行うこと}

ピットフォール & 制約

決定が必要 (次にこれらについて説明します): {各ピットフォール (カテゴリが "decision"):}

• {issue}: {impact}

参考までに (標準的な軽減策が適用されます): {各ピットフォール (カテゴリが "fyi"):}

• {issue}: {impact} → {mitigation}

{decision が必要なピットフォールがない場合、そのセクションを省略} {fyi ピットフォールがない場合、そのセクションを省略}

</output>

<action>AskUserQuestion ツールを以下のように使用します:
  - header: "統合"
  - question: "この調査の統合は完全に見えますか?"
  - options:
    - label: "完全に見えます (推奨)", description: "ピットフォールを解決して技術 Q&A に進みます"
    - label: "製品ドキュメントを探索", description: "追加の製品ドキュメントを調査します"
    - label: "コードベースを探索", description: "より多くのコードパターンまたは実装を分析します"
    - label: "ピットフォールを探索", description: "追加のリスク或は制約を特定します"
  - multiSelect: false
</action>
<note>ユーザーは「その他」を選択して、探索する具体的な領域を説明できます</note>

<branch condition="ユーザーが 'Looks complete' を選択">
  <action>統合を仕様に含めるために保存します</action>
  <action>resolve_pitfalls ステップに進みます</action>
</branch>
<branch condition="ユーザーが探索オプションを選択するか、カスタムインプットを提供">
  <action>要求された領域で追加調査を実施します</action>
  <action>統合を更新して再度提示します</action>
</branch>

</step> <step name="update_doc_links"> <note>調査コンテキストを使用して doc インパクトを再評価します。調査で新たに発見されたドキュメントを task.xml に自動追加します。 このステップにより、affects/engineering フィールドが、CREATE が推測したのではなく、scope が学習したことを反映することが確認されます。</note>

<action>調査結果、機能要件、調査中に発見された影響を受けるファイルからキーワードを抽出します</action>
<command>node .festinalente/scripts/festinalente.cjs search-product {キーワード}</command>
<command>node .festinalente/scripts/festinalente.cjs search-engineering {キーワード}</command>

<action>検索結果を現在の task.xml affects/engineering フィールドと比較します</action>

<branch condition="新しいドキュメントが見つかった (スコア >= 0.5) で、まだ affects/engineering に含まれていない">
  <action>新しいドキュメント ID を task.xml affects/engineering に追加 (既存エントリを保持、重複なし)</action>
  <action>更新された task.xml をディスクに書き込みます</action>
  <output>Scope は調査結果に基づいて {doc-ids} を affects に追加しました</output>
</branch>

<branch condition="新しいドキュメントが見つからない">
  <note>サイレント通過 — 既存の affects/engineering リストは既に完全です</note>
</branch>

</step> <step name="resolve_pitfalls" outputs="resolvedPitfalls"> <note>"decision" として分類された各ピットフォールについて、ユーザーにそれを処理する方法を質問します。</note> <note>festina-rework と festina-create で使用された構造化 AskUserQuestion パターンに従います。</note>

<branch condition="decision が必要なピットフォールが存在しない">
  <output>特定されたすべてのピットフォールに標準的な軽減策があります。技術 Q&A に進んでいます。</output>
  <action>resolvedPitfalls にすべての fyi ピットフォールをそれらの軽減策と共に追加します</action>
</branch>

<branch condition="decision が必要なピットフォールが存在">
  <output>

ピットフォールを解決

複数の有効なアプローチを持つピットフォールを処理する方法を決定しましょう。 </output>

  <action>カテゴリが "decision" であるピットフォール毎に:</action>

  <action>AskUserQuestion ツールを以下のように使用します:
    - header: "ピットフォール"
    - question: "{issue} — {impact}。これをどのように処理すべきでしょうか?"
    - options: suggestedMitigations (2-4 個のオプション) から構築、各オプションに:
      - label: 短い行動フレーズ (例: "ロックを使用", "リスクを受け入れ", "再試行ロジックを追加")
      - description: このアプローチが意味することと、そのトレードオフのより詳細な説明
    - multiSelect: false
  </action>
  <note>ユーザーは「その他」を選択してカスタム軽減策を入力できます</note>

  <action>ユーザーの選択を記録: {issue, chosenMitigation, source: "user"}</action>
</branch>

<action>カテゴリが "fyi" であるピットフォール毎に:</action>
<action>標準軽減策を含んで記録: {issue, mitigation, source: "standard"}</action>

<output>

ピットフォール決定が記録されました

{解決された各ピットフォール毎に:}

• {issue}: {chosenMitigation}

技術 Q&A に進んでいます。標準軽減策に関する懸念があれば、そこで提起できます。 </output> </step>

<step name="conduct_qa_dialogue"> <note>**一度に 1 つの質問** に AskUserQuestion ツールを使用します。</note>

<note>これは、**技術的な決定** に焦点を当てた **会話的なセッション**です:

• アーキテクチャと手法

• 従うべき既存パターン

• 依存関係とライブラリ

• 技術的制約

• 修正/作成するファイル</note>

  <note>FYI ピットフォール: ユーザーは、以前に「参考までに」として表示されたピットフォールについて議論したい場合があります。 ユーザーが標準軽減策について懸念を提起した場合、代替案を議論して resolvedPitfalls を更新します。 Q&A フェーズは、Q&A フェーズ中に行われた想定を変更する自然な場所です。</note>

  <note>提案しましょう、尋ねません。

• コンテキストから決定を推測します

• 理由を示して解を提案します: 「X をここに配置すると、Y だからです。それでいいですか?」

• コンテキストが解決しない真の曖昧さがある場合のみ尋ねます</note>

  <note>ダイアログがどのように機能するか:</note> <action>コードベース分析で見つけたものを提示します</action>

  <note>ユーザーはいつでも情報を提供できます:

• ユーザーはテクノロジー指示を提供できます (例: "Zustand を使用", "React Query を使用")

• ユーザーは調査をリクエストできます (例: "React 用のリアクティブ localStorage パッケージを調査")

• ユーザーはアーキテクチャ設定または制約を共有できます</note>

  <note>技術的な決定の質問: タスクに関連する場合に質問します (すべてが適用されるわけではありません)。</note> <questions name="technical_decisions"> <action>AskUserQuestion ツールを以下のように使用します: - header: "アプローチ" - question: "見つけた {existing pattern} を見つけました。このアプローチに従うべき、それとも異なる選好がありますか?" - options: - label: "既存を従う", description: "見つけたパターンを使用" - label: "異なるアプローチ", description: "別のアイデアがあります" - label: "スキップ", description: "次の質問に移ります" - multiSelect: false </action> <note>ユーザーは「その他」を選択して、優先されるアプローチを説明できます</note>

  <action>AskUserQuestion ツールを以下のように使用します:
    - header: "ファイル"
    - question: "タスクに基づいて、これらのファイルを修正/作成すると思います: {list}。これは正しく見えますか?"
    - options:
      - label: "はい", description: "ファイルリストは正しい"
      - label: "ファイルを追加", description: "追加ファイルを含める"
      - label: "スキップ", description: "次の質問に移ります"
    - multiSelect: false
  </action>
  <note>ユーザーは「その他」を選択して異なるファイルを指定できます</note>
  <note>このリストから製品ドキュメント (.festinalente/product/) とエンジニアリングドキュメント (.festinalente/engineering/) を除外します — これらは、タスクの affects/engineering フィールドを使用して /festina-finalize によって更新されます (フェーズ 2: ドキュメンテーション)。実装中ではなく。</note>
  
  <action>調査結果から依存関係を推測します。出力決定として述べます:
    - 見つかった依存関係の場合: "依存関係: {調査から推測されたリスト}"
    - 見つからない場合: "依存関係: なし特定"</action>
  
  <action>調査中に見つかったパターンを自動含めます。出力決定として述べます:
    - "パターン: {パターンリスト} を調査から従って"
    - パターンが見つからない場合: "パターン: コードベースで見つかった"</action>
  
  <action>調査結果とピットフォールから制約を推測します。出力決定として述べます:
    - 見つかった制約の場合: "制約: {調査/ピットフォールからのリスト}"
    - 見つからない場合: "制約: なし特定"</action>
  
  <note>境界は明示的には質問されません — ユーザーが Q&A 中に境界を提供したり、タスクノートで指定したい場合は、それを行うことができます。</note>
  <branch condition="ユーザーが Q&A 中に自発的に境界を提供">
    <action>境界を 3 つのカテゴリに分類します:
      - always: エージェントが尋ねずに常に行うべきこと (例: "テストを実行", "既存 API を保存")
      - ask-first: 続行する前にユーザーの承認が必要なこと (例: "パブリックインターフェースを変更", "共有設定を変更")
      - never: エージェントが超えてはいけないハードストップ (例: "ユーザーデータを削除", "認証ロジックを変更")
    </action>
  </branch>
  

  </questions>

  <note>必要に応じて、有益な場合に調査を実施します:</note>

  <note>ローカルコードベース調査:</note> <action>トピックが出現すると、Glob/Grep を使用してパターンを検索します</action> <action>既存実装を理解するためにファイルを読み取ります</action>

  <note>Web 調査:</note> <branch condition="ユーザーがパッケージ/ライブラリの調査をリクエスト"> <action>WebSearch を使用して npm パッケージ、ドキュメント、ベストプラクティスを調査します</action> <action>オプションを比較して結果を提示します</action> <action>AskUserQuestion ツールを以下のように使用します: - header: "結果" - question: "これらの結果があなたのアプローチに影響を与えますか?" - options: - label: "はい", description: "結果に基づいてアプローチを調整" - label: "いいえ", description: "元のアプローチを保持" - multiSelect: false </action> <note>ユーザーは「その他」を選択して、結果がアプローチにどのように影響するかを説明できます</note> </branch>

  <action>完全な機能仕様書を書くために十分な情報が得られるまで続行します</action>

  <output>概要: アプローチ: {概要}, キーファイル: {list}, 依存関係: {list}, パターン: {概要}。仕様作成を進んでいます。</output> <action>仕様書へ進みます</action>

  <note>主な原則:

• 技術的な決定に焦点を当てます。製品要件ではなく (それはタスクにあります)

• トピックが出現すると調査します。最初の後ではなく

• 会話を自然に流れさせます

• 急がないでください - 今の徹底性が実装中に時間を節約します</note> </step>

  <step name="derive_contracts" outputs="contractsList"> <note>オプションで、集約された要件から動作契約 (前提条件、事後条件、不変量) を派生させます。</note> <branch condition="contracts ディレクティブがロードされている"> <note>FR11: contracts ディレクティブがアクティブな場合、契約派生は必須です — 評価をスキップして、契約派生に直接進みます。</note> <action>deriveContracts を true に設定します</action> </branch> <branch condition="contracts ディレクティブがロードされていない"> <action>集約された要件をチェックして、契約が価値を追加するかどうかを評価します: - 要件は入力/出力、状態遷移、または副作用を持つ動作を説明していますか? - または、コンテンツの変更、設定、またはテキスト編集を説明していますか? </action>

  <branch condition="要件がコンテンツ/設定/テキスト変更のみを説明 (例: テンプレートを編集、プロンプトを更新、設定を変更、ドキュメントを追加)">
    <action>契約を完全にスキップ — 質問なし</action>
    <output>contractsList — 空 (コンテンツ/設定タスク、契約は適用不可)</output>
  </branch>
  
  <branch condition="要件が動作上の関心事を説明 (例: 入力を処理、状態を管理、並列作業を調整、データを検証、結果を永続化、外部サービスを呼び出す)">
    <action>AskUserQuestion ツールを以下のように使用します:
      - header: "契約"
      - question: "このタスクには動作要件が関係しています ({見つかった関連する関心事のリスト})。事前条件、事後条件、不変量を明確にするために契約を派生させることをお勧めします。契約を派生させますか?"
      - options:
        - label: "はい (推奨)"
          description: "動作要件の契約を派生させ"
        - label: "いいえ"
          description: "契約をスキップ"
      - multiSelect: false
    </action>
  </branch>
  
  <branch condition="不確実 —混合シグナルまたは不明確">
    <action>AskUserQuestion ツールを以下のように使用します:
      - header: "契約"
      - question: "要件から動作契約 (事前条件、事後条件、不変量) を派生させたいですか?"
      - options:
        - label: "はい"
          description: "各機能要件の契約を派生させ"
        - label: "いいえ"
          description: "契約をスキップ"
      - multiSelect: false
    </action>
  </branch>
  

  </branch> <branch condition="ユーザーが 'はい' を選択または contracts ディレクティブがアクティブ"> <action>関連する機能要件をグループ化します。単一の契約が複数の FR をカバーできます (例: すべての検証 FR が同じ動作制約を共有します)。提案するのは FR ごとに 1 つではなく、論理グループごとに 1 つです。</action>

  <action>各契約グループについて:
    要件を分析して、契約要素を提案します:
    - precondition: 前に true である必要があるもの
    - postcondition: 後に true である必要があるもの
    - invariant: 常に true である必要があるもの
    - property: 保持すべき一般的なプロパティ
  
    AskUserQuestion ツールを以下のように使用します:
    - header: "契約: {短い名前}"
    - question: "{カバーされる要件 ID}.\n以下を提案します:\n- Pre: {提案された事前条件}\n- Post: {提案された事後条件}\n- Invariant: {提案された不変量}\n- Property: {提案されたプロパティ}"
    - options:
      - label: "提案を受け入れる"
        description: "提案された契約要素をそのまま使用"
      - label: "変更"
        description: "これらの契約要素を調整したい"
    - multiSelect: false
  </action>
  <note>ユーザーは「その他」を選択して、完全にカスタムな契約要素を入力できます</note>
  
  <action>応答から契約要素を構築:
    - id: C1, C2, ... (順序付け)
    - requirement: カバーされた FR への参照 (FR1, FR2, ...)
    - name: 契約の短い