work-item-decompose

name	work-item-decompose
description	Break an intent into discrete, executable work items with complexity assessment and dependency validation.
version	1.0.0

Break an intent into discrete, executable work items. - Intent exists without work items - User wants to plan execution

<degrees_of_freedom> MEDIUM — Follow decomposition patterns but adapt to the specific intent. </degrees_of_freedom>

Each work item MUST be completable in a single run Each work item MUST have clear acceptance criteria Dependencies MUST be explicit and validated Read intent brief from .specs-fire/intents/{intent-id}/brief.md Understand goal, users, success criteria Break intent into discrete deliverables Each deliverable should be independently valuable

<guidelines>
  - Prefer vertical slices over horizontal layers
  - Start with foundation pieces (models, schemas)
  - End with integration pieces (API, UI)
  - Keep each item focused on ONE concern
</guidelines>

For each work item, assess RAW complexity:

<complexity level="low">
  - Single file or few files
  - Well-understood pattern
  - No external dependencies
  - Examples: bug fix, config change, simple utility
</complexity>

<complexity level="medium">
  - Multiple files
  - Standard patterns with some decisions
  - May touch existing code
  - Examples: new endpoint, new component, feature addition
</complexity>

<complexity level="high">
  - Architectural decisions required
  - Security or data implications
  - Core system changes
  - Examples: auth system, payment flow, database migration
</complexity>

Read workspace.autonomy_bias from state.yaml Apply bias to determine final execution mode:

<bias_table>
  | Raw Complexity | autonomous | balanced | controlled |
  |----------------|------------|----------|------------|
  | low            | autopilot  | autopilot| confirm    |
  | medium         | autopilot  | confirm  | validate   |
  | high           | confirm    | validate | validate   |
</bias_table>

<note>
  This allows user preference to shift thresholds:
  - autonomous: trusts AI more, fewer checkpoints
  - balanced: standard behavior (default)
  - controlled: more human oversight
</note>

For each work item, define: What must be true when complete How to verify it works Any edge cases to handle Check for circular dependencies Ensure dependencies exist or will be created first Order work items by dependency

<check if="circular dependency detected">
  <output>
    Warning: Circular dependency detected between {item-a} and {item-b}.
    Suggest splitting into smaller items or reordering.
  </output>
</check>

## Work Items for "{intent-title}"

  **Total**: {count} work items
  **Estimated**: {low} autopilot, {medium} confirm, {high} validate

  **Work Item Details**:

  {for each item}
  {n}. **{title}** ({mode}) — {description}
  {/for}

  ---

  Approve this plan? [Y/n/edit]
</output>

Create .specs-fire/intents/{intent-id}/work-items/ For each work item, generate using template: templates/work-item.md.hbs Save each to: .specs-fire/intents/{intent-id}/work-items/{work-item-id}.md Update state.yaml with work items list **{count} work items created** for "{intent-title}".

  ---

  Ready to plan execution scope? [Y/n]
</output>
<check if="response == y">
  <route_to>builder-agent (run-plan)</route_to>
</check>

<output_artifacts>

Artifact	Location	Template
Work Item	.specs-fire/intents/{intent-id}/work-items/{id}.md	./templates/work-item.md.hbs
</output_artifacts>

<success_criteria> Intent decomposed into discrete work items Each work item has clear acceptance criteria Complexity assessed for each item Autonomy bias applied to determine modes Dependencies validated (no circular dependencies) Work items saved to correct locations State.yaml updated with work items list </success_criteria>