--- 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 --- Plan the scope of a run by discovering available work items and suggesting groupings. - After work-item decomposition completes - User wants to start execution - Pending work items exist **MEDIUM** — Present smart grouping suggestions but let user choose scope. DISCOVER all available work — both in state.yaml AND file system FILE SYSTEM IS SOURCE OF TRUTH — state.yaml may be incomplete ALWAYS SCAN FILE SYSTEM — even if state.yaml shows all completed SUGGEST smart groupings based on mode, dependencies, and user history LEARN from user choices to improve future recommendations NEVER force a scope — always let user choose DEPENDENCIES = 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 | 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 | 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. Use Glob to list: .specs-fire/intents/*/brief.md Extract intent IDs from directory names Found intent directories: {list} Use Glob to list: .specs-fire/intents/*/work-items/*.md Extract work item IDs and their parent intents Found work item files: {list} Read state.yaml for known intents and work items Compare file system list against state.yaml entries **Discovered new intent**: {intent-id} (exists in file system but not in state.yaml) Parse brief.md frontmatter for intent metadata Add intent to state.yaml with status: active Scan its work-items/ folder **Discovered new work item**: {work-item-id} in {intent-id} (exists in file system but not in state.yaml) Parse work item frontmatter for metadata Add work item to state.yaml with status: pending state.yaml is authoritative for status (tracks run history). Frontmatter status may be stale from initial creation. **Status mismatch**: {work-item-id} - state.yaml: {state_status} - frontmatter: {frontmatter_status} (Using state.yaml as authoritative) Update work item frontmatter to match state.yaml Flag for review - work may have been done outside FIRE **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. Reset work item status to in_progress in state.yaml Update frontmatter to match Warning: {item} in state but file not found on disk ## 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} Filter work items with status == pending Group by intent Note mode (after autonomy_bias applied) for each Identify dependencies within and across intents No pending work items found. Create a new intent? [Y/n] planner-agent (intent-capture) Read workspace.autonomy_bias from state.yaml Read workspace.run_scope_preference from state.yaml (if exists) Dependencies = SEQUENTIAL execution in SAME run (NOT separate runs) batch mode: Group items BY mode type (autopilot together, confirm together, etc.) wide mode: ALL items in ONE run regardless of mode (executed sequentially) Cross-intent items allowed in same run if compatible Validate mode items may benefit from batch (separate run with focused checkpoints) Determine recommended option based on: autonomy_bias (autonomous→batch, controlled→single) run_scope_preference (user's historical choice) Number of pending items (few items→single is fine) ## Run Planning **Found**: {count} pending work items across {intent_count} intent(s) {for each intent with pending items} **{intent.title}**: {for each pending item} - {item.title} ({item.mode}) {/for} {/for} {if dependencies exist} **Dependencies** (determines execution order): - {dependent_item} depends on {dependency_item} {/if} --- **How would you like to execute?** **[1] One at a time** — {single_count} separate runs Most controlled, review after each run **[2] Group by mode** — {batch_run_count} run(s) {autopilot_count} autopilot items → Run A (no pauses) {confirm_count} confirm items → Run B (1 checkpoint each) {validate_count} validate items → Run C (2 checkpoints each) Less context switching per run **[3] All in one** — 1 run with all {count} items (Recommended) Execute sequentially: {item1} → {item2} → ... Pause at confirm/validate checkpoints Maximum throughput Choose [1/2/3]: run_scope = single work_items_for_run = [first_pending_item] User will re-invoke run-plan after each run completes run_scope = batch Group pending items by mode: autopilot_items = items where mode == autopilot confirm_items = items where mode == confirm validate_items = items where mode == validate Start with first non-empty group (autopilot preferred) work_items_for_run = first_mode_group_in_dependency_order After this run, user re-invokes for next mode group run_scope = wide work_items_for_run = all_pending_items_in_dependency_order All items in one run, sequential execution Update workspace.run_scope_preference in state.yaml Add to workspace.run_scope_history (keep last 10) choice: {run_scope} items_count: {count} timestamp: {now} After 3+ consistent choices, start pre-selecting that option and ask "Proceed with {preference}? [Y/n/change]" instead Starting run with {count} work item(s): {for each item in work_items_for_run} {index}. {item.title} ({item.mode}) {/for} Items will execute sequentially within this run. {if any item is confirm or validate} Checkpoints will pause for approval at confirm/validate items. {/if} --- Begin execution? [Y/n] run-execute ``` .specs-fire/ ├── intents/ │ ├── user-auth/ │ │ ├── brief.md ← Parse frontmatter for intent metadata │ │ └── work-items/ │ │ ├── login-endpoint.md ← Parse for work item metadata │ │ └── session-mgmt.md │ └── analytics/ │ ├── brief.md │ └── work-items/ │ └── dashboard.md ``` **Frontmatter parsing**: - Extract `id`, `title`, `status` from YAML frontmatter - If status missing, default to `pending` - If in file but not state.yaml, add to state ``` 1. Collect all pending items with their modes 2. Build dependency graph 3. Sort items in dependency order (dependencies first) 4. For "single" option: - Each item is its own run 5. For "batch" or "wide" option: - ALL items in ONE run - Execution order follows dependency graph - Checkpoints pause at confirm/validate items ``` ``` IF run_scope_history has 3+ same choices: pre_selected = most_common_choice ELSE IF autonomy_bias == autonomous: recommended = batch (all in one run) ELSE IF autonomy_bias == controlled: recommended = single ELSE: # balanced IF pending_count <= 2: recommended = single ELSE: recommended = batch ``` File system scanned for all intents and work items state.yaml reconciled with file system Run scope options presented to user User choice recorded for future recommendations run-execute invoked with selected work items

run-plan

Install this skill

Comments