---
name: zen-tasks
description: Convert an agreed specification into small demonstrable tasks with dependencies, acceptance, context and review evidence. Use to prepare work for owner-selected execution.
---
# Zen tasks

Make the specification executable without losing its scope. A task should demonstrate a useful behavior, not merely create one technical layer.

1. Read the current spec/decisions, existing tasks and exact selected artifacts. Search for duplicates and check their actual state before creating new work. Carry unresolved decisions forward visibly.
2. Partition into vertical slices with explicit dependencies. Separate independent tasks only where their contracts are stable. Map every spec criterion to one or more tasks; keep integration, documentation, migration and real acceptance represented.
3. Write each task's outcome, brief, type, priority, acceptance criteria, allowed files/worktree context, dependencies, checks and expected review report. Resolve material owner decisions using the [shared decide-and-ask guidance](../zen/SKILL.md#decide-and-ask); do not ask for discoverable repository facts. Include relevant applied FDK/MEM and why they apply, not the whole history.
4. Use TSK and backlog. Put `kind`, `priority`, `baseRef`, `acceptanceCriteria`, structured `checkCommands` and timezone in data, and dependency/spec/research/selection relationships in links. For manager plans, also use role and `dependsOn` task IDs in task data; reviewer/qa use `targetTaskId`. Plan-local dependencies use refs until approval maps them to IDs. See [the task template and payload](references/output.md). Use discovered UUIDs rather than guessing refs.
5. Keep CLI/model/effort unset if the owner has not selected them. A saved task selection is authoritative for that task/schedule; do not substitute another provider/model or repeatedly ask at dispatch. Record unsupported effort/image/continuation explicitly. Readiness/blockers can be recorded in body/data, but the current runtime does not enforce a readiness field: do not claim an advisory note itself prevents dispatch.
6. Persist through `zen_record_write` record.create with one stable operation key per intent. On retries use the identical request/key; on conflicts re-read. For file-only capture use the [standalone writer](../zen/references/standalone.md). With neither, give numbered draft tasks without fabricated TSK references.
7. Report the dependency order, criterion coverage, ready versus blocked tasks and the next owner action. Ordinary task-agent MCP cannot launch or schedule a run: a backlog task is not execution evidence. If schedules are configured elsewhere, retain UTC instant plus selected timezone and assigned device.

## Done means ready to execute

Check that each slice can be demonstrated, dependencies resolve and checks are appropriate to its risk. Include a final integration slice if independent unit checks cannot prove the whole flow. Avoid ritual tests for reversible edits and tests that merely repeat the implementation.

For every behavioral feature, name a repeatable scripted verification path tied to its acceptance criteria: reuse an existing test/harness or create a meaningful one where warranted. Record exactly how to run it and what evidence it produces. If a check cannot be automated or a tiny non-behavioral change needs no new test, state the reason and the actual alternative; never invent a passing script.

Example: “Submit a browser edit, persist one local revision and display its acknowledgement” is a vertical slice. Separate “create table,” “make button,” and “write client” tasks are insufficient unless their shared acceptance is covered. Successful execution later finishes in Review, with Done controlled by the owner.