Learning Opportunities - Claude CodeとCodexで意図的なスキル開発を支援するスキル
(github.com/DrCatHicks)- エージェント的コーディングを行いながら、プロジェクトだけでなくユーザーの専門性も高められるよう支援する、Claude CodeおよびCodex向けのスキル
- 新規ファイル作成、スキーマ変更、リファクタリングのようなアーキテクチャ作業を終えた後、Claudeが10〜15分の選択式学習演習を提案する
- 演習では、予測、生成、想起練習、間隔反復といった学習科学の手法を使い、ユーザーの実際のプロジェクト作業から半分だけ解かれた例を作ってくれる
- AIコーディングツールが、生成コードの無批判な受け入れ、流暢さの錯覚、長時間の詰め込み、メタ認知の不足、自己テストの減少を引き起こしうるという問題を減らすよう設計されている
- Claudeは「このトピックで短い学習演習をやってみますか？ 約10〜15分です」のように尋ね、ユーザーが受け入れると対話型演習を進める
- 中核となる設計原則は、Claudeが自分の質問に自分で答えず、ユーザーの入力を待つことであり、高速なagentic codingとは異なる内省・探索モードを作ることを意図している
- 演習タイプには、予測→観察→内省、生成→比較、実行経路の追跡、デバッグ予測、新しい開発者への説明、前回セッション内容の想起確認が含まれる
- 現在提案されている抑制条件は、1セッション内ですでに演習を断った場合、または1セッション内で演習を2回完了した場合には、学習機会を再度提案しないこと
- Codexでは
codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.gitでマーケットプレイスに追加でき、learning-opportunities、learning-opportunities-auto、orientが含まれる - Claude Codeでは Claude Code plugin marketplace から追加した後、
/plugin install learning-opportunities@learning-opportunitiesをインストールし、再起動して有効化する learning-opportunities-autoは、LinuxとmacOSでgit commit後にClaudeが演習提案を検討できるようにする任意のフックで、Windowsでも追加設定により利用できるorientスキルは、新しいリポジトリを学ぶ際にorientation.mdを作成し、プログラム理解とコードベース探索の研究に基づく推奨レッスンを提供する- Learning-Goal と併用するとよく、このスキルはMCII手法による半構造化の対話型学習目標設定を支援すると紹介されている
- チーム実験では MEASURE-THIS.md も併用でき、検証済みのアンケート項目、結果解釈ガイド、リーダーシップ共有用の「team boast」テンプレート、Claude.md向けの統計的厳密性のナッジを提供する
- Creative Commons Attribution 4.0 International License でライセンスされている
1件のコメント
Hacker Newsの意見
Skills自体はよく分からないが、リポジトリを見る限り、コミット後に実行される bash スクリプト内の短いプロンプト1つに比べて、装飾的なコードとテキストが多すぎるように見える
要するに、ユーザーが今まさにコミットしたのだから、新しいファイル、スキーマ変更、アーキテクチャ上の決定、リファクタリング、見慣れないパターンがあれば、10〜15分の学習練習を提案しろ、という話に近い
概念的には、他人が作った魔法を持ち込んで使うものではなく、段階的に育てるソフトウェアと見るべきだ https://alexhans.github.io/posts/series/evals/building-agent...
コーディングハーネスには SkillBuilder エージェントスキルがあることが多いので、作りやすく継続的に発展させられる
自分の悩みに合わせて自作するのを勧めたいし、評価を通じて自動化の精度を十分に引き上げる簡単な例もある https://alexhans.github.io/posts/series/evals/sketch-to-text...
だからこそ、Claudeで自分専用の似たような道具を作ることを勧めたい。最初はトークンを消費するが、その後は自前の道具によって意味のある作業に必要なトークンと呼び出しを大幅に減らせる
ツール呼び出しもより安全に制限でき、エージェント作業を再試行可能にし、失敗モードも減らせる。ノートPCが作業中に落ちて、エージェントがどこまで進めたかを復元するために大量のトークンを浪費するような状況も避けられる
いくつかのSkillsは、正確な手順ややるべきことすら書かれておらず、特定の作業でモデルがより良いテキストを出せるように動機づけのスピーチのようなプライミングをする程度だと知って驚いた
Claudeが使う frontend design skill も、良いフォントを選び、デザインに一貫性を持たせてほしいとほとんどお願いしているだけで、どのフォントを使うか、色のパレットやレイアウトをどう作るかといった具体性はない
https://github.com/anthropics/claude-code/blob/main/plugins/...
コード作成エージェントには反復的な負債が生じうる。コーディングアシスタントの結果を正しいか確認せずに受け入れると、自分のコードベースについての知識が失われる
CLAUDE.mdのようなコンテキストファイル、マイグレーションプロトコル、認証プロトコルは、それらを適切に更新できるだけ十分に理解しているときにしかうまく機能しないエージェントが作ったコードを2時間盲目的に受け入れたあと、コードベースがどう動いているのか分からなくなり、新しいコンテキストファイルを作れなくなったことがある。こうしたスキル負債は diff には現れず、エージェントを導かなければならない場面で露呈する
大きな機能変更を行うときは、エージェントにコードを書かせる前に、まずチャット上で解こうとしているビジネスドメインの問題について合意するのがよい。外注開発会社の担当者と座って、何が欲しいか整理するような感覚だ
その次に、エージェントと一緒に階層的な bullet の設計文書を実際の
.mdファイルとして書き、エージェントに大半を生成・修正させつつ、問題点や曖昧な決定を丁寧に詰めて、設計レベルの決定はここで先に終わらせるべきだ続いて、設計仕様を BDD 仕様テスト群の骨格に変換させ、実装しながら埋めていく
実装段階では単体テストや統合テストを追加・修正・削除してよいが、設計仕様ファイルと、そこから派生した BDD テスト構造は固定すべきだ。完了前には BDD テストがラベルに合ったロジックで埋められ、すべて通過していなければならない
プロジェクトが非常に大きいなら、新しいビジネス要件の定義、設計修正、BDD 群の追加といった過程を再度繰り返すスプリントを回せる。あるいは第2段階と第3段階の間に設計をマイルストーンに分け、現在のマイルストーンについてのみ BDD 項目を作って解かせることもできる
つまり結局、LLMにはウォーターフォール方式を使おうという話だ。全工程が1時間以内で終わるなら、ウォーターフォールもかなり快適に感じられる
重要なのは、プロジェクトやマイルストーンが終わったあと、エージェントが書いたコードをチャットで説明させつつ、設計時点ですでに明らかになっている内容は説明しないよう制限することだ
そうすれば、意外な部分についての説明をコードコメントへ変換させることができ、その結果は形式的でゴミのようなコメントではなく、人間が書きそうなコメントになる
ベンチマークと評価もないのに、
/create-skillより良い結果が出るとどうやって分かるのか？ 素朴なテストでは信頼できないアーキテクチャ作業を終えたとき、Claudeが根拠に基づく学習科学に基づいた、選択式の10〜15分の練習を提案するという説明がある。予測、生成、想起練習、間隔反復のような手法を使い、自分のプロジェクト作業から半完成の例を提供する方式だ
名前が紛らわしい
まだこのウサギ穴に入っていない人向けに言うと、Skillsは狭い範囲の作業をどう処理するかを説明する構造化されたMarkdownファイルだ
たとえば API エンドポイントを特定のやり方で書くなら、その手順を skill に書いておく。後でエージェントがこの skill を見て、現在のチャットコンテキストに関係があると判断したら読み込み、指示どおりに実行する
ツール呼び出しに似ているが、呼び出し可能な関数ではなく、その「スキル」を実行する方法についての指針だ
少なくとも自分が使っている Cline では、Skills をグローバルまたはプロジェクトレベルのローカルとして定義できる
CLAUDE.mdファイルのようにコンテキスト冒頭で共有されるここで聞いた話では、skill の読み込みは圧縮後にも残るなど、コンテキストに別の影響を与えることがあるらしい
複数の skill を読み込むと、セッションに永続的にロードされた状態になることもある
subagent との相性も良いと思う。subagent が skill を読み込んで作業を終え、結果だけを提示すれば、オーケストレーターエージェントはその内容を知らなくてもよい
adaptive dynamic textbook approachが正確には何なのか分からない。例が必要だ
生成されたコードを受け入れ、自分でコードを書く量を減らすと、理解を積み上げるための能動的処理を飛ばしてしまう、という話は本当にその通りだ
こんな素晴らしいアイデアを作っておきながら、デモやサンプル出力へのリンクを入れない手間をなぜわざわざかけるのか理解できない。HNで毎日見るパターンだ
この skill が実際にどう見えるのか確認するには、自分でダウンロードして実行するしかないのか？ そんなことはしたくない
無関係なときに skill を追加せず、コンテキスト肥大化を避けるという発想は理解できるが、AGENTS.md に明示的な指示がなければ、エージェントが skill を使う保証はない。そうなると、どこかに参照された Markdown ファイルと大差なくなる
https://www.agentkanban.io を作る中で、GitHub Copilot 統合タスクボードに指示をどこへ置くかをかなり試行錯誤した
AGENTS.md から1段階離れた構造はかなりうまく機能した。タスクごとの ID をエージェントに安定して拾わせる必要があったため、ツールが管理するファイル内に
INSTRUCTION.mdを置く方式に落ち着き、AGENTS.md の汚染も減らせたSkills も実験したが、あまりに頻繁にスキップされるので、今の方式ほど安定してツールを動かすのは難しかった
SKILL.mdがそこにあるのだから、読めば何をするものか分かるこのアイデアは本当に気に入った。Claudeにオープンソースの教材や文書を使わせて、その場で教材を作らせたことがある
この skill をもっと一般的な学習・応用領域に拡張できるのか、それともコードに特化したものなのか気になる
ここでの反応は興味深いが、多くは要点を取り逃しているように見える
自分にとって重要な教訓は、他の人たちがSkillsをどう使っているかを見て学ぶことにある。昨日 Matt Pocock のエージェント活用講義を見ていたら、製品要求仕様書を発展させるために “grill-me” skill を使うといった形で Skills を見せていた
彼のやり方をそのまま真似するわけではないが、要件を作って実装する方法について自分なりのアイデアは得られた
Anthropic のエンジニアたちの言い方を借りれば、Claudeは才能あるエンジニアのようだが専門性が足りない。Skills はその専門性を蓄積するフォルダとファイルなのだ
Pocock から学んだもう1つの点は、コンテキストやトークンサイズが長くなるほど応答が間抜けになる傾向があるということだ。だから Skills は、問題を圧縮した形で LLM に提示し、最適化された応答を得るためのもう1つの方法でもある
Claudeには行動特性もある。誰かが反復的に skill を作ったとしても、それが他のユーザーにうまく移植できるとは限らない。各人で Claude との会話の仕方が違うからだ
そのため、自分の skill フォルダを同僚に共有するのはためらっている。その代わり、自分が作ったものをデモとして見せ、何が可能かを見てもらって、それぞれが自分のワークフローを見つけられるようにしたい
価値があるのは、他人が Claude でどう作っているかを見て、自分なりに真似することにある。最初にプログラミングを学んだとき、Kernighan と Ritchie の C の本に載っていたコードを写経し、動作を理解しようとして変更し、後で目的に合わせて直したのと似ている
行動特性に触れたもう1つの理由は、著者が心理学者なので、Claudeとの相互作用の仕方がプログラマとはかなり異なる可能性があって興味深いからだ
関連して、著者や多分野の専門家たちはかなり前に Twitter を離れたらしいので、bsky や Mastodon を入れてフォローしようと思っている。専門家である非プログラマたちが LLM をどう使うかを観察するのは重要だと思う
良いアイデアなので、今朝いろいろ探ってみた
AIを使いすぎることで脳の流出のような感覚を強く覚えていたし、これが完全な解決策ではないにせよ、1日にいくつか練習するだけでもかなり助けになると思う