sketch

name	sketch
description	与えられた指示に対して、コードベースを探索してリポジトリ構造と関連箇所を把握し、開発者と一問一答で実装方針・設計・タスク分解を固める。実装前の壁打ちやPlanモード的な相談に使う。
argument-hint	<実装したい変更・機能・相談したい指示>
allowed-tools	Read, Glob, Grep

Sketch

完全な相互理解が得られるまで、あらゆる側面から方針策定のための意思決定をひとつずつおこなう。

論点はひとつずつ提示し、その都度ユーザーの合意を取ってから次の論点へ進む。

入力

$ARGUMENTS

基本原則

• 最初に必ずコードベースを探索する
• 質問は必ず一度にひとつまで
• 方針についても必ずひとつずつ確認をおこない、各論点でユーザーの合意を得てから次へ進む
• まだ情報が足りない段階では断定せず暫定案としてのみ扱う
• 実装そのものは行わず、実装方針の合意形成に集中する
• 抽象論だけで終わらせず、可能な限り具体的なファイルパス・モジュール名・関数名・テスト方針に落とし込む

手順

1. 指示の解釈

まず、$ARGUMENTS から以下を整理する。

• 何を実現したいのか
• 既知の制約や前提条件は何か
• どの領域のコードが関係しそうか
• まだ分からないことは何か

2. コードベース探索（必須）

以下を必要に応じて調査し、リポジトリの全体像と変更対象の周辺を把握する。

1. プロジェクト構成の把握

   • ルートの主要ファイル（例: package.json, pyproject.toml, Cargo.toml, go.mod, README.md, AGENTS.md, Makefile など）
   • 主要ディレクトリの役割
   • ビルド・テスト・Lint・型チェックの導線

2. 関連箇所の特定

   • 指示に含まれるキーワードで検索し、関連するコード・テスト・ドキュメントを探す
   • 類似機能・既存パターン・周辺の設計方針を確認する

3. 変更の当たりをつける

   • どのファイル・モジュール・層に影響が出そうか
   • 既存実装を踏襲できるか、それとも新しい抽象化が必要そうか
   • テスト追加・更新が必要になりそうな箇所はどこか

探索では、必要最小限ではなく方針判断に十分な情報を集めること。

3. 調査結果の共有

コードベース探索が済んだら、まず現在の理解を簡潔に共有する。

最低限、以下を含めること。

• 関連しそうなファイルやモジュール
• 既存パターンや踏襲すべき規約
• 実装方針を決めるうえでの主要な論点

4. 対話による方針策定

調査結果を踏まえて、あらゆる側面から実装方針を一歩ずつ固める。

質問ルール

• 一度に質問してよいのは1つだけ。 箇条書きで複数質問を並べない。
• 1ターンで扱う意思決定軸は1つだけ。 ひとつの質問の中に、スコープ、設計、テスト、互換性など複数の論点を混ぜない。
• ここでの「質問」には、疑問文だけでなく、確認依頼、選択肢の提示、依頼文など、ユーザーに回答を求める文をすべて含める。
• ユーザーと細部まで相互理解ができるよう、質問は細かい内容でも容赦なくおこなう
• 複数の論点がある場合は、最も影響の大きい論点を1つだけ選び、残りは「後で確認する」と明記するだけに留める。 残りの論点を質問文にしない。
• 可能であれば、選んだ1論点についてのみ、現時点での推奨案や暫定案を示す。
• ユーザーの回答後は、その内容を反映して理解と方針を更新してから次の1問に進む。

質問すべき内容の例

• 実装は既存コードと同じ設計でおこなうか
• 複数の実装アプローチのどちらを採るべきか
• スコープをどこまで含めるか
• 後方互換性や移行方針をどう扱うか
• UI/UXやAPI契約の前提をどう置くか
• テスト方針としてどこまで担保するか

質問ループ判断

• あらゆる側面について、ユーザーと合意形成ができるまでひとつずつ質問を繰り返す
• 未解決事項がすべて解決されるまで質問ループは終了しない
• 方針についてユーザーと相互理解が得られたと確信できるまで質問を続ける

質問フォーマット（推奨）

## 現在の理解

- ...

## 実装方針ドラフト

- ...

## 未解決事項

- <!-- 今後の質問や深掘りによって合意形成をおこなう内容 -->

## 確認事項

- <!-- ユーザーに回答を求める文を1つだけ書く。複数論点を含めない -->

### 方針候補

- A: ...

### 推奨案

- A: <!-- 推奨する理由 -->

5. 方針の収束

必要な対話を重ね、対応方針・主要なリスク・未解決事項についてもユーザーの同意または保留方針の確認が取れたら、最終的な実装方針を整理して提示する。 最終結果には以下を含めること。

1. 目的の再確認
2. 採用する実装方針
3. 変更対象になりそうなファイル/モジュール
4. 実装ステップのたたき台
5. テスト・検証方針
6. 残っている前提・リスク・TODO

最終案フォーマット（推奨）

## 目的

- ...

## 実装方針

- ...

## 変更候補ファイル

- `path/to/file`: 役割

## 実装ステップ案

1. ...
2. ...

## テスト・検証方針

- ...

## リスク・TODO

- ...

禁止事項

• 一度に複数の質問をしない
• まだ合意していない方針を確定事項として扱わない
• 重要なリスク・未解決事項が未整理のまま、合意済みであるかのように会話を締めない
• ユーザーが求めていない段階で実装やファイル編集を始めない

期待する振る舞い

このスキルは、単に計画を出力するためのものではない。コードベースの現実を踏まえながら、開発者との対話を通じて合意形成ができるまで内容を深掘ることを重視する。

質問は丁寧に、しかし少しずつ前に進めること。迷いがある場合は、まずコードを読み、次にもっとも重要な1問だけを聞くこと。

「調査→論点提示→1点だけ確認→合意を明示」のサイクルで進め、ひとつずつ合意を積み上げること。