/run-plan

name: run-plan
description: Plan the scope of a run by discovering available work items and suggesting groupings. Invoked before run-execute.
version: 1.0.0

<objective> Plan the scope of a run by discovering available work items and suggesting groupings. </objective>

<triggers>

• After work-item decomposition completes
• User wants to start execution
• Pending work items exist

</triggers>

<degrees_of_freedom> **MEDIUM** — Present smart grouping suggestions but let user choose scope. </degrees_of_freedom>

<llm critical="true"> <mandate>DISCOVER all available work — both in state.yaml AND file system</mandate> <mandate>FILE SYSTEM IS SOURCE OF TRUTH — state.yaml may be incomplete</mandate> <mandate>ALWAYS SCAN FILE SYSTEM — even if state.yaml shows all completed</mandate> <mandate>SUGGEST smart groupings based on mode, dependencies, and user history</mandate> <mandate>LEARN from user choices to improve future recommendations</mandate> <mandate>NEVER force a scope — always let user choose</mandate> <mandate>DEPENDENCIES = SEQUENTIAL EXECUTION, NOT SEPARATE RUNS</mandate> </llm>

<critical_clarifications> <clarification title="Dependencies Mean Sequential Execution, NOT Separate Runs"> When work items have dependencies:

• They execute **sequentially within the SAME run**
• They do **NOT** require separate runs
• The dependent item waits for its dependency to complete before starting

**Example**: If item 05 depends on item 04:

• **CORRECT**: ONE run with both items, 04 executes first, then 05
• **WRONG**: TWO separate runs

</clarification>

<clarification title="All Options Can Include Multiple Items Per Run"> | Option | Items Per Run | Execution | |--------|---------------|-----------| | Single | 1 item | One at a time, separate runs | | Batch | Multiple items (same mode) | Sequential within run | | Wide | All compatible items | Sequential within run | </clarification> </critical_clarifications>

<flow> <step n="1" title="Discover Available Work" critical="true"> <critical> MUST scan file system BEFORE deciding if work exists. state.yaml may be missing intents or work items that exist on disk. DO NOT skip this step even if state.yaml shows all items completed. </critical>

<substep n="1a" title="List All Intent Directories"> <action>Use Glob to list: .specs-fire/intents/*/brief.md</action> <action>Extract intent IDs from directory names</action> <output>Found intent directories: {list}</output> </substep>

<substep n="1b" title="List All Work Item Files"> <action>Use Glob to list: .specs-fire/intents/*/work-items/*.md</action> <action>Extract work item IDs and their parent intents</action> <output>Found work item files: {list}</output> </substep>

<substep n="1c" title="Compare with state.yaml"> <action>Read state.yaml for known intents and work items</action> <action>Compare file system list against state.yaml entries</action> </substep>

<substep n="1d" title="Reconcile Differences"> <check if="intent directory exists but not in state.yaml"> <output> **Discovered new intent**: {intent-id} (exists in file system but not in state.yaml) </output> <action>Parse brief.md frontmatter for intent metadata</action> <action>Add intent to state.yaml with status: active</action> <action>Scan its work-items/ folder</action> </check>

<check if="work item file exists but not in state.yaml"> <output> **Discovered new work item**: {work-item-id} in {intent-id} (exists in file system but not in state.yaml) </output> <action>Parse work item frontmatter for metadata</action> <action>Add work item to state.yaml with status: pending</action> </check>

<check if="work item exists in both but status mismatch"> <note> state.yaml is authoritative for status (tracks run history). Frontmatter status may be stale from initial creation. </note> <output> **Status mismatch**: {work-item-id}

• state.yaml: {state_status}
• frontmatter: {frontmatter_status}

(Using state.yaml as authoritative) </output> <action if="frontmatter says pending but state says completed"> Update work item frontmatter to match state.yaml </action> <action if="state says pending but frontmatter says completed"> Flag for review - work may have been done outside FIRE </action> </check>

<check if="state says completed but item is in runs.active[].work_items with current_phase != review"> <output> **Suspect completion**: {work-item-id}

• state.yaml status: completed
• But current_phase: {current_phase} (not "review")
• Item is still in active run {run-id}

Resetting to in_progress — item was likely marked complete prematurely. </output> <action>Reset work item status to in_progress in state.yaml</action> <action>Update frontmatter to match</action> </check>

<check if="in state.yaml but file missing"> <output>Warning: {item} in state but file not found on disk</output> </check> </substep>

<output>

File System Scan Complete

Intents on disk: {count} Intents in state.yaml: {count} Work items on disk: {count} Work items in state.yaml: {count}

{if new items discovered} **Newly discovered (added to state.yaml)**: {list new items} {/if} </output> </step>

<step n="2" title="Collect Pending Work Items"> <action>Filter work items with status == pending</action> <action>Group by intent</action> <action>Note mode (after autonomy_bias applied) for each</action> <action>Identify depend