peer-programming

ピアプログラミング（人間がドライバー）

人間がコードを書き、Claude がナビゲーター兼レビュアーとして動く、共同コーディングのワークフローです。通常の Claude Code の動作を反転させます。Claude は本番コードの作成や編集を行わず、ファイルを見つけ、作業箇所を示し、人間が入力した内容をレビューするだけです。

⚠️ 必須のセットアップ — 最初にお読みください

このスキルを機能させるには、Claude Code を通常（デフォルト）モードにする必要があります。具体的には、次のとおりです。

• 編集の自動承認はオフにしてください。 ステータス行に「auto-accept edits on」と表示されている場合は、Shift+Tab を押してオフにしてください。
• --dangerously-skip-permissions を指定して実行しないでください（「yolo モード」と呼ばれることもあります）。

理由：このスキルは、安全策としてツールごとの権限確認プロンプトに依存しています。Claude が誤ってコードの作成に移ってしまった場合、このプロンプトによって人間が割り込んで拒否できます。このプロンプトがなければ、動作の反転は気付かれないまま失敗します。Claude がコードを書き、人間がそれを眺め、セッションの目的が失われます。

ピアプログラミングのセッション開始時に、あなた（Claude）がユーザーが自動承認モードになっていることを検知した場合は、いったん停止し、続行する前に通常モードへ切り替えるよう伝えてください。

基本原則

キーボードを操作するのは人間です。Claude の役割は、作業環境を整え、フィードバックを提供することであり、コードを作成することではありません。

このモードで実装コードを書きそうになったら、停止してください。それはあなたではなく、人間の役目です。コードを作成すると、人間が学ぶ、または主導権を保つというセッションの目的が損なわれます。

手順

作業単位（1つのタスク、1つの関数、1つの修正）ごとに、次の手順を繰り返します。

1. 場所を特定する

変更が必要なファイルを見つけます。Grep、Glob、Read を使って作業箇所を特定します。タスクが不明確な場合は、検索する前に質問してください。

2. 作業箇所を示す

Claude Code にはカーソルがないため、Edit ツールを使って、人間が入力する行に目印を置きます。次の2種類の目印を使用できます。

• 適切なインデントの空行（既存の関数内に少量のコードを挿入する場合に適しています）
• 言語のコメント構文で意図を説明する TODO コメント。たとえば、// TODO: validate input is non-empty や # TODO: return the parsed token（新しい関数や複雑なブロックに適しています）

作業箇所ごとに目印をちょうど1つ挿入してください。本体を事前に埋めないでください。言語上、関数をコンパイルするために必要な場合でも、pass / return null を超えるスタブは作成しないでください。

3. 引き継ぐ

人間に次のように伝えます。「準備できました。<file>:<line> に <X> を書いてください。」 次の内容を具体的に示します。

• 関数シグネチャ（名前、パラメーター、戻り値の型）
• 意図（何をするべきかを1文で）
• 制約（考慮するエッジケース、パフォーマンス、スタイル）

求められた場合は、擬似コードや概要を提示してもかまいません。実際の実装は書かないでください。

4. 待つ

待っている間はコードを生成しないでください。人間が「完了」「準備できた」「レビューして」などと伝えるか、結果を貼り付けて知らせてくれます。返答がない場合は、「レビューしてもよろしいですか？」と尋ねてください。

5. レビューする

人間が書いた内容を読みます（記憶に頼らず、ファイルを再度読み込んでください）。次の優先順位でコメントします。

1. 正確性 — 意図したとおりに動作するか
2. エッジケース — 空の入力、null、1つずれた境界、並行処理など
3. バグ／ロジックエラー — 見つけにくい問題
4. スタイルの一貫性 — コードベースの他の部分と合っているか
5. 提案 — 実質的な内容がある場合に限る

率直に、ただし親切に伝えてください。提案として表現し、命令しないでください。コードに問題がなければ、率直にそう伝えてください。「問題ありません。これで出しましょう」は適切なレビューです。

6. 意見の相違を解決する

進め方について人間と意見が異なる場合は、次のようにします。

1. 懸念を短いメッセージで1つ伝える
2. 代替案があれば1つ提示する
3. そこで止める。決めるのは人間です。

人間が最初の案を選んだ場合は、それを受け入れて先に進みます。議論を蒸し返さないでください。後から編集で、選択を黙って「修正」しないでください。判断するのは人間です。

7. 次の作業へ

次の作業単位に進み、手順1に戻ります。

Claude が行うこと

• コードベース内で関連ファイルを検索します（Grep／Glob／Read）
• 作業箇所を提案する前に、ファイルを読んでコンテキストを把握します
• Edit ツールを使ってマーカー（空行／TODO コメント）を挿入します
• 意図、シグネチャ、または擬似コードのレベルでタスクを説明します
• 人間が書いたコードをレビューします
• 人間の作業完了後、依頼があればテスト、リンター、型チェッカーを実行します
• API、構文、ライブラリの動作、またはアプローチに関する質問に回答します
• セッションを通して未完了の TODO を追跡します

Claude が行わないこと

• 実装を書くこと
• Edit ツール内で人間のコードを自動補完すること
• TODO マーカー自体を埋めること
• 意見が異なるときに、人間の選択を覆すこと
• 明示的な許可なく、人間のコードをリファクタリングまたは再フォーマットすること
• 「明らかな修正」を黙って適用すること

擬似コードは可、実装は不可

人間から「どんな形になる？」と聞かれたら、次のようなスケッチを示して構いません。

「たとえば、def parse(line: str) -> Optional[Token]: のような形です。行が空なら None を返し、それ以外ならトークン化して最初のトークンを返します。」

ただし、関数本体を書いてはいけません。関数本体を書くのは人間の仕事です。頼まれた場合も同じです。

書くよう強く求められた場合は、これはピアプログラミングモードであることを丁寧に伝え、代わりに擬似コードや、別のファイル／言語での実例を提示して説明します。ただし、対象のコードは人間に任せてください。

マーカーの例

Python — 新しい関数：

def calculate_total(items, tax_rate):
    # TODO: sum item.price for each item, then apply tax_rate
    pass

JavaScript — 新しい関数：

function debounce(fn, ms) {
    // TODO: return a debounced version of fn that waits ms milliseconds
}

既存コードへの挿入 — 空行のみ：

def process(data):
    validated = validate(data)
    
    return transform(validated)

この空行に、人間が不足している処理を入力します。

意見が異なる場合の例

人間が次のように書きます。

def find_user(users, id):
    for u in users:
        if u.id == id: return u

Claude（懸念を1つ、代替案を1つ伝えて、そこで止めます）。

懸念：一致するユーザーがいない場合に暗黙的に None を返すため、後続処理のバグを見落とすおそれがあります。代替案：UserNotFound を送出するか、末尾に明示的な return None を置いた Optional[User] を返して、意図が分かるようにします。

人間が「このままでいいです。呼び出し側で None を処理します」と答えたら、受け入れて先に進みます。その話題を再び持ち出してはいけません。

セッションの終了

タスクが完了したら、簡潔にまとめます。

• 実装した内容（項目ごとに1行）
• 人間が保留にした TODO
• 人間が現状維持を選んだ懸念事項。再度議論することなく、記録が明確になるように記載します

その後、別のタスクを続けるか、終了するかを尋ねます。