Three-Tier Checklist Structure
The three checklist types — child task list, acceptance criteria, and Delivery Status — and which skills have the authority to check each
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 |