Task Command

The contract for /task, the registry command that files maintenance work as a GitHub Issue with the task label. The command owns the elicitation flow; this page owns the actions, the body format and the labels.

What a task is

	req	bug	task
For	New product behaviour	A defect	Keeping the project healthy — a dependency bump, a security/CVE update, a runtime upgrade, a config migration, a cleanup
Definition of done	## Acceptance Criteria checklist	Reproduced failure + regression test	## Verification checklist — steps that must pass
Traces to	A parent capability (Part of #NN)	The delivered requirement it broke, when known	A trigger — an advisory ID, CVE, EOL date or release link (optional)
Parent capability	Required	Not required	Not required — a sibling of bug, never a child of cap
Filed by	/requirement	/report-bug, gh issue create --label bug	/task

Provisioning

/task is a registry command (category: governance, default: false) — provision it per project:

bob provision add command task

The task label itself is part of the standard label set, so every repo gets it whether or not the command is provisioned: scripts/bootstrap-labels.sh ensure creates or updates it (colour #0E8A8A) and is idempotent — a second run changes nothing.

Actions

Action	Does
/task create	Files a new task issue from the body template below.
/task approve <N>	Adds the approved label so the task is eligible for /warp-drive, mirroring /requirement approve.
/task list	Lists open tasks, approved first, with verified/total Verification progress.
/task view <N>	Shows one task with its verification progress and Trigger: line.

Every dated write — an EOL deadline, an approval comment — is preceded by ~/.claude/skills/timelord/scripts/now.sh.

Automation levels

Decision point	L1	L2	L3
Title / priority (if not provided)	Ask	Suggest from context, confirm	Infer, show
Verification steps	Walk through interactively	Draft from context, ask for review	Draft all, present for review
Trigger reference	Ask	Suggest from context, confirm	Infer from context (omit when none)
Workstream area	Ask	Suggest from context, confirm	Infer from context (omit when none)
Approve when ready	Ask	Confirm	Auto when verification steps are clear

Body format

## Description

{what maintenance this task performs and why it is needed now}

## Verification

- [ ] {a step that must pass}
- [ ] {a step that must pass}

## Notes

Priority: {p1-critical | p2-high | p3-medium | p4-low}
Trigger: {advisory ID, CVE, EOL date, release link — omitted when none}
{scope boundaries — or "None"}

Section	Rule
## Description	Required. One paragraph.
## Verification	Required. At least one - [ ] step, each something that can be run and observed. Progress is - [x] over total.
## Notes	Required. Priority: always; Trigger: only when something external prompted the task.
## Acceptance Criteria	Never present. A task is not a requirement.
Part of #NN	Never required. A task with no parent capability is valid.

Labels

gh issue create is invoked with:

Label	When
task	Always.
p1-critical … p4-low	Always — exactly one priority.
area:<slug>	Only when the task belongs to a workstream; omitted otherwise.
approved	Added later by /task approve, never at creation.

Related

• Tracker labels — the full label glossary, task among the work-item labels.
• /requirement — product behaviour with acceptance criteria.
• TODO Format Contract — the other issue type whose body has a fixed contract.