Make the work actionable

Produce the smallest useful set of tasks that another engineer can execute. Choose the detail and decomposition from the actual work, not a required number of tasks, sections, questions, or file reads.

Author tasks

Use the brief, PRD, conversation, and relevant repository evidence to identify the outcome, dependencies, implementation anchors, and acceptance checks. Reuse existing investigation and decisions. Inspect uncertain interfaces or callers where they could change the plan; do not repeat a whole-repository survey.

Resolve routine choices from established conventions. Ask only about missing decisions that would materially change behavior, scope, security, or compatibility. If the requirements are sufficient, produce the tasks directly; there is no additional task-list approval ceremony. Follow any approval explicitly requested by the user.

Each task should make its outcome, relevant code, dependencies, and verification clear. Include risks, data/API changes, migration details, or QA steps when they affect execution. Group work that belongs together; split by dependency or independent deliverable when that makes execution easier. Do not invent adjacent features or fill irrelevant template sections.

Use the user's language and project terminology. Distinguish accepted requirements from proposals and unresolved assumptions. The result is ready when an implementer can act without rediscovering essential decisions; verbosity is not evidence of readiness.

Save only requested artifacts

Return tasks in conversation unless saving was requested. Follow the requested path or repository convention, otherwise use docs/tasks/<feature-slug>/ with an INDEX.md and task files where separate detail is useful. Preserve existing files and links; inspect a destination before creating it and do not overwrite another task set.

The index is the single delivery-status record; keep PRDs and task specifications free of duplicate mutable progress. A compact index can contain task details directly. Include task identifiers, outcomes or task links, dependencies, status, and evidence/blockers. Initialize new tasks as Pending and the summary as 0 / N done; writing a task is not implementing it.