Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

小森 一成(@icckx)

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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