Design Doc And Task Board

Overview

Decide where intent, design, work state, and acceptance criteria should live so they do not drift.

Design docs explain why and how; a work-state surface tracks current tasks, statuses, acceptance criteria, and task-to-change traceability; exec plans describe how to execute a complex batch of changes. tasks.md or docs/tasks.md is the lightweight repo-local default when no reliable Jira, Linear, GitHub Issues, internal board, or equivalent tracker exists. For shared harness terms, see ../../references/harness-patterns.md; when planning files are absent, use references/build-when-missing.md.

When To Use

• The user asks whether a requirement belongs in a design doc, tasks.md, an external task system, or an exec plan.
• README, design docs, tasks, and exec plans start to duplicate or drift.
• Requirements need to become tasks, statuses, acceptance criteria, and commit-linked change records.

Inputs Needed

• Current requirement or change goal.
• Existing task tracker or tasks.md, design docs, exec plans, README, and docs index.
• Change size, cross-module scope, and whether long-term tracking is needed.