Skip to main content

Master Checklist Template

Source: .agents/references/implementation/master-checklist-template.md

Content​

Master Checklist Template

The master checklist must exist in both:

  • The live chat/task tracker.
  • A temporary plan file under plan-docs/<feature>-master-checklist.md.

The temporary file exists for resumability only. It is deleted after all tasks pass and integration completes unless the user asks to keep it.

Allowed Statuses​

  • planned
  • blocked
  • in-progress
  • implementation-done
  • qa-failed
  • review-failed
  • passed
  • merged

Checklist Format​

Use this exact shape for every task:

## Master Checklist

- [ ] Task ID:
  - Title:
  - Owner:
  - Worktree:
  - Branch:
  - Env files: copied | skipped-no-source-env | not-needed
  - Status: planned | blocked | in-progress | implementation-done | qa-failed | review-failed | passed | merged
  - Requirement:
  - Acceptance criteria:
  - Files likely affected:
  - Write scope:
  - Dependencies:
  - Conflict responsibility:
  - Context references:
  - Tests/checks:
  - QA result:
  - Code review result:
  - Retry count:
  - Notes:

Task Breakdown Rules​

  • Each task must be small enough for one owner to complete independently.
  • Each task must have a clear write scope.
  • Tasks likely to edit the same files must be merged or explicitly ordered.
  • Prefer dependency order over maximum parallelism when file ownership is uncertain.
  • Every task with a newly created worktree must record whether .env and .env.* files were copied from the source checkout or skipped because none existed.
  • Keep task IDs stable across retries.
  • Increment Retry count after every failed QA or code review loop.

Dependency Section​

The checklist file must also include:

## Dependencies

- Task ordering:
- Shared files:
- Lark channel link: provided | skipped | not-applicable
- External/API dependencies:
- API integration mode: provided | ui-only | blocked | not-applicable
- UI-only exclusions:
- Conflict ownership:
- Feature references loaded:
- Coding standards loaded:
- Risks:

Completion Rules​

  • Mark a task implementation-done only after the worker reports changed files and tests/checks.
  • Mark a task passed only after QA and code review both pass.
  • Mark a task merged only after the passed work is integrated into the final branch/worktree.
  • Never delete failed feedback from the checklist; append updated results.
  • A task with unresolved or incorrectly resolved conflicts cannot be marked passed.