Status lookup
| Status | Meaning | Typical next action |
|---|---|---|
backlog | The request still needs scope, priority, ownership, or acceptance criteria | Clarify the task |
todo | One owner can start without another decision | Assignee begins |
in_progress | The assignee is working | Produce a result |
blocked | A person, dependency, permission, or external event must happen first | Name and resolve the blocker |
in_review | A result is ready for independent judgment | Reviewer decides |
done | The result has been accepted | Create follow-up only if needed |
cancelled | The work was intentionally stopped without an accepted result | Reopen only if the work becomes relevant again |
Rules that affect the workflow
- A newly created Issue normally starts in
backlog. - Assign an Agent only after the Issue is clear enough to start.
- A named reviewer means the assignee cannot skip review and close the task as accepted.
- Accepting a review can move the Issue to
done; requesting changes returns the next action to the assignee. - A failed Run does not complete the Issue.
doneandcancelledare closed. Reopening either one with explicit intent returns the Issue totodo.
Status and ownership are separate
Changing status does not silently change the assignee. Moving an Issue to review gives the reviewer the next decision, but the implementation owner stays visible. A direct request to the current assignee or reviewer can start an Agent response without using status as a permission switch. For normal planning, use the table above: it keeps the board understandable.Examples
- The audience for a launch note is unknown: keep it in
backlog. - The brief and owner are ready: move it to
todo. - The Agent needs a product decision: use
blockedand name the decision owner. - The file exists and checks are complete: move it to
in_review. - The reviewer accepts the result: the Issue can become
done. - The request is withdrawn: move it to
cancelled. If it returns, reopen it totodowith a comment that explains why.