Work Decomposition

Analyze finely; dispatch coherently. Keep each task small enough that its owner can understand, perform and verify it without keeping several largely separate problems in mind. Ten concerns may need three tasks, or one broad concern may need several. Task count is not the goal: too many fragments add handoffs; oversized tasks cause repeated reading, lost context and expensive retries.

This skill proposes work groups and dependency/coordination facts for the project's delivery plan; it does not require a planner agent, scheduler, or plugin. Ordinary implementation choices remain within implementation scope. Accepted product meaning, design, architecture, constraints, and exclusions remain inputs: ask their decision owner about unresolved meaning, and do not hide a changed promise inside an implementation task. A decision update needs authorization and a named owner, not just a writable requirements file.

1. Discover the work before drawing task lines

Start from outcomes and guarantees, not a file list. Inventory mandatory requirements, rules that must remain true, agreed scenarios, interfaces, and exclusions. Use these questions only when they change the work:

• Capability: what distinct outcomes must become true?
• Ownership: which module or responsibility naturally owns each concern?
• Boundary: where do data, control, permissions, state, evidence, or failures cross between components? What must both sides agree on?
• Composition: which user-visible outcomes need several real product-owned parts? Record which groups together enable each scenario; a scenario is not automatically another task.
• Change surface: inspect current producers, consumers, schemas, configuration, generated sources, tests, and documentation relevant to the outcome. Ground paths and resources in current inspection; mark guesses [unverified]. Include shared databases, test ports, caches, and indexes.
• Preservation: what must stay true during rollout and afterward? Check migration, compatibility, safety, and recovery where they matter.

Read-only discovery can extend beyond likely write paths. A likely change surface is not proof that no other consumer matters, nor permission to edit outside scope. Inspect important neighbors before handing off executable work. Request the smallest needed write scope through the host's normal process. Planning-only work may leave exact paths unresolved when the uncertainty and discovery owner are clear.