lenny-skills を Claude Code に導入する前に確認したいこと

誰のためのリポジトリか

このリポジトリが埋めようとしているのは、PM の作業を AI エージェントに任せたときの語彙と判断基準のずれである。README によれば、Lenny's Podcast と Lenny's Newsletter の全アーカイブから 597 のエピソードと記事、4,019 の出典付きインサイトを抽出し、76 のスキルとして整理している。対象はプロダクトマネジメントとエンジニアリングの実務で、採用、ユーザーリサーチ、戦略、出荷といった工程が並ぶ。

読み手として想定されているのは、Claude Code のような SKILL.md を読むエージェントを日常的に使っている人である。ゼロからフレームワークを書く代わりに、既に名前の付いた型をエージェント側に持たせたい、という動機が前提にある。逆に、プロダクトの用語を自社内で統一できているチームや、エージェントに長文の文脈を渡す運用をしていないチームにとっては、置いても使われないファイル群になりやすい。

スキルはどう読み込まれるのか

仕組みは単純である。スキルは Markdown ファイルで、エージェントに専門知識と作業手順を与える。プロジェクトに追加すると、Claude Code あるいは SKILL.md を読む任意のエージェントが、該当するタスクに取り組むときに適切なフレームワークを適用する、と README は説明している。

2.0 では構成が変わった。スキルはプロダクト組織が実際に回す工程、つまり戦略、計画、ディスカバリー、構築、ローンチ、成長、チーム、運営のケイデンスごとにグループ化され、さらに業種別のプレイブックとキャリアの道筋が加わっている。1.0 がポッドキャストのみを対象にしていたのに対し、2.0 は 349 のニュースレター記事のフレームワークとテンプレートも取り込んだ。各スキルには references/artifacts.md が付き、ゲストが実際に使っている名前付きのフレームワーク、チェックリスト、テンプレートがそこに入る。引用は出典のトランスクリプトや記事と逐語で照合されていると README は述べている。

ここで注意したいのは、このリポジトリ自体が推論や実行を行うわけではない点だ。中身はテキストであり、効果はエージェント側の読み込みと適用に依存する。

導入はコピーで完結する

インストール手順は README に明示されている。リポジトリを clone し、使いたいスキルのフォルダをプロジェクトの .claude/skills/ にコピーする。

git clone https://github.com/RefoundAI/lenny-skills.git cp -R lenny-skills/skills/writing-prds .claude/skills/

個別のスキルだけが欲しい場合は、refoundai.com/lenny-skills のダウンロードリンクから取る方法も案内されている。設定キーや環境変数は登場しない。パッケージマネージャもビルド手順もなく、必要なのはコピー先のディレクトリを正しく合わせることだけである。

この単純さは利点であると同時に、運用上の判断を利用者に丸投げしているということでもある。どのスキルを入れるか、入れたスキルを更新時にどう差し替えるかは、README の範囲では規定されていない。

76 と 86 の食い違い

リポジトリの説明文には 86 のスキルとあるが、README のバッジと本文は 76 と記載している。どちらが正しいかをこの材料から確定することはできない。v2.0.0 のリリースノートは Lenny Skills DB 2.0 という表題のみで、スキル数の内訳には触れていない。

導入を検討する立場では、この数字の不一致は実害が小さい。重要なのは総数ではなく、自分の業務に対応するフォルダが skills/ 配下に存在するかどうかである。README には戦略、計画、ディスカバリー、構築、ローンチなどの分類ごとにスキル名と出典数が表で示されているので、まずその表を自分の工程に照らして読むほうが早い。数字を成熟度の指標として扱うべきではない。

引用の検証方針と、その限界

このプロジェクトの主張で最も具体的なのは、引用を逐語で照合しているという点だ。言い換えによる意味のずれ、つまり paraphrase drift を避けると README は書いている。PM の助言は文脈依存で、要約の段階で条件が落ちると別の主張に変わってしまう。逐語にこだわる方針は、その事故を減らすための設計だと考えられる。

ただし、検証されているのは引用が原文と一致するかどうかであって、その主張が正しいかどうかではない。ポッドキャストのゲストは自社の成功体験を語っていることが多く、同じ戦術が別の市場規模や別の成長段階で機能する保証はどこにもない。エージェントが references/artifacts.md のフレームワークを提示してきたとき、それが自社の制約に当てはまるかは人間が判断する必要がある。

もう一点、README の記載は出典数を各スキルに添えている。出典数が多いスキルほど扱う論点が広いという程度の読み方が妥当で、品質の差を示すものではない。

向かない場面

このリポジトリが適さないのは、意思決定の権限や社内の固有名詞をエージェントに覚えさせたい場合である。スキルの中身は公開されたポッドキャストとニュースレターから抽出した一般的なフレームワークであり、特定企業の組織図、価格表、ロードマップを反映するものではない。

もう一つの失敗の型は、スキルを入れただけで出力が良くなると期待することだ。README の説明どおり、適用はタスクが一致したときに行われる。曖昧な依頼を投げれば、どのスキルが選ばれるかはエージェントの判断に委ねられる。writing-prds を入れたなら PRD を書く依頼だと分かる形で指示する、という使い方が前提になる。

ライセンスは MIT で、リポジトリのバッジもそれを示している。商用利用を含めて比較的自由に扱える条件だが、同梱される引用文の扱いについては、出典元であるポッドキャストとニュースレター側の条件も別途確認する必要がある。ここは法的助言ではないので、配布や再公開を伴う使い方をするなら法務に相談してほしい。

何と比べるか

比較対象として素直なのは、自前でスキルを書く運用である。違いは抽出元の有無にある。自前のスキルは自社の用語、過去の失敗、承認フローをそのまま書けるが、書く手間と更新の手間を自分で負う。lenny-skills は 597 のエピソードと記事という外部の集合知を既に構造化しており、その代わり自社固有の文脈は持たない。

もう一つの対照は、一般的なプロンプト集やナレッジベースをエージェントに読ませる方法だ。こちらは検索や要約の対象としてテキストを渡す。lenny-skills は SKILL.md という形式で、タスクに応じて適用される単位として切られている。参照資料が references/artifacts.md として分離されている点も、読む側のエージェントが段階的に開ける構造になっている。

どちらが上かという話ではない。自社の文脈を書く場所と、外部の型を借りる場所を分けて持つのが現実的で、このリポジトリは後者を埋める。

更新コストと見極め

コピーで導入する方式は、更新も同じ手作業になる。v1.0.0 が 2026-01-29、v2.0.0 が 2026-07-16 で、2.0 ではスキルの分類が工程別に再編され、ニュースレター由来の内容が加わった。分類の再編は、フォルダ構成が版をまたいで安定しないことを意味する。プロジェクトにコピーしたスキルを追従させるなら、リリースごとに差分を確認して差し替える作業が発生する。

見極めの順序はこうだ。まず自分の Claude Code が SKILL.md をどのディレクトリから読む設定になっているかを確認する。次に skills/ 配下から業務に近いフォルダを一つ選び、SKILL.md と references/artifacts.md を開いて、フレームワークの粒度と引用の長さが自分の依頼の書き方に合うかを見る。合わなければ、その部分だけ自前のスキルに置き換える。全部を入れる必要はない。

編集部の結論

プロダクトマネジメントの語彙と型をエージェントに与えたい個人や小規模チームには向く。一方、自社固有の用語や社内プロセスをそのまま反映させたい組織にはそのままでは足りない。導入前に、自分の Claude Code が SKILL.md をどのディレクトリから読むかを確認し、skills/ 配下の対象フォルダと references/artifacts.md の中身を実際に開いて、引用の粒度が自分の用途に合うかを見ておくべきである。

公式情報源

1. Issues
2. License: MIT
3. README
4. RefoundAI/lenny-skills on GitHub
5. Releases