Playbook

---
name: playbook
description: "作業の種類（不具合の修正、機能の追加・変更、リファクタリング、性能の改善、調査）ごとの手順書。作業の重さを決めた直後に、当てはまる手順書を読んで、その順に進める。'このバグを直して'、'不具合'、'機能を追加して'、'リファクタリングしたい'、'遅い'、'速くして'、'/playbook'で使う。"
---

# 作業の種類ごとの手順書

作業の重さ（E/0/1/2/R）は、承認と文書がどこまで要るかを決める。この手順書は、何をどの順に行うかを決める。2つは別に判断する。

## 手順書の選び方

| 作業の種類 | 手順書 |
|---|---|
| 報告された不具合を再現し、原因を突き止めて直す。原因の診断だけの依頼も含む | [`playbooks/bug-fix.md`](playbooks/bug-fix.md) |
| 振る舞いを新しく足す、または変える | [`playbooks/feature.md`](playbooks/feature.md) |
| 振る舞いを変えずに構造を変える（名前の変更、抽出、統合、移動） | [`playbooks/refactoring.md`](playbooks/refactoring.md) |
| 計測できる遅さや重さを改善する。原因の診断だけの依頼も含む | [`playbooks/perf.md`](playbooks/perf.md) |
| コードを変えずに、仕組み、経緯、選択肢を調べる | [`playbooks/investigation.md`](playbooks/investigation.md) |

当てはまるものがなければ、手順書を使わずに進める。1つの依頼に種類が混ざる場合（リファクタリング中に不具合が見つかったなど）は、混ぜずに報告し、別の作業として扱う。

## 作業の重さとの関係

| レベル | 流れ |
|---|---|
| E、0 | 手順書を使わない |
| 1 | レベルを記録する → 手順書を読む → 読み取りだけの手順（再現と原因の特定、仕組みの確認）を行う → `spec`の短い契約を示す → 残りの手順 |
| 2 | レベルを記録する → 手順書を読む → 読み取りだけの手順と設計の下書きを行う → `spec`で仕様書を書く → 承認を待つ → 残りの手順 |
| R | `spike-rebuild`を使い、この手順書は使わない |

読み取りだけの手順は、契約より先に行う。再現して原因が分かるまで、何を直すかと受け入れ条件が決まらないためである。契約や承認の前に行う再現は、`.tmp/evidence/<task>/`のスクリプトでできる範囲を先に使う。作業ツリーのコードにログや計測を足した場合は一時的なものとし、契約を示す前に戻して、何を足して何が分かったかを報告する。`git bisect`のようにHEADを動かす操作は、未コミットの変更がないことを確かめてから行い、終わったら元のブランチに戻す。レベルを決める前にこのスキルが読み込まれた場合は、先にレベルを決める。

## 共通の約束

- 手順書の手順を、Todoの先頭にそのまま写す。やらない手順は消さず、`skip: <理由>`を付けて残す。
- 手順は自分で順に行う。サブエージェントや複数のモデルは、ユーザーが明示した場合だけ使う。
- 再現や確認に使うスクリプトは`.tmp/evidence/<task>/`に置き、リポジトリには入れない。新しいテストは`[test]`の条件だけにする（`spec`）。
- 証拠は`~/.claude/references/evidence.md`の形式で残す。
- 手順書は手順を決めるだけで、承認、証拠、Gitの規則はCLAUDE.mdに従う。