---
title: ステータスラベルの状態機械
description: todo→doing→review→doneの順にラベルが変わる仕組みと、誰が変えていいかのルール
seo:
  image: /ogp.png
---

`export-backlog` → `implement-backlog` → `review-issue` → `merge-issue`という4つのスキルは、
GitLab/GitHubのIssueに貼るラベル(ステータスラベル)を、共有の状態機械(状態が決まった順番で変わっていく仕組み)として使います。

```mermaid
stateDiagram-v2
  [*] --> todo
  todo --> doing: implement-backlog
  doing --> review: implement-backlog / review-issue
  review --> done: merge-issueだけ
  review --> blocked: review-issue(収束しない場合)
  done --> [*]
```

どの遷移を誰が起こせるかは、遷移ごとに決まっています。

| 遷移 | ラベルを変えるスキル | タイミング |
|---|---|---|
| `todo → doing` | `implement-backlog` | 実装に着手したとき |
| `doing → review` | `implement-backlog` / `review-issue` | `implement-backlog`は実装が終わった時点(上げられるのは`review`まで)。`review-issue`はブロッカーが0件になり、PR/MR(コードの変更をレビューしてもらうための提出)を作ったとき |
| `review → blocked` | `review-issue` | 自動修正ループが上限に達しても直らなかったとき |
| `review → done` | **`merge-issue`だけ** | 実際にPR/MRがマージされた(取り込まれた)ときだけ |

:::warning[PR/MRを作るのはreview-issue]
`implement-backlog`の仕事は、コードを書いてブランチにコミットするところまでです。PR/MRは作りません。
PR/MRを作るのは`review-issue`で、しかもブロッカーが0件になったときだけです。
「実装は終わったのにPR/MRが見当たらない」ときは、`/architect:review-issue`をまだ実行していないことが原因です。
:::

:::note[なぜimplement-backlogはdoneをセットしないのか]
実装が終わった時点で`done`にしてしまうと、まだマージされていないのに「完了した」ように見えてしまいます。
それを防ぐため、`done`に変えていいのは`merge-issue`だけと決めています。実装が終わっても、
レビューを通ってマージされるまでは`done`になりません。
:::