Task List

Create or update exactly:

• tasks.md in the same directory as the provided spec.md

This is a task-list command for an existing spec, not research-only and not implementation.

By default, write a full task list that covers the complete spec. Only write a partial task list when the user explicitly asks for a limited scope.

Input

The prompt must provide a path to changes/<feature-name>/<NUMBER-idea-name>/spec.md.

If no spec path is provided, ask one focused question for the path. If the path is not an existing spec.md file, stop and report it.

Context To Read

1. Read the provided spec.md fully before writing tasks.
2. Read relevant code, tests, exports, docs, and guidelines needed to identify affected packages and likely implementation areas.
   • Always include root guidelines/code.md or guidelines/test.md, plus nested guidelines/code.md or guidelines/test.md files for directories likely to change.
   • Respect package boundaries: public APIs export from src/index.ts; downstream internal pqb access goes through pqb/internal.
3. If tasks.md exists in the same folder, read it first, preserve still-correct tasks, remove stale tasks, and reconcile it with final spec.md.

tasks.md

Output path: same directory as the provided spec.md.

If it exists, read it first, preserve still-correct tasks, remove stale tasks, and reconcile it with final spec.md.

The file must start with this section before any package or docs work:

## 0. read spec.md and guidelines

- 0.1 Read `spec.md`, including `spec.md` `## Detailed Design`, before starting any later task. Follow that design for every later task, and make sure the final implementation matches it exactly.
- 0.2 Check whether any later task you were prompted to do requires coding. If yes, read and follow every guideline below for that work, and verify that all produced code follows them to the letter.

- you must follow guidelines/code.md or guidelines/test.md for coding
- you must follow <relevant-nested-path>/guidelines/code.md or <relevant-nested-path>/guidelines/test.md for coding

Section 0 rules:

• It contains exactly two numbered entries, 0.1 and 0.2; both are plain list items, not checkboxes.
• Guideline bullets are required supporting lines, not subtasks.
• Include root guidelines/code.md or guidelines/test.md and every relevant nested guidelines/code.md or guidelines/test.md for directories the implementation will change.

After section 0, only these sections are valid:

• affected package sections, ordered by dependency: lower-level packages before downstream packages
• for full task lists only, optional docs section, only for repo-root docs/ work, placed after package work
• for full task lists only, final changeset section with the next number and one non-coding task that follows .agents/skills/changeset/SKILL.md

Package section names must be package folder names or root package script names. For schema config work, use zod and/or valibot, never schema-configs or schemaConfigs. Keep package-local docs in the relevant package section.

Every implementation checkbox task after section 0:

• is a responsibility/change-slice title, not the instruction itself
• is complete only when all nested subtasks are done
• owns an indented numbered subtask list, e.g. 1.1.1, 1.1.2
• has at least one actionable subtask; do not add filler
• stays high-level, not file-by-file or helper-by-helper
• may mention likely code locations, exported functions, or docs pages when useful for orientation

If one requirement spans multiple packages, create a separate task in each affected package section. Do not create empty sections, standalone test tasks, generic research tasks, vague cleanup tasks, or exact test-writing instructions.

Every package coding task must start its subtask list with:

• <task>.1 scope: <short package area or capability class>
• <task>.2 acceptance: <high-level expected outcome>

Then add change-specific subtasks. End every coding task with these exact verification subtasks after the numeric prefix:

• verify implementation against guidelines
• code must be covered by tests
• tests and types must pass: run pnpm verify
• reconcile spec.md for every new user-visible requirement