Subtasks, checklists and test plans

These look similar and do genuinely different jobs.

Subtasks — independently trackable work

A subtask is a real task: its own reference, status, assignee and estimate. It shares its parent's dates rather than being scheduled separately.

Use when the pieces are independently trackable — different people, different completion states, worth reporting on separately. "Build the front end" splitting into "Component library", "Page templates", "Cross-browser pass" is a good split.

Don't use just because a task is large. A big task done by one person in one go should stay one task with a longer specification. Subtasks nest one level only — deliberately, because two levels is where a task list turns into a filing system.

Marking a parent done while subtasks are still open prompts you, with the option to complete them all.

Checklists — steps to tick off

A flat list of steps on a task. No assignees, no dates, no references — just things to tick. Waymarq records who ticked each one and when.

Use when the steps aren't worth tracking as work, but you don't want to forget one: "Home / Menu / Find us / Order online", or a pre-launch list.

You can have several checklists on a task.

Test plans — how you'll verify it

A checklist of kind test plan: the same mechanics, but it answers "how do we know this is actually done?" rather than "what are the steps?". It gets its own icon, and its progress surfaces once the task is in progress or review — which is when verification actually matters.

Use when a task has an acceptance bar worth writing down. "Lighthouse scores 90+", "keyboard-only navigation works", "no horizontal scroll at 375px".

There's also a separate Test plan (for AI) field on a task — plain instructions a coding agent can run against finished code. It's for automation, not for a person to tick.

Full specification

Distinct from all three: a long-form markdown field on the task for the actual detail — requirements, edge cases, technical approach. This is where the substance of a task belongs. It renders as formatted text, and it's what someone should read before starting the work.

A good large task looks like: a couple of sentences of description, a full specification, two or three subtasks, and a short test plan.