/mdtask-do — Task workflow

Use the mdtask CLI to find and read tasks — don't hand-scan the Markdown files to discover or reason about them. Run mdtask list / mdtask view <ID> (add --json for machine-readable output); open the Markdown only after the CLI points you at the exact task and file. Invoke it as mdtask <command>, or a project-defined wrapper such as pnpm mdtask <command> if the project sets one.

Flow

Gate — do this before reading any further. Your first action is to materialize the steps below as a live, checkable list and tick items off as you go (you'll confirm against it before the commit in Step 8). The tracked artifact is mandatory; the mechanism is whatever your harness offers — a task-list tool, a scratch ./tmp markdown checklist, or, if nothing else, the same checklist written into your visible reply. (For example: in Claude, the task tools — ToolSearch for select:TaskCreate,TaskUpdate, then TaskCreate one item per step; in Pi, a ./tmp markdown file.) The steps: Pick, Plan, Review plan, Execute, Behavior check, Review code, Final validation, Update spec, Commit. Don't summarize them in prose as a substitute; create the tracked list, then go straight into Step 1.

One checklist per run. Before creating this run's items, check (TaskList) for a checklist left by a previous task in this session. If there is none, or every item in it is closed, clear it and start fresh. If it still has open (unfinished) items, the rule depends on how you're running: interactively (the user is present and hasn't told you to act independently, here or in standing instructions) → STOP and ask the user what to do with them — never wipe someone's in-progress work; autonomously (the user set independent / loop operation in instructions or chat) → there's no one to ask, so just clear all of them and start fresh, don't block the loop.

Modes

normal (default) — full cycle, autonomous: pick the most logical task and approve your own plan.
fast (fast, --fast, -f) — skip planning, both review steps, test-first work, the behavior check, and final validation. Still pick the task with the CLI, make the change, update the task and spec, and — when the project commits task changes — commit unless told not to.

#noqa tag — if the picked task carries #noqa, skip the two review steps (Step 3 and Step 5). Everything else, including the behavior check and commit, still runs.

Task boundaries

Do only the work required for the result of the current task.