菜单
コードベースを探索し、アーキテクチャ改善の機会を見つける。浅いモジュールを深くすることで、テスタビリティの向上に焦点を当てる。ユーザーがアーキテクチャの改善、リファクタリングの機会の発見、密結合なモジュールの統合、またはAIがナビゲートしやすいコードベースにしたい場合に使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
| name | improve-codebase-architecture |
| description | コードベースを探索し、アーキテクチャ改善の機会を見つける。浅いモジュールを深くすることで、テスタビリティの向上に焦点を当てる。ユーザーがアーキテクチャの改善、リファクタリングの機会の発見、密結合なモジュールの統合、またはAIがナビゲートしやすいコードベースにしたい場合に使用する。 |
| ref | https://github.com/mattpocock/skills/blob/main/improve-codebase-architecture/SKILL.md |
AIのようにコードベースを探索し、アーキテクチャ上の摩擦を浮き彫りにし、テスタビリティ向上の機会を発見し、モジュール深化のリファクタリングをGitHub issueのRFCとして提案する。
深いモジュール（John Ousterhout著「A Philosophy of Software Design」）は、大きな実装を隠す小さなインターフェースを持つ。深いモジュールはよりテストしやすく、AIがナビゲートしやすく、内部ではなく境界でテストできるようになる。
Agent toolのsubagent_type=Exploreを使って、コードベースを自然にナビゲートする。厳格なヒューリスティクスに従わず、有機的に探索し、摩擦を感じた箇所を記録する：
あなたが感じる摩擦こそがシグナルである。
深化の機会を番号付きリストで提示する。各候補について以下を示す：
まだインターフェースを提案しないこと。ユーザーに「どの候補を掘り下げたいですか？」と尋ねる。
サブエージェントを生成する前に、選ばれた候補の問題空間をユーザー向けに説明する：
これをユーザーに示し、すぐにステップ5に進む。サブエージェントが並行して作業する間、ユーザーは問題について読んで考える。
Agent toolを使って3つ以上のサブエージェントを並行して生成する。各サブエージェントは深化されたモジュールに対して根本的に異なるインターフェースを作成する必要がある。
各サブエージェントに個別の技術概要（ファイルパス、結合の詳細、依存関係のカテゴリ、隠されるもの）を渡す。この概要はステップ4のユーザー向け説明とは独立している。各エージェントに異なる設計制約を与える：
各サブエージェントの出力：
設計を順番に提示し、その後散文で比較する。
比較した後、自分自身の推奨を示す：どの設計が最も優れていると考えるか、その理由を述べる。異なる設計の要素がうまく組み合わさる場合は、ハイブリッドを提案する。意見を持つこと — ユーザーが求めているのは単なるメニューではなく、強い見解である。
gh issue createを使ってリファクタリングRFCをGitHub issueとして作成する。テンプレートはREFERENCE.mdを使用する。作成前にユーザーにレビューを求めないこと — そのまま作成してURLを共有する。
