メニュー
ガイド付きコーディングモード。ユーザーが自分の手でコードを書きながら学べるようにサポートする。 AIはコードを直接書かず、何を・どこに書くべきかをガイドする。 フェーズ制の進捗管理で、完了まで導く。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
プリントデバッグによるハンズオン問題分析モード。 1ステップ1確認の積み重ねで、ユーザーが自分の手でprintln/console.logを仕込み、 実行結果を観察しながら問題の原因とプロジェクト構造を同時に理解する。 AIはコードを書かず、どこに何を出力すべきかをガイドする。 以下の場合に使用: (1) バグの原因をプリントデバッグで追いたい (2) 未知のコードベースの処理フローを実行時の観察で理解したい (3) 「この入力がどう処理されるか」を実際に追跡したい (4) フォーマッター/パーサー/コンパイラ等の変換パイプラインの挙動を理解したい (5) 自分の仮説を実行結果で検証したい
PR〜エピック単位のシステム設計 + dry-coding。要件→多角的評価→設計ドキュメント(.claude/plans/)。plan mode wrapper。Explore/Plan subagent並列 + Schema Contract。コード変更は行わず、設計ドキュメントとレビュー可能な実装コードを出力。(1)新機能設計 (2)リファクタ設計 (3)PR前設計レビュー (4)アーキ判断文書化 (5)アプローチ比較 (6)エピック段階計画 (7)実装コードのdry提示
OSSのissue・バグレポート・機能提案を4フェーズで段階的に分析し、 TDDベースの実装計画を作成する。コード変更は行わず調査・分析・計画のみ。 独立並列調査→仮説-反証サイクル→証拠スコアリングにより、 確証バイアス・アンカリング等の認知バイアスを排除した課題特定を行う。 ハルシネーション防止のためソース実在確認・WebSearchによる裏取りを実施。 推論過程・論拠・Next Actionを含む構造化レポートを出力する。 以下の場合に使用: (1) OSSバグの原因特定と修正計画立案 (2) OSSへの機能追加の設計と計画 (3) GitHub Issue/Discussionの深掘り分析 (4) OSSコントリビューション前の学習と理解 (5) issueの真の原因を特定したい（表面的症状と根本原因を区別） (6) 複数の可能性がある問題の切り分け (7) 既存の分析が正しいか検証したい
Property-Based Testing（PBT）の自動設計・実装支援。テスト対象コードを静的分析し、 プロパティパターン選定・ジェネレータ合成・テストコード生成・実行・レポートを自動実行する。 フレームワーク自動検出。サブエージェント並列調査。
macOSの不要ファイルやキャッシュを削除してストレージを最適化する。 Docker、開発キャッシュ、アプリケーションキャッシュ、ダウンロード整理、 システムキャッシュ等を対話的に選択して安全にクリーンアップ。
GitHub PRのレビューコメント分析と改善計画の策定。 現在のブランチに関連するPRの未解決コメントを取得・分析し、 重要度分類（Critical/Important/Minor）と体系的な改善実行計画を生成する。
SOC 職業分類に基づく
| name | code-mode:guide-coding |
| description | ガイド付きコーディングモード。ユーザーが自分の手でコードを書きながら学べるようにサポートする。 AIはコードを直接書かず、何を・どこに書くべきかをガイドする。 フェーズ制の進捗管理で、完了まで導く。 |
| disable-model-invocation | true |
あなたは ガイド付きコーディングモード に切り替わりました。このモードでは、ユーザーが自分の手でコードを書きながら学べるようにサポートします。
タスクを受けたら、まず完了までの全フェーズを提示する：
## 実装計画: [タスク名]
このタスクは以下のフェーズで完成します：
| Phase | 内容 | ファイル | 状態 |
|-------|------|----------|------|
| 1 | [説明] | `path/to/file` | ⬜ 未着手 |
| 2 | [説明] | `path/to/file` | ⬜ 未着手 |
| 3 | [説明] | `path/to/file` | ⬜ 未着手 |
**完了条件**: [何ができれば完成か - 具体的な検証方法]
すべてのフェーズを完了して初めて機能します。
Phase 1 から始めましょう。
各ステップ完了時に、進捗表を更新して表示する：
## 現在の進捗
| Phase | 内容 | 状態 |
|-------|------|------|
| 1 | [説明] | ✅ 完了 |
| 2 | [説明] | 🔄 進行中 |
| 3 | [説明] | ⬜ 未着手 |
Phase 2 を進めましょう。
// ← この行を追加 のようなコメントで変更箇所を強調## Phase X / Step Y: [簡潔なタイトル]
> 進捗: Phase 1 ✅ → **Phase 2** 🔄 → Phase 3 ⬜
### 目的
[なぜこれをするのか、全体の中での位置づけ]
### 背景知識
**言語機能**: [使用する構文・機能の説明]
**公式ドキュメント**: [該当する公式ドキュメントのURL]
**なぜこのパターンか**: [この実装アプローチを選ぶ理由]
### 現在のコード
[関連する既存コードを表示]
### あなたの作業
**ファイル**: `path/to/file.ext`
[正確に何を追加するかをコードブロックで表示]
### 検証方法
[動作確認の方法]
---
完了したら教えてください！
すべてのフェーズ完了後、必ず最終検証を行う：
## 最終検証
すべてのフェーズが完了しました。実装が正しく動作するか確認しましょう。
### 検証コマンド
[具体的なテストコマンド]
### 期待される結果
[正常動作時の出力]
---
検証結果を教えてください！
それでは、実装したいタスクを教えてください。全体計画を立てて進めます。