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

200個のGitHubリポジトリを横断調査したかった生活協同組合コープさっぽろ 2026/06/17 小森一成（@icckx）クラメソさっぽろIT勉強会 (仮) #14 〜オススメの Agent
Skills〜

小森一成(@icckx)

「オススメのAgentSkills」 is 自作Skillsの話 200個のリポジトリを横断調査したかった自作Skills gh-repo-proﬁler やってみて設計で学んだことを共有

作成の背景と目的 Aさん「うちってどんな技術スタックがデファクトなの？」私「エンジニア内でなんとなく、これっていう共通認識はありますね...」 Aさん「GitHubリポジトリみて調査して」私「わかりました（AIある時代だし、なんとかなるよね）」

1個ずつ人間が見て回るのは無理。だから横断で言語 / フレームワーク / パッケージマネージャ / IaC / クラウド…
SBOMじゃ細かすぎ、GitHub CLIだけじゃ情報不足... 1個ずつ、CloneしてAIに調査させる？！だるすぎ...

素朴にAIに聞くと上手くいかない抜ける（見るべきファイルを探し損ねる）推測で埋める（ハルシネーション）出力フォーマットが毎回バラバラ

作ったもの: gh-repo-proﬁler owner/repo を渡すと、技術選定プロファイルを ~/repo-proﬁles/<owner>/<repo>.json に出力するSkills 目的は「単発の構成解説」ではなく横断クエリ可能な判断材料を溜めること 1リポジトリ =
1 JSON、蓄積前提の設計作り方: /grill-with-docs → /skill-creator

設計の核: 素材取得は「決定的スクリプト」 LLMに「探させる」と抜ける gh CLI + tarball でマニフェスト /
CI / IaC / README を機械的に回収 LLMの仕事は「集める」ではなく「読んで構造化する」だけ

設計の核: なぜ出力をJSONにしたかスキーマ固定JSONにして出力を安定化 DuckDBがそのまま読める形に、溜めたJSONを横断クエリ可能としておく Skills Skills Skills Skills Skills

溜めた瞬間、問いがSQL1本に DuckDBで一発(ゴールデンSQLはSkillsのReferenceに) JSON, CSV, Parquet なんでもSQLで操作できちゃうやつ → LLMの集計に　確実性を与える

学び: 200個は「サブエージェント」で捌く /gh-repo-proﬁler サブエージェントつかって処理して。 Repo1 Repo2 Repo3 … （Repo45までは平行はためした当時
Opus4.7）

おまけ：レポートはHTMLで DuckDBで集計したものを Pythonでグラフにして、 LLMのの評価とかけ合わせるレポートだとHTMLは MarkDown + Mermaid より見やすい
レポート用のSkillsが別途あると便利

まとめ取得は決定的スクリプト、構造化だけLLM → 抜け・嘘を防ぐ出力はDuckDB可読のJSON → 出力も後続の入力も安定する大量実行はサブエージェント → 親の文脈を汚さず200個を捌く

200個のGitHubリポジトリを横断調査したかった生活協同組合コープさっぽろ 2026/06/17 小森一成（@icckx）クラメソさっぽろIT勉強会 (仮) #14 〜オススメの Agent
Skills〜

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

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

Issei.Komori

More Decks by Issei.Komori

Other Decks in Technology

Featured

Transcript