fracture

Competitive Problem Decomposition. Spawns N independent agents, each proposing a DIFFERENT decomposition of a problem into subproblems using a distinct structural lens. One decomposes by user journey, another by data flow, another by failure domain, another by team boundary, another by deployment unit. Synthesizes into a comparison of decomposition strategies with convergence analysis and a recommended framing.

Arguments

$ARGUMENTS — format: [N] [path/to/problem.md or inline description] where N is optional decomposition-lens count (default: 5, min 3, max 7)

Parse Arguments

Extract:

• agent_count: the optional leading integer (default 5, min 3, max 7)
• input: path to a problem description, design document, PRD, or feature spec — or an inline problem description

If the input is missing or unclear, ask the user to clarify before proceeding.

Phase 1: Frame the Problem

If a file path is given: read it and extract the key goals, constraints, stakeholders, technical context, and scope.

If inline: parse the problem description.

Prepare a problem brief that includes:

• What the problem is (1-2 sentences)
• Who the stakeholders are
• Known constraints (technical, organizational, timeline)
• Current assumptions
• Scale expectations (users, data volume, team size)
• What "solved" looks like (success criteria)

Present the problem brief to the user and confirm before proceeding. Adjust if the user gives feedback.

Phase 2: Spawn Decomposition Agents

Launch all N agents in parallel using the Agent tool. Each agent gets the same problem brief and a unique decomposition lens — a structural perspective through which to break the problem apart.

Standard Decomposition Lenses

Select N from the following (rotate starting selection across invocations to avoid bias; always include a mix of user-facing and system-facing lenses):

1. User Journey Decomposition — break the problem along the paths users take. Each subproblem corresponds to a distinct user goal, workflow, or interaction sequence. Boundaries fall where the user's mental model shifts.
2. Data Flow Decomposition — break the problem along how data moves. Each subproblem owns a stage: ingestion, transformation, storage, retrieval, presentation. Boundaries fall where data changes shape or crosses a trust boundary.
3. Failure Domain Decomposition — break the problem along what can break independently. Each subproblem is a blast radius — a component whose failure should not cascade. Boundaries fall where you want isolation.
4. Team Boundary Decomposition — break the problem along who owns what. Each subproblem maps to a team or role with clear ownership, interface contracts, and independent release cycles. Boundaries fall where communication overhead should be minimized.
5. Deployment Unit Decomposition — break the problem along what ships independently. Each subproblem is a deployable artifact with its own lifecycle, scaling profile, and rollback boundary. Boundaries fall where release cadences differ.
6. API Surface Decomposition — break the problem along the contracts between components. Each subproblem is defined by the interfaces it exposes and consumes. Boundaries fall where you want stability and backward compatibility.
7. Temporal/Lifecycle Decomposition — break the problem along when things happen. Each subproblem owns a phase: setup, steady-state, migration, scaling, deprecation. Boundaries fall where the system's behavior fundamentally changes over time.