Tasks

The Tasks step turns the design into build work. Every design component becomes an epic, every implementation unit becomes a ticket, and the agent writes each ticket's why, what, scope and an ordered list of build steps with a check for each. The result is a ticket manifest that fills the delivery board, and a readable build plan.

What you get

Two files from every successful run:

• The ticket manifest, tasks-vN.json — the structured source the board reads.
• The build plan, tasks-vN.md — a Markdown document titled Build Plan — Epics and Tickets, written entirely by the bridge from the manifest.

The build plan has the title block (project, client, version, date) and then:

Each ticket in the manifest also carries its requirement references, test-case references, acceptance criteria (copied verbatim from the SRS), a feature label, an assignee role — and an assignee name when the project has team members in that role — plus the agent's why, what, in-scope and out-of-scope text.

Tasks is not a reviewed step: there is no Approve or Request changes. The run is complete as soon as the manifest is written, and the board fills at that moment.

Before you run it

• The STS must exist. It does not need to be approved. Until it exists, /tasks is locked with "Run /sts first".
• Every design component must have at least one implementation unit. A design produced by the current SDS step always does; if yours does not, the run stops with "No implementation units on: DC-… — re-run /sds".

How it works

Tasks makes one sdlc-task-author call per design component, up to four at a time. Everything around those calls is deterministic.

Drawing diagram…

1. Scaffold

The bridge builds the manifest skeleton from the project state, with no agent involved:

• one epic per design component, with its dependencies;
• one ticket per implementation unit, in design order;
• ticket ids made from the project's initials and one running number across the whole project;
• each ticket's requirements, the test cases linked to those requirements, and the acceptance criteria;
• story points from the component's complexity — simple 3, average 5, complex 8 — shared across its units;
• an assignee role from the component's assigned role, matched to the project's team members.

2. Author, one component per call

Each call receives one component: its header and description, and its units with their type, title, description, contract, requirements, acceptance criteria and resolved test cases. For each unit it depends on — even one in another component — the call also receives that unit's contract, so the build steps can wire against what it exposes.

The skill returns, for every unit, keyed by the unit id:

• why, what, scope_in and scope_out — all required and non-empty;
• tasks — an ordered, non-empty list T1, T2 … each with a description and a verify check grounded in the unit's contract and test cases;
• optionally unit_acceptance, which may sharpen but never replace the SRS acceptance criteria.

If the agent cannot cover every unit of a component, the skill tells it to return an error for that component rather than partial work.

A failed call does not stop the others. Its component is recorded as failed and the remaining components carry on.

3. Assemble

Assembly is all or nothing. If any component failed, or any unit is missing tasks or narrative, the run fails and lists every gap — and no manifest is written. Otherwise the authored work is merged into the scaffold, validated against the manifest schema, and written.

The run panel shows: Scaffolding epics, Authoring build tickets, Assembling the manifest, Building the doc tree, Writing the Markdown document.

Ids this step owns

Epics use the design component ids (DC-NNN), and each ticket names its implementation unit (DC-NNN-MM).

Reviewing it

There is no approval, but read the build plan before you push work to a team:

• the epic dependency graph should match the order you expect to build in;
• each ticket's steps should end in something checkable — "POST /auth/login returns 401 for an unknown email", not "the endpoint works";
• scope-out text tells a developer where the ticket stops.

To change the tickets, change their source. Tasks ignores notes, so the way to reshape them is to adjust the design (request changes on the SDS or re-run it) and run /tasks again.

When it fails

A failed run keeps the components that did author successfully. The next run reuses them without calling the agent again and retries only the failed ones, so a retry after a partial failure is quicker. Once a run succeeds, that saved work is cleared. The reuse is by component id only, so if you regenerate the design between a failed run and the retry, the retry can still pick up tickets authored for the old design — in that case check the build plan closely once it succeeds.

Under the hood

• The driver is bridge/src/services/tasksPipeline.service.ts; scaffolding and assembly are bridge/sdlc-engine/scripts/sdlc/build-tasks-manifest.js.
• TASKS_AUTHOR_POOL_SIZE sets how many component calls run at once (default 4).
• The manifest is .sdlc/artifacts/tasks-vN.json, registered as artifacts.tasksManifest; the build plan is .sdlc/artifacts/tasks-vN.md, registered as artifacts.tasks. A tasks entry is added to the phase history.
• Because Tasks is never approved, its version number does not advance: each successful run replaces the manifest and build plan under the same number.
• The step also regenerates the project's docs/implementation/ tree: one file per epic and one per ticket.
• After the run, the bridge ingests the manifest into the board's tickets.