コーディングエージェント用のスキルを入れるとき、配布元が渡してくるファイルと、公開リポジトリにあるファイルが同じものだと確かめていますか。確かめていない人がほとんどだと思います。私たちもそうでした。
今朝、ByteDance の Lark（飛書）ドキュメント操作スキル lark-doc について、その確認を実際にやってみました。結果として、自分たちが 8 月に公開した記事の誤りが 1 つ見つかりました。手順とあわせて共有します。所要時間は 30 秒ほどです。
結論
飛書が自社ドメインから配信している lark-doc の SKILL.md は、MIT ライセンスの GitHub リポジトリ larksuite/cli にある skills/lark-doc/SKILL.md とバイト単位で同一でした。どちらも 4,192 バイト、49 行、SHA-256 は 2786f910370662069b1b52b98508033c84baaf0bd7b0bae177426ece4ceafacc です。いずれも 2026 年 9 月 13 日に取得しました。
30 秒でできる検証手順
curl と shasum だけで足ります。
- 配布元から渡されたファイルをハッシュ化する。
curl -sS https://open.feishu.cn/.well-known/skills/lark-doc/SKILL.md | shasum -a 256
# 2786f910370662069b1b52b98508033c84baaf0bd7b0bae177426ece4ceafacc
- GitHub API で現在の HEAD の SHA を取る。ブランチ名のまま引用してはいけません。
curl -sS "https://api.github.com/repos/larksuite/cli/commits?per_page=1" | jq -r '.[0].sha'
# 39aaf9fca0e08825b51f6d8c6c617bf781db761b
- その SHA を指定して同じパスを取得する。
curl -sS "https://raw.githubusercontent.com/larksuite/cli/39aaf9fca0e08825b51f6d8c6c617bf781db761b/skills/lark-doc/SKILL.md" | shasum -a 256
-
diffを取る。一致すればコミット固定の permalink で引用できます。一致しない場合は、著者が今なにを書いているかという意味でリポジトリ側が正です。そして差分そのものが調べる価値のある情報になります。
飛ばされがちなのは手順 2 です。main を指した permalink は、誰かがそのファイルを触った次の瞬間から引用行がずれます。しかも、ずれたことは誰も教えてくれません。
ついでにレスポンスヘッダも見ておくとよいです。配布元のエンドポイントには ETag も Last-Modified もありませんでした。つまり、この配信面には固定できるバージョン情報が存在しません。
同じファイルなのに、掲載が 2 つある
lark-doc は 2 つの経路で配布されていて、レジストリは両者を別々に数えています。
| ベンダードメイン経由 | GitHub 経由 | |
|---|---|---|
| インストールコマンド | npx skills add https://open.feishu.cn --skill lark-doc |
npx skills add https://github.com/larksuite/cli --skill lark-doc |
| 累計インストール数 | 663,945 | 439,469 |
| 数値の基準日（掲載ページ表記） | 2026 年 9 月 12 日 | 2026 年 9 月 7 日 |
| リポジトリの star 表示 | なし | 17k |
どちらの数値も skills.sh レジストリのもので、2 つのページはいずれも 2026 年 9 月 13 日に読み取りました。差は 224,476、比にするとベンダー経由が GitHub 経由の約 1.5 倍です。
ただし、この 2 つを足してはいけません。Skillselion の Lark Doc スキル紹介ページには、2026 年 9 月 13 日時点で次の注記が表示されています。
This is a copy of lark-doc by larksuite - installs and ranking accrue to the original listing.
観測できるのは、カタログが経路ごとに別レコードを持っていること、レジストリがそれぞれに違う数値を返していることまでです。1 件のインストールがどちらに計上されるかは外からは見えないので、合計値は出しません。
名前空間をまたいだ完全一致の複製は珍しくありません。私たちはエージェントスキルの複製調査レポート（2026 年 8 月 12 日時点で凍結）で 79,848 件の掲載を突き合わせ、3,443 件を複製と判定しました。この複製群が 26,061,541 インストール、全体の 15.8% を占めます。判定基準は SKILL.md がバイト単位で一致すること、つまり今回 lark-doc が満たした条件そのものです。なお、複製由来のインストールのうち 35.0% は、他人のスキルを盗んだものではなく、自分のスキルを複数経路に出している公開元によるものでした。
ファイルの中身は何をしているのか
コミット 39aaf9f 時点で skills/lark-doc/ にあるのは 44 ファイルです。内訳は SKILL.md が 1 つ、リファレンスが 15、references/genres/ 配下の文書ジャンル別テンプレートが 28。SKILL.md 本体は 49 行しかなく、やっていることはほぼルーティングだけです。リポジトリ全体では SKILL.md を持つディレクトリが 28 あり、star は 17,151、fork は 1,381、ライセンスは MIT でした（GitHub API、2026 年 9 月 13 日取得）。
frontmatter は依存関係を散文ではなく機械可読なメタデータとして宣言しています。
metadata:
requires:
bins: ["lark-cli"]
skills: ["lark-shared"]
出典: skills/lark-doc/SKILL.md, frontmatter, commit 39aaf9f, 2026 年 9 月 13 日取得
バイナリ 1 つと兄弟スキル 1 つ。インストーラがディスクに何か書く前に検証できる形です。README の途中に「事前に X を入れておいてください」と書いてあるだけ、という状態とは違います。
本文の最初の指示はドキュメント操作の話ではなく、コンテキスト消費の話です。
**CRITICAL：先判断场景，再读取该场景的参考文件；不要在任务开始时一次性读取全部参考文件。每个文件只在首次进入对应阶段时读取一次。**
出典: skills/lark-doc/SKILL.md, "场景与 Shortcut 路由", commit 39aaf9f, 2026 年 9 月 13 日取得
訳すと「CRITICAL: まずシナリオを判断し、そのシナリオの参照ファイルだけを読むこと。タスク開始時に参照ファイルを一度に全部読んではいけない。各ファイルは対応する段階に最初に入ったときに一度だけ読む」。49 行のルータの背後に 43 個の参照ファイルがぶら下がっている構成なので、この 1 行が設計そのものです。
ファイル中で一番いい行は、ゼロから文書を作るときのルーティング項目にあります。
- **从零创作 — [`创建工作流`](references/lark-doc-create-workflow.md)**：先完整执行创建工作流，**简单任务不是跳过的理由**；
出典: skills/lark-doc/SKILL.md, "文档内容", commit 39aaf9f, 2026 年 9 月 13 日取得
「簡単なタスクであることは、手順を飛ばしてよい理由にならない」。エージェントが「これくらい簡単だから」と判断して壊れた成果物を出すところを、書いた人は見たのだと思います。
認証の扱いも面白くて、多くのスキルとは逆向きです。共有認証スキルを事前に読み込まず、auth status --verify も事前実行しない。未認証・トークン・ID・スコープのいずれかでエラーが出たときに初めてそのスキルを読み、直してリトライする。大半のスキルは毎回の認証チェックのコストを払い続けますが、これは失敗したときだけ払います。
8 月の記事から 1 行だけ変わっていた
私たちの解説記事は 2026 年 8 月 20 日時点で引用を検証しています。その直前の変更である 525a98270f80693bdaf3c0a6006e9f3f94820851（2026 年 8 月 14 日）と現在の HEAD を diff すると、変更されているのは 19 行目の 1 行だけでした。ローカルファイルのパス解決ルールです。
@path 参照をカレントディレクトリ基準にすると述べた 1 文が、探索順序、XML ソースファイルのディレクトリへのフォールバック、そしてフォールバックを行わない入力（インライン内容、stdin、オンライン文書）の明示まで含む 4 節構成に書き換わっていました。この変更が入ったのはコミット 9a29abea、2026 年 9 月 9 日です。ファイルサイズは 4,009 バイトから 4,192 バイトになり、行数は 49 行のままでした。
このルールからは、行間を推測するまでもなく 2 点が読み取れます。ローカル参照の範囲が CWD 基準の相対パスだけから、ディスク上の任意の絶対パスまで広がったこと。そして同名ファイルが衝突したときは、作業ディレクトリ側が黙って優先されることです。
こちらのカタログ側のコピーは、いまも古いほうの行を表示しています（2026 年 9 月 13 日に掲載ページを読んで確認）。4 日遅れです。引用の前に必ず上流を取り直す、というルールを持っているのはこのためで、今日の自分たちのミスもそのルールが見つけました。
訂正
8 月の記事には「このスキルには公開リポジトリがない」「固定できるコミット履歴がない」と書いてあります。どちらも誤りでした。skills/lark-doc/SKILL.md は 2026 年 3 月 28 日から公開リポジトリに存在します。lark-cli を Lark / 飛書 の公式 CLI として OSS 化したコミットで、以後このファイル 1 つに 40 件のコミットが入っています。
原因は平凡です。配布元の .well-known エンドポイントを見てバージョン情報がないことを確認し、そこで探すのをやめました。ファイル中の特徴的な 1 行で GitHub を検索していれば 30 秒で見つかったはずです。記事の引用自体は今も有効ですが、出典の注記は誤りなので、こうして訂正します。一覧はディープダイブ記事の一覧ページにあります。
入れるべきか
チームのドキュメントが Lark や飛書にあるなら入れる価値があります。ただし、このスキル単体ではなくスイートで入れてください。lark-doc はファイル単位の操作とコメントを意図的に扱わず、そこは Lark Drive スキルの紹介ページにあるスキルの担当です。表計算と Base のデータ操作も範囲外です。
なお、導入前にひとつ。GitHub 経由の掲載ページには、skills.sh の監査結果として「セキュリティ監査: 3 つのスキャナのうち 2 つが通過」と表示されています（2026 年 9 月 13 日に確認）。それ自体が危険信号というわけではありませんが、本番環境に入れる前にそのページの Security Audits パネルに目を通してください。
Lark を使っていないなら不要です。CLI バイナリからルーティング対象の URL 形式まで、すべて ByteDance のエコシステム前提で書かれています。
どちらにせよ、入れるなら GitHub 経由を選ぶのが無難です。中身は同じで、以後の変更を diff で追えます。用語そのものが初見ならエージェントスキルの用語解説ページに平易な定義を置いてあります。リポジトリ、star 数、セキュリティ監査の結果は larksuite/cli 版 Lark Doc の紹介ページで確認できます。
次にスキルを入れるとき、上の 4 コマンドを試してみてください。30 秒で終わりますし、「誰にも検証できないファイルを引用してしまう」状態を防げるのはこれだけです。
検証環境: larksuite/cli のコミット 39aaf9fca0e08825b51f6d8c6c617bf781db761b、および配布元の SKILL.md（いずれも 2026 年 9 月 13 日取得）。インストール数は各掲載ページが表示している基準日つきの数値です。中国語からの訳は私たちによるものです。Skillselion は独立したディレクトリであり、ByteDance、Lark、Anthropic、OpenAI、Cursor とは提携関係にありません。