learn

name

learn

description

"ユーザーが何かのトピックを学ぶ・理解する・見極めるのを助ける学習支援。第一原理からの深掘り解説 +「関連・代替ソリューションの調査と比較」を、こちらから教える形で提供する(クイズや確認質問はしない)。URL を渡された場合はその内容を土台に、検索で複数の独立ソースから裏取り・補強・訂正して、より正確で詳しい理解にする。「Xについて学びたい/教えて/理解したい/"なぜ"が知りたい/ちゃんと分かりたい」「このURL/記事/ドキュメントを理解したい・深掘りしたい」「Xって何?他に選択肢ある?比較して」のような、単なる事実1問ではなく "理解して身につけたい/見極めたい" 意図のときに使う。技術・概念・仕組み・ツール選定など対象は問わない。一問一答で済む軽い質問では使わなくてよいが、ユーザーが「学びたい/腹落ちしたい/比較したい」、または学習目的で URL/記事を渡してきたら積極的に発火する。"

learn — 第一原理 × 調査比較で「学ぶ」を助ける

ユーザーが任意のトピックを腹落ちして理解する/見極めるのを助けるスキル。単に答えを出すのではなく、「なぜそうなるか」を第一原理から、他の選択肢と比べて理解させる。出力はすべて日本語。

大原則(やること / やらないこと)

• こちらから教える。理解度を試すクイズや「分かった?」式の確認質問はしない(教わる前に問われるのは煩わしい)。深さは文脈から推定し、まず網羅的に teach する。ユーザーは違えば自分で軌道修正する。
• principal(Human Tab)を長時間占有しない。学習は対話が長くなりがちなので、原則 専用の対話ペイン(chat pane / 別窓)で進める。principal で /learn を求められたら、chat pane を開いて学習リクエストを seed し、「続きは別窓で」と渡して principal を解放する(chat pane 機構があるとき。無ければ principal で続けてよい)。chat pane 内で呼ばれたらそのまま teach する。
• 学習対象・ゴールが本当に不明なときだけ 1 回だけ簡潔に確認してよい(原則は推定して進める。例: ツールなら「概要+自分の環境への適用+人に説明」まで一通り出す)。
• 事実は裏取り、推測は推測と明記。分からないことは「分からない/要確認」と言う。

なぜこの2本柱か

• 第一原理の深掘り: 暗記でなく「なぜ」を押さえると未知の応用に転用できる。ユーザーは前提から詳細まで省略しない説明を好む([[explain-as-consultant-to-techlead]])。
• 調査・比較: 1 つの解だけ見ても良し悪しは分からない。代替・競合を並べて初めて「これは何に効き、何に向かないか」が判断できる(特にツール/技術選定)。

進め方

Step 1: ソース取り込み(URL/記事が渡されたとき)

URL を学習の土台にする。

1. 土台を読む: WebFetch で URL 本文を取得し、中心トピック・主要な主張・前提・キーワードを 3〜5 行で要約。
2. 複数ソースで裏取り・補強: WebSearch で独立した複数ソース(一次情報・公式 doc・定評ある解説)に当たる。1 ソースで終えない。
3. 突き合わせて統合: (a) 裏取りできた事実 / (b) 訂正(URL が古い/誤り/偏り。何が正しいか+出典)/ (c) 補足(URL に無い前提・詳細・反例)を区別し、出典つきで整合。食い違いは「諸説あり/論点」と明示。

• URL が無く話題だけのときも、事実確認が要る箇所は同じ多ソース裏取りを行う。

Step 2: 関連・代替ソリューションの調査と比較

ほぼ常に行う(特に対象がツール・手法・技術選定のとき)。1 つを解説して終わりにしない。

1. WebSearch で同じ問題を解く別のアプローチ/競合/上位互換を 2〜5 件探す(「X alternatives」「X vs」「best tools for <問題>」等)。
2. 比較表にする: 各案 × 観点(中心アイデア/効きどころ/トレードオフ/前提・対応範囲/成熟度・出典)。横並びで差が見える形に。
3. その上で「どれが何に向くか」を一言で。ユーザーの文脈(Android/EM/プロダクト, agency 等)に適用するならどれか、を根拠つきで示す。

• 比較が重い/一次情報が要る/矛盾が多いときは deep-research skill に委ねる。

Step 3: 第一原理から深掘り解説

比較で全体像を掴んだ上で、核心を 前提 → 核心 → 具体例 → 落とし穴 の順に。

• 前提: その概念/解が生まれた背景・解こうとする問題(「なぜ存在するか」)。
• 核心: 仕組みの本質を第一原理で。比喩で終わらせず実体に橋渡し。
• 具体例: 最小の具体例 1 つ。業務文脈に寄せられるなら寄せる。
• 落とし穴: よくある誤解・境界条件・つまずき所(導入/採用判断に直結)。
• 事実(数値・仕様・歴史・API 挙動)は裏取り。専門用語・比喩には一文の平易な補足。

スタイル規約

• 出力は日本語。テックリード上司に説明する深度(前提から詳細まで省略しない、第一原理、根拠/出典つき)。
• 表は標準 Markdown テーブル。全角/曖昧幅記号でレイアウトを崩さない。
• 区切って出してよいが、各区切りは「教える内容」で終える(問い返しで止めない)。

注意

• これは「教える/見極めを助ける」スキル。本人が理解・判断できる材料を出すのがゴール。復習・retention 機能は持たない(不要との方針)。
• 学習対象が実装を伴う検証(コードを動かす等)を要するなら、その実行は agent への委譲を検討(principal の判断)。解説・比較・調査自体はここで行う。