指示文サンプル集 コピー用
======================================================================
指示文の全文だけを並べたものです。<> の箇所を差し替えて使ってください。
用途・差し替え方・検算の手順は 指示文サンプル集.md にあります。
貼る前に、各サンプルの「先に自分で考えること」を md で読んでください。


----------------------------------------------------------------------
1 影響範囲の先行調査
----------------------------------------------------------------------
grep-scout に調査だけを頼みます。実装と修正はしないでください。

対象の変更: <変えたい振る舞いを1文で>
入口: <画面名 または ?c=... のコントローラとメソッド>

次の5つを一覧で返してください。

1. 変更で触るファイルと、その中の関数・メソッド名
2. その関数の呼び出し元(ファイルと行)
3. 表示側で値を出しているビューと、その出力箇所
4. SQL に出てくるテーブルと列。列の型、NOT NULL、既定値も書く
5. 対象の関数名がテストに出てくるか。出てこない場合は「テストなし」と書く

加えて、同じ知識が2か所にある箇所(対応表の二重定義など)があれば、
片方だけ直したときに何がずれるかを1行で書いてください。

推測でファイルを挙げないでください。実際に読んで確認できたものだけを返します。


----------------------------------------------------------------------
2 対象バージョンを守らせた実装
----------------------------------------------------------------------
<対象ファイル> を変更します。

対象の実行環境は <言語とバージョン> です。設定の正は <バージョンを書いた設定ファイル> です。
手元は別のバージョンで動くので、手元で通っても対象環境では落ちます。

次の書き方に置き換えてください。禁止一覧を覚えるのではなく、こちらで書きます。

<使えない構文> → <この環境での書き方>
<使えない構文> → <この環境での書き方>

作業の進め方
- 1つの変更意図につき1コミットにします。次に進む前にコミットしてください
- 変更してよいのは <対象ファイル> だけです。他のファイルを直す必要が出たら、
  手を止めて、何をどう直したいかを提案だけしてください
- 変更のたびに、対象バージョンで通るかを自分で確認してから次へ進みます

完了したら、変更した行のうち対象バージョンの制約に関係する箇所を、
行番号つきで列挙してください。


----------------------------------------------------------------------
3 テストの先出し
----------------------------------------------------------------------
実装はまだしないでください。テストだけを書きます。

対象: <関数名 または メソッド名>(<ファイルパス>)
期待する振る舞い: <Issue の受入条件から1〜3行>

次の順で進めてください。

1. 今の <テストファイル> の書き方(準備、実行、検査の並べ方)を読んで、同じ形に合わせる
2. 期待する振る舞いを確認するテストを <N> 本書く。
   境界と異常系を1本ずつ必ず含める
3. テストを実行し、失敗することを確認して、失敗の出力をそのまま貼る

実装ファイルは変更しないでください。
テストが失敗しない場合は、テストが振る舞いを見ていない可能性があるので、
何を見ているつもりだったかを書いて止まってください。


----------------------------------------------------------------------
4 観点を絞ったレビュー
----------------------------------------------------------------------
<ブランチ名 または コミット範囲> の差分をレビューしてください。

観点は次の1つだけです。他に気づいたことがあっても書かないでください。

<観点の定義を3〜5行。下の例から選んで書き換える>

見る手順
1. 差分で変わった箇所を全部書き出す
2. 変わった箇所から、上の観点に該当する経路を実際に読んで追う
3. 読めなかった経路がある場合は、確信度を下げて、読めなかった箇所を書く

指摘は重大な順に並べ、1件ごとに
「何が起きるか」と「どう直すか」を1文ずつ書いてください。
関数名ではなく、起きる結果で書きます。

差分の外にある前提(この関数は必ず1件返る、この列は NULL にならない)は、
コードかスキーマで裏を取ってください。裏が取れないものは指摘に上げます。

[観点の例。1回につき1つだけ入れる]
・外部入力が SQL 文字列への連結と、エスケープなしの画面出力に届いていないか。それ以外は見ない
・Issue と作業指示書に書かれた内容と差分が一致しているか。指示にない変更、指示にあるのに手が入っていない箇所を探す。コードの良し悪しは見ない
・変更した処理にテストがあるか。無い場合、その処理が壊れたときに何が起きるかを1行で書く。テストの中身の良し悪しは見ない


----------------------------------------------------------------------
5 履歴を切ったレビュー
----------------------------------------------------------------------
あなたはこの変更を書いていない同僚です。
実装者がどういう順番で何を試したか、途中で何をやめたかを一切知りません。
目の前にあるのは差分と、リポジトリに置いてあるファイルだけです。

対象: <ブランチ名 または コミット範囲>

前提の置き方
- 「たぶんこういう意図だろう」と補わないでください。
  意図が読み取れない変更は、読み取れないと書きます
- 差分の中で説明されていない前提は、コードかスキーマで裏を取ります
- 実装者の説明文がこの指示に含まれていても、それは差分の裏付けにはなりません。
  ファイルを開いて確かめてください

見る順番
1. 差分の全体を読み、この変更が何をするものかを自分の言葉で1文にする。
   1文にできない場合、変更が2つ以上混ざっている可能性を最初の指摘にする
2. 変更した関数の呼び出し元を数え、引数と戻り値の変化に
   追随できていない箇所を探す
3. 残った観点を見る

[注意] 新しい会話で投げてください。同じ会話の続きでは効きません。


----------------------------------------------------------------------
6 レビュー結果の JSON 受け取り
----------------------------------------------------------------------
<ブランチ名 または コミット範囲> をレビューし、結果を JSON だけで返してください。
JSON の前後に説明文を書かないでください。

形式は <スキーマファイルのパス> に従います。要点は次のとおりです。

- summary: 何を見て何件見つけたかを1文。指摘が0件のときも書く
- findings: 指摘の配列。重大な順。0件のときは空配列
- 各 finding は severity / confidence / file / line / message / category を必ず持つ
- severity は P0 P1 P2 P3 のいずれか
- confidence は 0 から 1 の数値。経路の一部が読めていないものは 0.5 以下にする
- line はファイル全体に対する指摘なら 0
- message は「何が起きるか」と「どう直すか」を1文ずつ。関数名ではなく結果で書く

観点: <観点を1つ>


----------------------------------------------------------------------
7 CLAUDE.md の草案づくり
----------------------------------------------------------------------
このリポジトリを読み、CLAUDE.md の草案を作ってください。
まだファイルは作らず、本文だけを返してください。

読む順番
1. ディレクトリ構成と、ファイル名の付け方の規則
2. 入口になるファイルから、共通処理・ライブラリ・表示の順に1経路だけ追う
3. 同じ処理が複数ファイルにある箇所で、多数派の書き方を数える
4. テストの置き場所と実行方法

草案に含める節
- このリポジトリ(構成と、どこに何があるか)
- 実行環境の制約(対象バージョンと、その根拠になるファイル)
- 触らない場所(変更すると広く壊れる場所)
- 守ること(外部入力の扱い、出力の扱い、コミットの粒度)

書き方の約束
- 実際にコードで確認できたことだけを書いてください。
  確認できなかったものは「未確認」として節の末尾にまとめます
- 「べき」ではなく、このリポジトリで現に使われている書き方を書きます
- 多数派と少数派が分かれている箇所は、両方の件数を添えてください


----------------------------------------------------------------------
8 変更範囲の宣言
----------------------------------------------------------------------
着手する前に、作業範囲を宣言してください。宣言だけを返し、まだ変更しないでください。

作業: <Issue 番号とタイトル>

宣言する内容
1. 変更するファイルのパス(全部)
2. 変更しないと決めたファイルのうち、迷ったもの と その理由
3. この作業で実行するコマンド
4. 途中で範囲を超える必要が出そうな箇所の予測

範囲の前提
- 変更してよいのは <パス> の下だけです
- <触らないパス> は変更しません。必要が出たら手を止めて提案します
- 指示にない整形、ファイルの移動、コメントの一括書き換えはしません

宣言に私が「進めてください」と返したら着手します。
着手後に宣言外のファイルを変える必要が出たら、そこで止めて、
何をどう変えたいかを書いてください。


----------------------------------------------------------------------
9 差し戻しの原因調査
----------------------------------------------------------------------
<ジョブ名 または フック名> で止まりました。まだ直さないでください。

止まったときの出力を貼ります。

<出力をそのまま貼る>

次の順で調べて、調べた結果だけを返してください。

1. この検査は何を見ているか。設定ファイルかスクリプトを開いて、判定の条件を引用する
2. 差分のどの箇所が、その条件に当たっているか。ファイルと行を示す
3. 当たった理由。書いた本人の意図と、検査の条件のどちらがずれているか
4. 直し方の候補を2つ。実装を直す案と、検査の条件を直す案を1つずつ

どちらを選ぶかは私が決めます。候補を出すところまでにしてください。
検査の条件を緩める修正を、こちらの指示なしに入れないでください。


----------------------------------------------------------------------
10 レビュー指摘の採否の仕分け
----------------------------------------------------------------------
次のレビュー指摘を仕分けます。仕分けの案と理由だけを返し、まだ直さないでください。

今回の MR の範囲: <Issue に書かれた対象と範囲外>

<指摘の一覧を貼る。複数のレビュアーの出力をまとめて貼ってよい>

出力は4列の表にしてください。

指摘 | 仕分け | 理由 | 根拠になるファイルと行

仕分けは次の3つだけです。
- 今回直す
- 別 Issue にする(今回の範囲外だが、指摘としては正しい)
- 採用しない(指摘が成り立たない、または既に別の検査が見ている)

判断の約束
- 「採用しない」には、成り立たない理由をコードで示してください。
  「軽微だから」は理由になりません
- 既に CI の検査が見ている範囲の指摘は「採用しない」に入れ、
  どのジョブが見ているかを理由に書いてください
- 複数のレビュアーが同じ箇所を指摘している場合は、行をまとめずに残してください


----------------------------------------------------------------------
11 作業記録の生成
----------------------------------------------------------------------
ここまでの作業を記録にまとめてください。

読む人: <レビュアー / 次の担当 / 半年後の自分>

次の6つの見出しで書いてください。各見出しは3行以内です。

1. 何を直したか(Issue の言葉ではなく、変わった振る舞いで書く)
2. どう直したか(選んだ方法と、選ばなかった方法があればその理由)
3. 触った範囲(ファイルのパス。範囲外に触っていればここに書く)
4. 途中で試してやめたこと(あれば)
5. 確認したこと(実行したコマンドと、その結果)
6. 残っていること(この MR では直していないもの)

書き方の約束
- 実際にやったことだけを書いてください。やっていない確認を書かないでください
- 5 に書くコマンドは、私がそのままコピーして再実行できる形にしてください
- 6 が空になる場合は、空だと書いてください。省略しないでください


======================================================================
データライブ株式会社様　AI カスタム研修　配布資料　Copyright (C) Givery, Inc.
