ハクソク

世界を動かす技術を、日本語で。

意図的なスキル開発のためのクロードコードとコーデックススキル

19時間前原文(github.com)

概要

  • learning-opportunities は、科学的根拠に基づいた学習法をエンジニアリングワークフローに組み込むスキル
  • コーディングや設計作業後に 10～15分の学習エクササイズ を提案
  • 実証済みの学習科学 （生成、予測、リトリーバル、間隔反復）を活用
  • Claude CodeやCodexプラグイン として簡単に導入可能
  • チームや個人の 学習文化醸成とスキル向上 を支援

learning-opportunities：エンジニアのための動的学習スキル

  • プロジェクト構築 だけでなく、 専門性の構築 を重視するアプローチ
  • アダプティブな「動的教科書」 方式により、日々の開発フローに学習を統合
  • 新ファイル作成、スキーマ変更、リファクタ などの設計作業後にオプションで学習エクササイズを提案
  • エクササイズは 予測、生成、リトリーバルプラクティス、間隔反復 などの科学的手法を応用
  • 自分のプロジェクト実例を利用した 半完成例 を活用した学習体験

導入方法とプラグイン構成

  • Codexプラグインマーケットプレイス から次のコマンドで導入可能
    • codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git
    • ローカル開発の場合はパス指定も可能
  • Claude Codeプラグイン としてもインストール対応
    • マーケット追加後 /plugin install learning-opportunities@learning-opportunities
    • Claude Codeの再起動で有効化
  • 自動プロンプト機能 （learning-opportunities-auto）で、git commit毎に自動で学習提案
  • orientプラグイン によるリポジトリのオリエンテーションレッスン生成機能

学習科学にもとづくリスクと対策

  • AIコーディングツール による学習低下リスク
    • 生成効果の低減：自分でコードを書く機会減少による理解不足
    • 流暢性の錯覚：生成コードが理解できていると錯覚しやすい
    • 間隔効果の喪失：反復・振り返りの機会減少
    • メタ認知の不足：自分の理解度や知識ギャップの把握が難しくなる
    • テスト・リトリーバルの機会減少：自己テストや知識の引き出しが減る
  • SKILL.md に記載の手法でこれらリスクを回避
    • アクティブ生成（予測・説明・スケッチ）
    • リトリーバルプラクティス（自己テスト・教え返し）
    • 意図的な間隔（振り返り・休憩）
    • 明示的なメタ認知（自己評価・ギャップ特定）

エクササイズの種類

  • 予測→観察→振り返り ：結果予測→実行→驚きを振り返る
  • 生成→比較 ：実装前に自分でアプローチをスケッチ→実装と比較
  • 実行経路のトレース ：一つずつ実行を追い、各遷移を予測
  • デバッグ ：どこで何が問題になるか推測
  • 教え返し ：新しい開発者に説明するつもりで解説
  • リトリーバルチェックイン ：前回から覚えていることを確認

プロンプト抑制条件

  • 同一セッション内で既にエクササイズを辞退
  • 同一セッションで2回エクササイズを完了

チーム導入・計測サポート

  • MEASURE-THIS.md による軽量な事前・事後計測ガイド
    • チームの学習文化やAIスキル脅威感を可視化するためのサーベイ項目
    • 結果の扱い方や分析の注意点
    • チーム向けの報告テンプレートも提供

カスタマイズ例

  • 技術スタックや学習目標 に合わせたエクササイズレベルの調整
  • ワークフローに合わせたトリガー条件や上限数 の変更
  • プロジェクト固有の例題や質問 の追加
  • 評価チェック の組み込みによる効果測定

背景とリサーチ

  • Dr. Cat Hicks による学習科学と現場インタビューを基に開発
  • agentic coding （AI主導コーディング）時代の開発者の成長と心理的安全性を重視
  • 学習文化の強いチームは AI導入時の不安や脅威感が低く、チーム効果が高い 傾向

関連リソース・参考文献

  • PRINCIPLES.md で学習科学の詳細解説
  • AI Skill Threat や Developer Thriving などの公開サーベイ
  • 主要な学習理論・実践論文への参照
    • Bjork, Dunlosky, Ericsson, Giebl, Hicks, Kalyuga ほか

著者・関連情報

  • Learning-Opportunities 開発者：Dr. Cat Hicks（心理学者・研究者）
    • Web: drcathicks.com
    • コンサル: catharsisinsight.com
    • 書籍: The Psychology of Software Teams (2026)
  • Orient 開発者：Dr. Michael Mullarkey（元セラピスト・MLエンジニア）
    • Web: blendtutor ほか

更新・コミュニティ

  • オープンサイエンスリソース の共有・フィードバック歓迎
  • ニュースレター「Fight for the Human」で最新情報発信

このスキルは AI時代の開発者に求められる学習力・適応力の強化 を目指し、日常の開発体験に 科学的な学びの機会 を組み込むための新しいアプローチを提供します。

Hackerたちの意見

ベンチマークや評価がないけど、どうやって/create-skillよりも良い結果が出るってわかるの？単純なテストじゃ信頼感が得られないよね。

└

これは人間のスキル開発を意味してると思う。ユーザーに学習の機会を提供するんだ。 > アーキテクチャ作業（新しいファイル、スキーマの変更、リファクタリング）を完了すると、Claudeは証拠に基づいた学習科学に基づいたオプショナルな10-15分の学習エクササイズを提供するよ。エクササイズでは、予測、生成、リトリーバルプラクティス、間隔反復などのテクニックを使って、自分のプロジェクト作業から半分完成した例を提供してくれる。名前はちょっと混乱するけどね。

└

ええ、evalsのことを言ってくれて嬉しい！今使っているものや探しているものを教えてもらってもいい？自分で作ってるの、それとも既存のフレームワークを使ってるの？

└

LLMに夢中になりすぎて、関連用語を言うだけでパブロフの反応が出る脳。

スキルには詳しくないけど、リポジトリを見た感じ、装飾的なコードやテキストが多すぎると思う。結局、bashスクリプトで実行される以下のプロンプトに過ぎないのに（やばい）： {"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":"[learning-opportunities-auto] ユーザーがコードをコミットしました。learning-opportunitiesスキルに基づいて、今が学習エクササイズを提供する良いタイミングかどうか考えてみてください。コミットされた作業に新しいファイル、スキーマの変更、アーキテクチャの決定、リファクタリング、または不慣れなパターンが含まれている場合、ユーザーに（短い文で）10-15分のエクササイズをやりたいか聞いてください。確認があるまでエクササイズを始めないでください。もし断られたら、そのことを記録しておいてください — このセッションではもう提案しないで。"}}

└

スキルは、進行的開示やプロンプト共有を通じて文脈を保存する再現可能なワークフローを説明するのに良い基準だよ。あまり使われていない機能だけど、非決定的な部分を決定的なもの（スクリプトなど）と結びつけることもできる。概念的には、他人から魔法を借りるんじゃなくて、増分ソフトウェアとして扱うべきだよ。[1] コーディングハーネスにはSkillBuilderエージェントスキルがあることが多いから、作成がすごく簡単になるし、進化させることもできる。自分の特定の問題点に合わせて自分のものを作ることをおすすめするよ。別のユーザーが「evals」について言ってたことを示すとてもシンプルな例があるよ。[2]

└

これらのツールのほとんどは、プロンプトに何らかの形でスライスされる別のmdファイルに過ぎない。これがLLMの動作方法だよ…普通のことだね。だから、同じようなツールを自分で作るためにClaudeを使うことをおすすめするよ。ちょっとトークンを使うけど、その後は自分のツールを使うことで90%のトークンコストを節約できるから…本当に意味のある作業をするのに必要なトークンやコールがどれだけ少なくて済むか、すごく驚くよ…それに、ツールの呼び出しをより安全にロックダウンできて、エージェントのタスクを再試行可能にしたり、失敗モードを与えたりできるしね。（ただし、エージェント作業中にノートパソコンが壊れたら、あなたのコードに何が起こったかを知っているのは神とエージェントだけだよ…あ、待って。エージェントは100kトークンを使って、どこにいたかを思い出さなきゃいけないんだ（お金の使い方としては最悪だね）。

「適応的ダイナミック教科書アプローチ」って具体的に何なの？例は？ > 生成効果：生成されたコードを受け入れ、自分のコードを生成するのを減らすことで、理解を深めるためのアクティブな処理をスキップできる。まさに真実だね。

このアイデアが本当に好き！オープンソースの教科書やドキュメントを使って、Claudeにその場で教科書を作ってもらったことがあるんだ。このスキルをもっと一般的な学習や応用の分野に拡張することは可能？それとも、コードに特化してるの？

なんでこんなクールなアイデアを開発しておいて、デモリンクやサンプル出力を載せないのか全く理解できない。HNでは毎日こういうのを見るけど、結局自分でダウンロードして実行しないとこのスキルがどういうものか分からないってこと？いや、結構です。

└

SKILL.mdがそこにあるから、何をするかはそれを読めばわかるよ。

└

スキルの使い方がAGENTS.mdの明確な指示よりもずっと信頼性が低いと感じてる。エージェントにスキルを追加しない機会を与えるのがアイデアだってのはわかるけど、AGENTS.mdに明示的な指示がないと、エージェントがそのスキルを使うかどうかを保証する方法がないんだ。その時点で、どこかのマークダウンファイルを参照してるのと同じことになっちゃう。https://www.agentkanban.io（GitHub CoPilot統合のタスクボード）を作るときに、指示の配置についてたくさん実験したよ。AGENTS.mdから1つのセパレーションを持つのがすごくうまくいった（エージェントがタスク特有のIDを拾うための堅牢な手段が必要で、INSTRUCTION.mdというファイルをツールが管理するファイルに置くことにしたんだ。これでAGENTS.mdをできるだけ汚さないようにできた）。スキルも試したけど、ツールが今のように信頼性を持って機能するためには、スキルがあまりにもスキップされすぎた。

まだこの迷路に入ってない人のために言うと、スキルっていうのは狭い範囲のタスクを扱うための構造化されたマークダウンファイルなんだ。だから、APIエンドポイントを特定の方法で書くと、そのスキルがそのプロセスを説明することになる。後でエージェントがこのスキルを「見る」ことができて、現在のチャットの文脈に関連する時にロードして、指示されたことを実行するんだ。「ツールコール」と似てるけど、呼び出す関数じゃなくて、その「スキル」を実行するための指示って感じ。少なくとも私が使ってるエージェント（Cline）では、スキルをグローバルまたはローカル（プロジェクトレベル）で定義できるよ。

└

スキルには「フロントマター」っていうヘッダーもあって、その一部はコンテキストの初めに共有されるんだ。claude.mdファイルみたいにね。スキルの読み込みがコンテキストに別の影響を与えることがあるって聞いたことがある。コンパクトな状態を超えて残ることもあるみたい。たくさんのスキルを読み込むと、セッションがそれらを永久に読み込んだ状態になるかもしれない。サブエージェントと組み合わせると良いと思う。サブエージェントがスキルを読み込んで、作業が終わったら結果だけを提示すればいいから、オーケストレーターエージェントはそれを知らなくても大丈夫なんだ。

これはいいアイデアだね、今朝ちょっと試してみたよ。AIを使いすぎて脳が疲れてきてるのを感じてるけど、これが解決策ではないにしても、1日数回のエクササイズが本当に役立つと思う。

コードを書くエージェントに特有の反復的な種類がある。コーディングアシスタントの出力を正しいかどうか確認せずに受け入れると、コードベースに関する知識を失うことになる。CLAUDE.mdや移行プロトコル、認証プロトコルのようなコンテキストファイルは、適切に更新できるだけの知識があれば正しく機能する。エージェントが生成したコードを2時間盲目的に受け入れたセッションもあったけど、その後はコードベースの動作を忘れて新しいコンテキストファイルを作れなくなった。こうしたスキルの負債はdiffには現れないけど、エージェントをガイドしなければならない状況で明らかになる。これがこのスキルが提案する実践の本質だね。

└

反復的、または再帰的？私の意見では、大きな機能変更に取り組んでいる場合、エージェントにコードを書かせる前に、まずは次のことをするのがベストだと思う。1. 問題領域に関してチャット内で合意を形成する — つまり、解決しようとしているビジネスドメインの問題について（エージェントがソフトウェア開発の契約者で、何を求めているかを明確にするために座っているような感じ） 2. エージェントと一緒に階層的な箇条書きの設計文書を共著する（これは実際の.mdファイルであるべきで、チャットだけではダメ） — エージェントに大部分を生成・編集させるけど、問題や決定のあいまいさを徹底的に指摘して、すべての設計レベルの決定をここで前もって行うようにする 3. 設計仕様をBDD仕様テストスイートの骨組みに翻訳させる — 実装しながら埋めていく 4. エージェントに実装を自由にやらせる — エージェントがユニットテストや統合テストを追加・修正・削除できるけど、設計仕様ファイルと派生したBDD仕様テストの構造は固定しておく必要がある（そして、完了と見なす前に、A. BDD仕様テストがすべてラベルに反映された適切なロジックで埋められていること、2. すべてパスしていることを確認する） 5. この時点で、あなたは終わっているかもしれない。でも、プロジェクトがすごく大きい場合は、ここで新しいビジネス要件を定義し、設計を修正し、エージェントにBDDスイートを追加させるためにもう一度「スプリント」を行うかもしれない。（または、すべてを前もって話し合いたい場合は、2と3の間に「設計をマイルストーンに分解する」というステップを挿入する — その時、エージェントは現在のマイルストーンのためのBDD仕様項目だけを作成し、それを解決し、承認を得てから次のマイルストーンに進む。）要するに、LLMを使ったウォーターフォールをやるべきだと言ってるんだ。ウォーターフォールは、プロセス全体が1時間の間に行われると、実際にかなり快適になることもある。そして、ここで理解するための重要なポイントは、プロジェクト（または大きなプロジェクトの各マイルストーンの後）に、エージェントが書いたコードをチャットで説明しながら一緒に見ていくことができるということ — ただし、設計によって「暗示」されていることを説明する必要はないという制約がある。そうすれば、「驚くべき部分」の説明をコードコメントに変換させることができて、結果として得られるコメントは実際に人間が書くようなもので、形式的なゴミではなくなるんだ！

ここでの反応、面白いね。多くの人が本質を見失ってる気がする。私にとっての主な教訓は、他の人がスキルをどう使っているかを見て学ぶことだよ。昨日、マット・ポコックのエージェントの使い方に関するクラスを見てたんだけど、彼は「グリルミー」スキルを使って製品要件書を作成する方法を見せてたんだ。彼と全く同じことはしないけど、自分なりの要件の開発や実装のアイデアができたよ。結局、アンソロピックのエンジニアたち自身の言葉を借りると、クロードは才能あるエンジニアみたいだけど、専門知識が足りないんだ。スキルは専門知識を築くためのフォルダやファイルみたいなもの。ポコックから学んだもう一つの重要なことは、コンテキスト（トークンサイズ）が長くなるほど、返答がバカになる傾向があるってこと。だから、スキルは問題をLLMにコンパクトに提示する別の方法で、最適な返答を得るためのものなんだ。クロードには行動特性もあるから、誰かがスキルを反復的に構築すると、他のユーザーにうまく移行しない可能性が高い。私たちそれぞれがチャットの仕方が違うからね。だから、同僚と自分のスキルフォルダを共有するのには躊躇してる。でも、自分が作ったものをデモすることで、彼らに可能性を見せて、自分のワークフローを考えてもらうつもり。だから、他の人がクロードを使ってどうやって構築しているかを見ることが価値なんだよ。それを自分なりに真似するのが大事。プログラミングを初めて学んだとき、カーニハンとリッチーのC言語の本からコードをコピーして、それを変えてどう動くか理解して、最終的には自分の目的に合わせてカスタマイズしてたのと似てる。行動特性について言及したのは別の理由があって、著者は心理学者だから、彼女がクロードとどうやってやり取りするかを見るのが本当に面白い。プログラマーがクロードを使うのとはかなり違うだろうし。ちなみに、彼女（と他の専門家たち）はずいぶん前にTwitterを辞めたんだ。bskyやマストドンをインストールしてフォローするつもり。専門の非プログラマーがLLMをどう使っているかを見るのは大事だと思うから。

いくつかのスキルが、具体的にどのステップを踏むべきかや何をすべきかを説明していないことに驚いた。なんかモチベーションを上げるスピーチみたいな感じで、特定のタスクに対してモデルがより良いテキストを出力するための準備をするみたい。https://github.com/anthropics/claude-code/blob/main/plugins/... クロードが使うこのフロントエンドデザインスキルは、基本的にいいフォントを選んでデザインを整えるように頼んでるだけなんだ。どのフォントを使うかや、いいカラースキームやレイアウトをどう作るかについての具体的な指示はないんだよ。