菜单
ドキュメント・実装・アーキテクチャを、調査・推測・実地検証を踏まえて段階的に解説し、その過程と結論をMarkdownドキュメントとして書き出すスキル。「〇〇の仕組みを理解したい」「コードベースを読み解きたい」「設計の意図まで把握したい」「他の人に説明できるレベルで学びたい」「調査結果をドキュメントに残したい」など、深い理解や学習記録の作成を目的とする依頼に使用する。複数ファイルにまたがる調査や、Markdownドキュメントとして残す必要がある場合は積極的に起動する。「〇〇って何？」「ざっくり教えて」など2〜3文で答えられる一問一答の質問には使わない。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Gitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。
指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。
既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。
マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。
| name | x-teach-me |
| description | ドキュメント・実装・アーキテクチャを、調査・推測・実地検証を踏まえて段階的に解説し、その過程と結論をMarkdownドキュメントとして書き出すスキル。「〇〇の仕組みを理解したい」「コードベースを読み解きたい」「設計の意図まで把握したい」「他の人に説明できるレベルで学びたい」「調査結果をドキュメントに残したい」など、深い理解や学習記録の作成を目的とする依頼に使用する。複数ファイルにまたがる調査や、Markdownドキュメントとして残す必要がある場合は積極的に起動する。「〇〇って何？」「ざっくり教えて」など2〜3文で答えられる一問一答の質問には使わない。 |
| allowed-tools | ["AskUserQuestion","Read","Bash","Glob","Grep","Write","Edit","WebFetch","mcp__playwright__*","mcp__*","TaskCreate","TaskUpdate","TaskList"] |
対象のドキュメント・実装・アーキテクチャを調査し、その目的・構造・意思決定を段階的に解説します。読解だけでなく、ローカルでの実行・観察・小さな改変、および利用可能なMCPツール(Playwright・WebFetch・各種コネクタ)を組み合わせ、過程と結論をMarkdownドキュメントとして書き出します。
着手前に学習の目的と完了条件をユーザーと合意し、章立てが完了条件に沿っているかを常に確認しながら進めます。最終的にユーザーが自分で応用・拡張できる理解と、後から読み返せる学習記録を残すことを目指します。
詳細ルールは以下の参照ファイルに分割しています。各フェーズの着手前に必ず読んでください。
references/document-rules.md — 成果物のMarkdownルール(コードブロック・図表・文章スタイル)references/question-guide.md — AskUserQuestionの使い方と質問テンプレートreferences/doc-template.md — ドキュメントの初期テンプレートスキルを起動したら、作業を始める前にreferences/doc-template.mdを読んで成果物の構造を把握します。どんなドキュメントを作るかを先に理解しておくと、各フェーズで何を読み・何を書くかが明確になります。
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|---|---|
| 1 | 目的とゴールの合意 | — |
| 2 | 出力先の合意とファイル作成 | 1 |
| 3 | 静的探索 | 2 |
| 4 | 動作環境の把握 | 3 |
| 5 | 構造と意思決定の推測 | 4 |
| 6 | 解説計画の提示 | 5 |
| 7 | 段階的な解説 | 6 |
| 8 | 小さな改変による定着 | 7 |
| 9 | 完了判定とまとめ | 8 |
学習の目的・完了条件・スコープ外を確認します。目的が曖昧なまま進めると章立てが発散するため、question-guide.mdの「フェーズ境界の質問の型」を参照してAskUserQuestionで1問ずつ確認します。合意できたら内容を口頭(チャット)で復唱してからファイル作成に進みます。
出力先(既定: docs/learn/<topic>.md)・粒度・実行範囲をAskUserQuestionで確認します。doc-template.mdのテンプレートを使い、目的・完了条件・スコープ外を埋めた状態とし、Writeを呼び出して初期ファイルを作成します。
Glob/Grepで関連ファイル(import元・呼び出し元・テスト・型定義・設計ドキュメント・設定ファイル)を洗い出します。Readで対象本体とREADME・コメント・package.jsonなどを読み、「参照一覧」セクションとしてドキュメントに記録します。
依存関係・ビルド・実行・テスト・型チェック方法を特定します。すぐ動かせる例(examples/・fixtures/・CLIの--help)を探します。利用可能なMCPツールを棚卸しし(Playwright・WebFetch・接続済みコネクタ)、対象の性質と照らしてどのツールがどの検証に使えるかを「動かし方」セクションに併記します。
責務・入出力・依存先・呼び出し関係を整理したら、まずMermaid図として可視化します。図を先に書くことで関係性の抜けや矛盾に気づきやすくなるため、文章での解説はその後に書きます。設計上の選択を推測し、根拠(構成・命名・依存・コミット履歴)を併記します。静的事実・実行で検証すべき推測・実行しても確かめにくい意図、の3層に整理します。
章立て(例: 全体像 → 動作確認 → 主要コンポーネント → 個別の意思決定 → 応用ポイント)をドキュメントの目次に書き出します。各章で「読む」「動かす(Bash/MCP)」「変えてみる」のどれを行うかを明示し、各章がどの完了条件に貢献するかを併記します。貢献しない章は計画から外します。AskUserQuestionで開始章・粒度・実行範囲を確認します。
章ごとに以下を繰り返します。構造を説明する章では必ず図を先に書いてから文章で補足します。図のないまま箇条書きだけで済ませることはしません。
章を書き終えたらAskUserQuestionで確認し、修正・補足・次章の方向を決めます。短いトピックでも省略しません。
解説のルールを守ります。
ユーザーが希望すれば、安全な範囲で改変実験を行います(例: ログ追加・分岐の差し替え・テスト追加)。改変前後の差分・観察結果・解釈をドキュメントの「実験ログ」章に残します。変更はコミットせず、確認後に元へ戻します。
冒頭で合意した完了条件を1つずつ照合し、達成度を「完全/部分/未達」のいずれかで明示します。未達のものは「なぜ達成できなかったか」「次に何があれば達成できるか」を書きます。「確認できた事実/残った推測/踏み込まなかった領域/次の一歩」をドキュメント末尾にまとめます。進行中マーカーを外して完成版とし、出力先のファイルパスをユーザーに提示して締めます。
--help・--dry-run・--version・テスト実行・型チェック・ls/tree/cat系)MCPツールは積極的に使います。WebUIを含む対象ではPlaywright MCPを必ず検討します。ライブラリやフレームワークが対象のときはWebFetchで公式READMEやAPIリファレンスを直接取得して引用します。ツール選択は「何を確かめたいか」から逆算し、スクリーンショットを目的ではなく仮説の検証手段として使います。取得したスクリーンショット・ログ・引用は出力先ドキュメントの近くに配置し、本文から相対パスで参照します(例: docs/learn/<topic>.assets/01-initial-state.png)。