GitHubのAI用の人気Skillをそのまま使わず、自分用に派生させた理由

GitHubのAI用の人気Skillをそのまま使わず、自分用に派生させた理由

GitHubのAI用の人気Skillは完成品ではなく素材でした。
そのまま入れて終わりだと汎用のままです。(それでも十分使えます。)
自分の仕事に効かせるには、削って、自分の判断基準を入れる必要がありました。

最近この感覚が強くなったきっかけが grill-me です。
最初は「便利なSkillがあるらしい」と思って見に行きました。
でも読んでみると、本当に価値があるのは機能そのものより、考えを詰める型 だと気づきました。

元のGitHub URLはここ

元ネタとして見たのは、Matt Pocock さんの skills リポジトリです。

中身はとても短いです。
でも、その短さの中に「質問し続ける」「設計木を順番に潰す」「コードベースで分かることは先に見る」「おすすめの答えも返す」が入っています。

この設計を見たとき、うまいと思いました。
ただ同時に、そのままでは自分の仕事には少し広すぎるとも感じました。

なぜそのまま使わなかったのか

理由は単純です。
私が欲しかったのは、汎用の質問役ではなく、attripの記事改善や企画整理にそのまま効く道具 だったからです。

元の grill-me は強いです。
でも強いのは、誰にでも使えるように広く作られているからです。

そこが、そのまま使うと弱さにもなります。

  • 記事改善には少し抽象的
  • SEOや読者像の視点が入っていない
  • どこから直すかの優先順位が弱い
  • 自分のブログ運営ルールまでは持っていない

つまり、便利ではあるけれど、まだ他人の道具です。
自分の現場で毎回効かせるには、もう一段自分側へ引き寄せる必要がありました。

こういうことになった理由は、ボトルネックが変わったから

前は「AIがうまく書けるか」が大きな問題でした。
でも今は、書くことや叩き台を出すこと自体はかなり速いです。

その結果、ボトルネックが変わりました。
いま詰まりやすいのは、次のほうです。

  • 誰向けに書くのか
  • 今回の勝ち筋は何か
  • 何をやらないか
  • どこから直すか

ここが曖昧なままAIに投げると、出力も曖昧になります。
だから必要だったのは、もっと賢い生成より先に、こちらの考えを狭く正確にする Skill でした。

grill-me を見て、「あ、必要なのはこれだ」となりました。
ただし、そのまま使うのではなく、自分のボトルネックに合わせて削る方向です。

実際にやったことは、フォークより先に削ることだった

最初にやったのは、壮大なSkill集を作ることではありません。
元の考え方を借りて、必要な質問だけを残すことでした。

今回 attrip 向けに作ったのはこの3つです。

  • attrip-article-grill
  • attrip-seo-grill
  • attrip-strategy-grill

やっていることは派手ではありません。
でも、仕事にはこちらのほうが効きます。

いまはGitHubの公開URLがまだないので、派生Skillの中身はこの記事の中でそのまま読める形にしておきます。
つまり、この記事自体を入口にして、何を足したのかまで追えるようにします。

たとえば attrip-article-grill では、次のような問いを先に固定しました。

  • 誰が読むか
  • その人は何を今すぐ知りたいか
  • 1文目で答えているか
  • 体験、失敗、比較のどれかが入っているか
  • H2 が具体語だけで立っているか

ここで重要なのは、質問を増やすことではありません。
自分が毎回つまずく場所だけを、先に固定すること です。

派生スキルの中身はここから見られる

3つとも、元の grill-me をそのまま増やしたのではなく、役割ごとに分けました。

派生Skill 役割 最初に見る点
attrip-article-grill 記事の弱さを詰める 誰向けか、1文目で答えているか
attrip-seo-grill 検索意図とのズレを詰める 主クエリ、タイトルと導入の一致
attrip-strategy-grill 勝ち筋と構造を詰める 誰を取りにいくか、何を捨てるか

attrip-article-grill

記事の弱さを詰めるための派生です。
読む相手、1文目の答え、具体性、離脱ポイントを先に見ます。

---
name: attrip-article-grill
description: Grill a draft or published article to expose weak claims, vague wording, reader mismatch, and missing concrete detail.
---
誰が読む記事か
その人は何を今すぐ知りたいか
1文目で答えているか
体験、失敗、比較のどれかが入っているか
H2 が具体語だけで成立しているか

attrip-seo-grill

検索意図とのズレを詰めるための派生です。
タイトル、導入、H2 の順番、内部リンクまで見ます。

---
name: attrip-seo-grill
description: Grill an attrip article from a search-intent and SERP-fit perspective.
---
主クエリは何か
読者は今すぐ知りたいのか比較したいのか
タイトルで約束した答えを冒頭で返しているか
最初の H2 が検索意図の中心を受けているか
attrip 内で次に送るべき記事はあるか

attrip-strategy-grill

書く前の勝ち筋を詰めるための派生です。
誰向けか、何で勝つか、何をやらないかを最初に切ります。

---
name: attrip-strategy-grill
description: Grill a content idea or revision plan until the winning angle, target reader, scope, and article structure are clear.
---
このテーマで誰を取りにいくか
その人は何に困っているか
attrip だから出せる視点は何か
今回の勝ち筋は1文で言えるか
捨てる論点は決まっているか

派生させると何が良くなったかは、この差を見ると早い

元の grill-me は強いです。
ただ、広く強いぶん、記事運営の現場では次の判断がまだ人間側に残ります。

見る点 元の grill-me 派生後
質問の広さ 設計全般を広く詰める 記事、SEO、戦略に分けて詰める
読者像 必要なら聞く 最初に固定する
検索意図 明示されていない SEO用の問いとして固定する
やらないこと 会話次第 戦略段階で先に切る
修正の順番 広く相談できる どこから直すかを先に決める

要するに、派生させて良くなったのは「深くなった」ことではありません。
迷う場所が先に固定されて、毎回同じ判断をしなくてよくなったこと です。

GitHubの価値は、完成品より素材にある

この件で改めて感じたのは、GitHubの価値は「すぐ使える正解」ではないことです。
むしろ、「どう設計すると強いか」の型が見えるところに価値があります。

流れで言うと、こうです。

  1. GitHubで元の設計を見る
  2. そのまま使ってみて、広すぎる部分を知る
  3. 自分の仕事に不要な部分を削る
  4. 自分の判断基準を入れる
  5. 自分専用のSkillにする

この順番なら、いきなりゼロから作るより速いです。
しかも、元の良さを残したまま、自分の現場に合う形へ寄せられます。

これからSkillを作る人に一番伝えたいこと

SkillをGitHubで見つけたとき、やりがちなのは「すごいからそのまま使おう」です。
でも本当に効くのは、その次です。

自分に必要なのは何か。
逆に何がいらないか。
毎回どこで止まるのか。

そこまで見えているなら、GitHubは倉庫ではなく武器庫になります。
完成品を集める場所ではなく、派生させるための出発点です。

私にとって grill-me はまさにそうでした。
便利なSkillを見つけた話ではなく、自分のボトルネックがどこかをやっと言葉にできた話だったと思います。

GitHubのSkillはそのままより派生で強くなる

GitHubのSkillをベースにするのは正解です。
ただし、本当に効くのはそのまま使ったときではなく、自分用に削ったときです。

  • 元URLは mattpocock/skills
  • 参考にした元ファイルは grill-me の SKILL.md
  • そのまま使わなかった理由は、汎用のままだと自分の現場では広すぎたから
  • 派生させた理由は、AIより先に人間側の判断を詰める必要があったから

GitHubでSkillを探している人は、完成品を探すより、「自分ならどこを削るか」で見ると一気に使いやすくなるはずです。

関連記事

参考

attrip

attrip

考えたことを、記事・AI・音楽に変えて発信しています。

盆栽、音楽、ブログ運営、日々の試行錯誤について書いています。

2010年から発信中

コメントを残す