SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbreakdown-tasks

breakdown-tasks

Design & creation

View repository

Updated 10-16 01:35

About this skill

Skill: Break Down Tasks

Purpose

Turn a validated design document into an ordered, trackable task list. Each task has dependencies, acceptance criteria, and an assignee (or AI execution prompt) so that it can be implemented without ambiguity.

Core Objective

Task objective: Generate a task document (e.g., tasks.md) from the design document so that each implementable unit is a task with clear dependencies, acceptance criteria, and ownership.

Success criteria(all requirements must be met):

  1. ✅ Task document exists: Written to the agreed path (e.g., docs/process-management/tasks/YYYY-MM-DD-<topic>.md or project tasks.md) and committed
  2. ✅ Design traceability: Each task maps to at least one part of the design (section or acceptance criterion)
  3. ✅ Dependencies are clear: The task order or dependency list is clear (no circular dependencies)
  4. ✅ Acceptance criteria for each task: Each task has specific "done" criteria
  5. ✅ Assignee or execution prompt: Each task has an owner (person/role) or AI execution prompt (e.g., which skill or step to run)
  6. ✅ User confirmation: The user explicitly approves or adjusts the task list

AcceptanceTest: Can an executor (person or agent) use only this document and the design to choose the next task, implement it, and verify completion?

Scope Boundaries (Scope Boundaries)

This skill is responsible for：

  • Design document → ordered task list (tasks.md or equivalent)
  • Dependencies between tasks; acceptance criteria for each task; assignee or AI execution prompt
  • Persist the task list as a living product for implementation tracking

This skill is not responsible for：

  • Creating or validating the design (use "Design Solution" or "Brainstorm Design")
  • Validating requirements (use "Analyze Requirements")
  • Executing tasks (implementation techniques, running fix loops, etc.)
  • Scheduling or capacity planning (use project/milestone tools)

Handoff point: Once the task list is approved and retained, hand off to execution (e.g., run tasks in order, or enter the backlog/board).

Use Cases (Use Cases)

  • Post-design planning: The design is approved; before coding you need a clear implementation plan.
  • Traceability: You want every design decision to map to one or more concrete tasks.
  • AI-assisted execution: You want each task to include a prompt (e.g., "use skill X" or "edit file Y") so an agent can execute the plan.

Behavior (Behavior)

Interaction (Interaction) Policy

  • Default: A design document (path or content) is required; use the project specification as the output path (if present)
  • Choose option: When the design is unclear, ask one clarifying question at a time
  • Confirmation: The user must approve or adjust the task list before handoff

Phase 1: Ingest Design

  1. Load design: Read the design document (e.g., design.md or docs/design-decisions/*.md).
  2. Extract structure: Identify the parts that imply work (architecture, components, data flow, error handling, testing, etc.).
  3. Confirm scope: If the user specifies a subset (e.g., "backend only"), limit the tasks to that subset.

Phase 2: Derive tasks

  1. One task per implementable unit: Each task should be completable in one focused session; when X is large, avoid vague "implement X".
  2. Order by dependencies: List tasks so that dependencies come first; make document dependencies explicit (e.g., "depends on: T1, T2").
  3. Acceptance criteria: For each task, state what "done" looks like (testable or verifiable).
  4. Assignee or prompt: For each task, set an assignee (person/role) or an AI execution prompt (e.g., "run the design solution for module Y", "edit src/foo.ts according to design §3").

Phase 3: Persist and hand off

  1. Resolve path: Prefer project conventions (e.g., docs/ARTIFACT_NORMS.md); otherwise docs/process-management/tasks/YYYY-MM-DD-<topic>.md or project convention tasks.md。
  2. Write task document: Use a consistent format (see below); if the project uses it, include front-matter (created_by:分解任务、lifecycle:living, design source path).
  3. User approval: Present a summary and request approval or edits.
  4. Handoff: Suggest starting execution from the first unblocked task.

Input & Output

Role Content
Input Design document (path or content); optional user scope/priority
Output Task document located at docs/process-management/tasks/YYYY-MM-DD-<topic>.md or project tasks.md; each task has an ID, title, dependencies, acceptance criteria, assignee/prompt

Recommended task list format

# Implementation tasks: [Topic]

**Source design:** [path or title]
**Created:** YYYY-MM-DD

| Id | Task | Depends on | Acceptance criteria | Owner / Hint | Status |
| :--- | :--- | :--- | :--- | :--- | :--- |
| T1 | ...  | —          | ...                  | ...         | Todo   |
| T2 | ...  | T1         | ...                  | ...         | Todo   |

Status Lifecycle

This skill is only responsible for setting the initial status of all derived tasks to Todo. Downstream implementation and execution skills (such as a specific development execution agent), task board synchronization tools, or developers are responsible for maintaining and updating that status during implementation (e.g., transitioning to In Progress、Blocked、Done or Cancelled). This skill is not responsible for continuously changing task status thereafter.

Optional: Add a brief "Summary" and "Design Traceability" (task → design section) at the top.

Limits (Restrictions)

Hard Boundaries

  • Design first: Do not run when the design is missing or unapproved; hand off to "Design Solution" or "Brainstorm Design".
  • No implementation: Do not write code or run implementation techniques; only produce a task list.
  • No circular dependencies: The task order must be acyclic.

Skill Boundaries (avoid overlap)

Do not do these (other skills can handle them)：

  • Requirements analysis or validation → "Analyze Requirements"
  • Design exploration or approval →设计解决方案
  • Execute the task or fix loop → implement the skill or "run the fix loop"

Self-Check

  • The task document exists and has been committed
  • Design traceability: each task maps to at least one part of the design
  • Dependencies are clear: the task order or dependency list is clear, with no circular dependencies
  • Each task has acceptance criteria (testable or verifiable)
  • Each task has an assignee or an AI execution prompt
  • Each task is configured with an initial state (such as Todo) and is included in the table's status column
  • A task list approved or explicitly accepted by the user

Example (Example)

Example 1: Standard design-to-task workflow

Call: "We have a design in docs/design-decisions/2026-03-16-core-v1.md. Break it down into tasks."

Agent: Use the task breakdown; read the design; derive an ordered list of tasks with sections and acceptance criteria; write to docs/process-management/tasks/2026-03-16-core-v1.md; obtain user approval; suggest starting with the first task.

Example 2: Edge case — oversized design

Call: "Our platform design document is very large (multiple subsystems). For now we only need tasks for 'authentication + user onboarding'."

Agent：

  • Ask the user to confirm the intended scope subset (for example, sections 3 and 4 of the design).
  • Limit task derivation to that subset, and clearly note the scope source section in the task document.
  • Ensure that dependencies outside the scope are either captured as external prerequisite stubs or as explicit blockers.
  • Generate a task file whose first column links each task back to the specific design section used, so future runs can expand coverage without duplication.