200個のGitHubリポジトリを横断調査したかった

クラメソさっぽろIT勉強会 (仮) #14 オススメの Agent Skills
https://classmethod.connpass.com/event/394411/

Transcript

1. 200個のGitHubリポジトリを 横断調査したかった 生活協同組合コープさっぽろ 2026/06/17 小森一成（@icckx） クラメソさっぽろIT勉強会 (仮) #14 〜オススメの Agent Skills〜
2. 小森 一成(@icckx)
3. 「オススメのAgentSkills」 is 自作Skillsの話 200個のリポジトリを横断調査 したかった 自作Skills gh-repo-profiler やってみて設計で学んだことを共有
4. 作成の背景と目的 Aさん「うちってどんな技術スタックがデファクトなの？」 私「エンジニア内でなんとなく、これっていう共通認識はありますね...」 Aさん「GitHubリポジトリみて調査して」 私「わかりました（AIある時代だし、なんとかなるよね）」
5. 1個ずつ人間が見て回るのは無理。だから横断で 言語 / フレームワーク / パッケージマネージャ / IaC / クラウド… SBOMじゃ細かすぎ、GitHub CLIだけじゃ情報不足... 1個ずつ、CloneしてAIに調査させる？！だるすぎ...
6. 素朴にAIに聞くと上手くいかない 抜ける（見るべきファイルを探し損ねる） 推測で埋める（ハルシネーション） 出力フォーマットが毎回バラバラ
7. 作ったもの: gh-repo-profiler owner/repo を渡すと、技術選定プロファイルを ~/repo-profiles/<owner>/<repo>.json に出力するSkills 目的は「単発の構成解説」ではなく 横断クエリ可能な判断材料を溜めること 1リポジトリ = 1 JSON、蓄積前提の設計 作り方: /grill-with-docs → /skill-creator
8. 設計の核: 素材取得は「決定的スクリプト」 LLMに「探させる」と抜ける gh CLI + tarball で マニフェスト / CI / IaC / README を機械的に回収 LLMの仕事は「集める」ではなく 「読んで構造化する」だけ
9. 設計の核: なぜ出力をJSONにしたか スキーマ固定JSONにして出力を安定化 DuckDBがそのまま読める形に、溜めたJSONを横断クエリ可能としておく Skills Skills Skills Skills Skills
10. 溜めた瞬間、問いがSQL1本に DuckDBで一発(ゴールデンSQLはSkillsのReferenceに) JSON, CSV, Parquet なんでもSQLで操作で きちゃうやつ → LLMの集計に 　確実性を与える
11. 学び: 200個は「サブエージェント」で捌く /gh-repo-profiler サブエージェントつかって処理して。 Repo1 Repo2 Repo3 … （Repo45までは平行はためした 当時 Opus4.7）
12. おまけ：レポートはHTMLで DuckDBで集計したものを Pythonでグラフにして、 LLMのの評価とかけ合わせる レポートだとHTMLは MarkDown + Mermaid より 見やすい レポート用のSkillsが 別途あると便利
13. まとめ 取得は決定的スクリプト、構造化だけLLM → 抜け・嘘を防ぐ 出力はDuckDB可読のJSON → 出力も後続の入力も安定する 大量実行はサブエージェント → 親の文脈を汚さず200個を捌く
14. 200個のGitHubリポジトリを 横断調査したかった 生活協同組合コープさっぽろ 2026/06/17 小森一成（@icckx） クラメソさっぽろIT勉強会 (仮) #14 〜オススメの Agent Skills〜