メニュー
ドキュメント・技術文書を、知識プロファイル (~/.claude/knowledge-profile.md) を参照・更新しながら「ユーザが作業を進められるレベル」まで対話的に読解支援する。「このドキュメントを解説して」「この設計書を理解したい」「読むのを手伝って」「前提知識が足りない」など、単発の Q&A で済まない規模のドキュメント理解で起動。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/skanehira/dotfiles --skill utility-doc-readingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
実装ループ。/dev-spec が作成した GitHub issue (ゴール / 設計参照 / DoD / 非スコープ / 依存の thin 構成) を入力に、依存順に 1 件ずつ「implementer subagent → 統合レビュー → 修正 ≤2 ラウンド → PR → DoD ローカル実行 → merge → close」で自律実装するオーケストレーター。進捗は issue コメントに残し、詰まった issue は needs-human で駐車して次へ進む。人間の介入はエスカレーション時のみ。issue 作成後にユーザーが直接起動し、エスカレーション回答後の再開も本スキルの再実行で行う。「実装ループを開始」「issue を順に実装して」「残りタスクを自動で実装」などで起動。
設計ループ。ユーザーストーリー → UI スケッチ → ユースケース → 実現可能性検証 → PoC 検証 → 横断設計 (docs/design/DESIGN.md) → 機能設計 (docs/design/features/) → 設計チェック → issue ドラフトチェック → GitHub issue 生成 (親子構造) までを対話的に実行し、人間が issue を確認して実装ループへ引き渡す。 「設計フェーズを開始」「要件を整理したい」「計画を立てたい」「ユーザーストーリーを書きたい」 「技術的に実現できるか確認したい」「機能設計を書きたい」「issue に落としたい」などで起動。 docs/design/ の状態から途中再開・特定フェーズの部分実行も可能。 `cli` / `webapp` のプロダクトモード指定で CLI ツール開発時は UI スケッチ等を軽量化できる。 issue 作成後、/dev-impl がそれを 1 件ずつ実装する。
dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。
SOC 職業分類に基づく
SKILL.md を表示中
| name | utility-doc-reading |
| description | ドキュメント・技術文書を、知識プロファイル (~/.claude/knowledge-profile.md) を参照・更新しながら「ユーザが作業を進められるレベル」まで対話的に読解支援する。「このドキュメントを解説して」「この設計書を理解したい」「読むのを手伝って」「前提知識が足りない」など、単発の Q&A で済まない規模のドキュメント理解で起動。 |
| argument-hint | <ドキュメントのパスまたは URL> |
| user-invocable | true |
大量・高密度なドキュメントを、ユーザの知識レベルと目的に合わせた深度で理解できるように導く。ゴールは「ドキュメントの完全理解」ではなく「ユーザが次の作業を進められる状態」。この違いが本スキルの深度調整のすべてを決める。
~/.claude/knowledge-profile.md がユーザの知識の永続記録。毎回の知識確認を減らし、回を重ねるごとに解説がユーザに最適化されていくための仕組み。
claude/knowledge-profile.md (mkOutOfStoreSymlink で ~/.claude/ に配置され、複数マシン間で git 同期される)drs / hms 未適用のためプロファイルを更新できない」と報告する (勝手に実ファイルを作ると home-manager の symlink 配置と衝突する)# Knowledge Profile
## 既知 (ユーザが知っていると申告した概念)
<!-- - 概念名 — 一言メモ (YYYY-MM-DD) -->
## 解説済み (本スキルで解説した概念)
<!-- - 概念名 — 解説した要点の一行要約 (YYYY-MM-DD) -->
引数のパス / URL を読む。引数がなければ対象を尋ねる。複数ファイルの場合はすべて読み、相互参照関係を把握する。
AskUserQuestion で「このドキュメントを読んで何ができればよいか」を確認する:
このゴールが解説深度の上限になる。以降のすべての解説で「この深さはゴールに必要か?」を自問し、超える詳細はユーザが追加で聞いたときだけ提供する。技術の内部実装を知らなくても、役割と挙動が分かれば作業を進められることが多い — その線で止める。
ドキュメントを理解する上で土台になる概念だけを抽出する (登場する専門用語の網羅ではない。それを知らないと本文の議論が追えないもの、の基準で選ぶ)。ゴールが浅いほど抽出も絞る。
各概念を知識プロファイルと突き合わせて 3 分類する:
| 分類 | 判定 | 扱い |
|---|---|---|
| 既知 | プロファイルの「既知」に記載あり | 確認せず解説もスキップ |
| 解説済み | プロファイルの「解説済み」に記載あり | 「以前解説しましたが復習しますか?」と軽く確認 (陳腐化対策) |
| 未知候補 | プロファイルに記載なし | ステップ 4 で確認 |
未知候補を AskUserQuestion (multiSelect) で提示し、ユーザに「知っているもの」を選んでもらう。概念が 5 個を超える場合は、本文理解への影響が大きい順に絞るかグループ化して、確認の往復が 1〜2 回で済むようにする。
ユーザが「知っている」と答えたものはプロファイルの「既知」へ、それ以外が解説対象になる。
(a) 未知概念の解説 — 役割・挙動レベルで解説する:
例: 「mkOutOfStoreSymlink」なら — ✅「Nix 管理のファイルをコピーではなく元リポジトリへの symlink として配置する仕組み。これがあるので設定を編集すると再ビルドなしで即反映される。この設計書では live edit を実現する手段として登場する」 ❌ Nix store の内部構造、derivation の仕組み、他の symlink 手法との比較表
(b) 本文ウォークスルー — セクション単位で進める:
セッション末尾に、今回解説した概念を「解説済み」セクションへ、ユーザが既知と申告した概念を「既知」セクションへ追記する (日付は date +%F で取得)。既存エントリと重複させない。更新したことを一行で報告する。
ウォークスルー中にユーザが特定の概念を深く聞いてきたら、それは深度上限の一時解除。その質問に限り詳細に答え、答え終わったら元の深度に戻る。深掘りした内容もプロファイルの「解説済み」に反映する。