---
title: Three-Tier Checklist Structure
description: >-
  The three checklist types — child task list, acceptance criteria, and Delivery
  Status — and which skills have the authority to check each
seo:
  image: /ogp.png
---
Every backlog item has three types of Markdown checkboxes. None of them are decorative.
Each one represents the item's current state, displayed by GitLab/GitHub as a progress counter.

| Checklist | Location | 1 box = | Skill authorized to check |
|---|---|---|---|
| **Child task list** | Parent's description (`## Sub-Epics` on an Epic, `## Issues` on a Sub-Epic) | A child item (`- [ ] #<iid> <title>`) | `implement-backlog` (when implementation and tests are complete). `review-issue` unchecks on rejection; `merge-issue` verifies at merge time |
| **Acceptance criteria** | `## Acceptance Criteria` in the Issue body | A verifiable condition (`- [ ] <criterion>`) | `implement-backlog` (implementation confirmation) → `review-issue` (verification confirmation) |
| **Delivery Status** | `## Delivery Status` on each item | A progress stage (`Implemented` / `Reviewed` / `Merged`) | The skill that brought the item to that stage (see table below) |

The child task list and acceptance criteria represent **implementation state** — whether code has been written and tests are passing.
They do not indicate whether something has been merged. Progress through merge is tracked by `## Delivery Status`.

| Stage | Checking skill | Meaning |
|---|---|---|
| `Implemented` | `implement-backlog` | Code is committed and tests pass (all acceptance criteria checked) |
| `Reviewed` | `review-issue` | Review verdict is Mergeable and a PR/MR has been created |
| `Merged` | `merge-issue` | PR/MR has been merged and the Issue is closed |

:::warning[A checked child task list item does not mean merged]
A check in the child task list does not mean the merge is complete. `implement-backlog` checks the item at the point of
"implementation + tests complete." Conversely, if `review-issue` finds the implementation or tests insufficient,
it **unchecks** the item with a reason attached.
To determine whether something has been merged, check the `status::*` label or the `Merged` entry in `## Delivery Status`.
:::

:::note[What this convention guarantees]
Only items that have actually been verified will have a check. Checks cannot be added in advance on the basis of "planning to verify later."
`export-backlog` **always creates all three checklist types in an unchecked state.** After that, no skill is permitted to check an item simply because it is planned.
The result is a system where a checked item can be trusted to be genuinely verified.
:::