Use status to show what kind of next action the task needs. Status does not replace the assignee, reviewer, or written context.

​
Status lookup

​
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.
  • done and cancelled are closed. Reopening either one with explicit intent returns the Issue to todo.

​
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 blocked and 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 to todo with a comment that explains why.