PR・コミット・差分・ファイルをレビューし、再現条件と根拠のある不具合、回帰、検証漏れを報告する。変更が差分の外で何を壊しうるか（影響範囲）を、安全の根拠をコードで証明して確かめるときにも使う。
nokonoko1203/agent-settings922026年10月22日 更新
無料GitHub で公開
playbook
作業の種類（不具合の修正、機能の追加・変更、リファクタリング、性能の改善、調査）ごとの手順書。作業の重さを決めた直後に、当てはまる手順書を読んで、その順に進める。'このバグを直して'、'不具合'、'機能を追加して'、'リファクタリングしたい'、'遅い'、'速くして'、'/playbook'で使う。
含まれるファイル（8）
- SKILL.md3.5 KB
- NOTICE.md2.5 KB
- playbooks/bug-fix.md2.5 KB
- playbooks/feature.md1.6 KB
- playbooks/investigation.md679 B
- playbooks/perf.md1.4 KB
- playbooks/refactoring.md2.4 KB
- references/benchmark-checklist.md5.4 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
作業の種類ごとの手順書
作業の重さ（E/0/1/2/R）は、承認と文書がどこまで要るかを決める。この手順書は、何をどの順に行うかを決める。2つは別に判断する。
手順書の選び方
| 作業の種類 | 手順書 |
|---|---|
| 報告された不具合を再現し、原因を突き止めて直す。原因の診断だけの依頼も含む | playbooks/bug-fix.md |
| 振る舞いを新しく足す、または変える | playbooks/feature.md |
| 振る舞いを変えずに構造を変える（名前の変更、抽出、統合、移動） | playbooks/refactoring.md |
| 計測できる遅さや重さを改善する。原因の診断だけの依頼も含む | playbooks/perf.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に従う。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
コメント
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
同じリポジトリのスキル
Codex CLI（`codex exec`）に、モデル・reasoning effort・速度を指定して作業（調査、レビュー、相談、実装）を頼み、結果を受け取って要約する。「solで〜して」「astra xhighで調べて」「luna low fastで」「Codexで〜」「Codexに聞いて／やらせて」のように、呼び名（sol / astra / luna）やCodexを指定して作業を頼まれたときだけ使う。文中に普通の単語として「sol」「luna」が出てきただけのときは使わない。
nokonoko1203/agent-settings922026年10月22日 更新
エージェントが同じ間違いを繰り返すとき、履歴から間違いの種類を洗い出し、設計、型、lint・CI、テスト、文書の順に、効く範囲で最も上の層で再発を防ぐ。計画を承認してから実装し、各チェックが過去の実際の間違いで失敗することを証明する。'/correct'で使う。
nokonoko1203/agent-settings922026年10月22日 更新
アプリを利用者と同じ操作で動かして振る舞いを確かめる、プロジェクト専用の検証スキル（`.claude/skills/verify-<app>/`）と機能一覧を作る。言語、フレームワーク、Web・CLI・API・デスクトップを問わない。'/create-verification-skill'、'このリポジトリの検証スキルを作って'、UI・CLI・サービスの振る舞いを確かめる手順がリポジトリにないときに使う。
nokonoko1203/agent-settings922026年10月22日 更新
リポジトリにエージェント開発用の検証基盤を整える。`make check`、GitHub ActionsのCI、短いAGENTS.mdを、言語とツールを検出して作る。'harness-init'、'リポジトリを初期化して'、'検証コマンドを用意して'、新規リポジトリ作成直後や既存リポジトリへの導入時に使う。
nokonoko1203/agent-settings922026年10月22日 更新
既存のコードやシステムが今どう動いているか（仕組み、処理の流れ、どこに何があるか、どの層やモジュールが持つべきか）を、コードを読んで説明する。'どうなっているか'、'仕組みを教えて'、'この処理の流れ'、'これはどこに置くべきか'、変更の前に既存の仕組みを理解したいときに使う。なぜ今の形なのか（経緯）は`why`、技術の選定は`research`を使う。
nokonoko1203/agent-settings922026年10月22日 更新