blog.yuzu441.com

自分が使っているスキル

claude codeの色んなスキルが公開されているのを見て、自分はprivateなmarketplaceを利用しているので中々書くの難しいなと思っていたら、とある記事でスキル自体は公開していないけど、どういう分割をしているかやどういうものを定義しているかというのが参考になることに気づいたので、自分も2026/07現在のスキルを書いてみる。

スキル一覧

スキル自体の公開予定はありません。基本的に公開されているものをそのまま利用することはなく、完全自作か公開されているスキルをベースにアレンジを加えています。

git

git操作やブランチを切る時の規則、コミットメッセージの書き方などを扱うスキル。

このスキルで明示することによってコミットメッセージの生成ブレや、ブランチルールが自動で適用されるようにしている。

typescript

typescriptのコードを書く時に自分の手癖というかを再現してもらったり、reactを書く時にuseEffectは極力使わずに書きたい。そのため そのエフェクトは不要かも を意識して、使用時には他に方法が無いかを考えてくれというような事を書いている。

gitかこのスキルが2 topくらいでコールされている。

go

今までは趣味で使ったりしていたけど、最近はskillから呼び出すcliツールをgolangで作っていて、その時に生成されたコードに対してのフィードバックをスキルにしたもの。

typescriptに比べると自分に知識がないのもあり、まだ全然育ってない。

webapp-testing-for-node

claude code公式の webapp-testing を元に作ったスキル。

公式版はpythonベースに作られていたのでnodejs版で動くようにした。ただ最近は魔改造していて、@playwright/cli を使うようにしている。

create-issue

以下の事が書かれたissueを作り、後のresolve-issueでPR作らせる所までをやるための情報をAIと一緒に作る。

  • やりたいこと
  • 完了条件
  • やってはいけないこと
  • 実装のヒント(参考にして欲しい実装の情報等)
  • テスト実行などの動作確認の方法

resolve-issue

create-issueで作ったissueを元にprを作る所までやるスキル。

issueにちゃんと書いているとsonnetでも結構ちゃんと作ってくれるので、0→1をやってもらう目的で作ったが、たまにそのままマージしてる。

create-pr

prを作る時にtemplateに従って作ってくれる。git diffからprに書かないといけない内容を考えてもらっている。

templateの項目を正しく埋めるのが結構難しくて毎回粒度がバラついていたので、diffから必要な情報を拾ってもらうことで同じ水準のprを作れるようにしている。

fix-pr-review

resolve-issue等でaiが作ったコードに対してgithub prのdiff上にコメントして、その指摘を対応するためのスキル。

行単位でコメントできるので便利に使っていたけど、Rebuild.fm で紹介されていた Crit を使うと自分のレビューはpushしなくて対応できるので、導入を考えている。

trim-gh-output

ghコマンドのアウトプットがたまに大きくなるので、トークンコスト節約のためにコマンドオプションとかを利用して小さく取ってもらうためのスキル。

特に大量のログ返されがちなciログはダイジェスト返すcliツールを自作し、それが返したものを読んでもらうようにしている。

pr-review-report

レビューを行ってもらうスキル、ではなくレビュー修正の対応状況をhtml形式のレポートにしてくれるスキル。

最初はレビューをさせていたが、人間のレビュー品質再現がうまくいかず、レビューは人間が、その指摘事項が正しく解消されているかの確認をAIにさせるという方向性にしてみた。

ポジション的にタイミングによってはPRが集中するタイミングがあり、めちゃくちゃ役に立っている。

結構便利なので、通常時からよく使うようになり、トークンコスト削減のためにコメントの収集や、htmlレポートの作成等、ルール的に作れる所をAIに変わって行うcliツールも作った(結果的にはコストよりも実行時間とcontext消費しないという利点の方がcli化の効果があった)。

cost-optimize-plan

最近fableに全部やらせてみたら一瞬でtokenが溶けたので、Plan Modeで作った計画をプラン内容からopus/sonnetに割り振ってくれるスキル。

まだ作ったばかりでそこまで実績を得ていない。

plan-with-codex

Plan Modeで作ったプランに対してcodexにレビューをさせて、反論があればai同士で意見を戦わせてプランを考えるというスキル。

同じモデルに何回聞いても似た計画しか出てこないので、別のAIに反論させた方が抜けが見つかるという狙い。

github-actions-reviewer

github actionsのworkflowファイルを書いた時にtimeoutの設定等をよく書き忘れたので、レビュー用のスキルを作った。

ただ最近これはagentに切り出して、スキル自体は残しているという状態なのでめちゃくちゃ薄い。

translate-skill

実はskillディレクトリとは別にskill-jpというディレクトリを作っていて、それを原本に英訳してもらうスキル。

これで英語になることで日本語よりはトークンが少なくなるけど、descriptionは「コミットして」などの指示に反応できるように翻訳せず、日本語のままにしている。

verify-skill-change

go, typescriptスキルのように定期的にアップデートしているが、その変更がちゃんと機能しているのかを検証するためのスキル。

mizchiさんの プロンプトの再現性をAI に自動チューニングさせる方法 ~ 暗黙知を排除する の手法を参考にしている。

確率の部分があるので、複数の空agent用意して検証するの結構大事。

開発フロー

  1. create-issue スキルでissueを作成する
  2. resolve-issue スキルでissueを元にprを作成する 1
    • git スキルに従ってブランチ名、コミットメッセージ等考えさせる
  3. (作成されたprに指摘あれば) fix-pr-review スキルで指摘事項と指摘の妥当性を確認し、修正を実行
    • この時ciエラーなどもコメントしておけばciのエラーも取得して調査する

まとめ

スキルを整備した結果、自分しか使わないツールだからとか、影響は許容範囲だし必須で直してもらうほどでもないか、というような面倒で妥協してしまっていた部分も対応してもらえるようになった。

なので最近はどんどんスキル作るというフェーズでもなく、既にあるスキルをよりAIが働きやすい形に直すのが中心になっている。具体的にはトークンコスト節約のために内容を遅延読み込みにしたり、ルール的に処理できる部分をcliに切り出したりしている。

あとはclaude code前提で書いている部分がそこそこあるが、skillの仕様自体は共通なので、特定のAIに依存しない書き方にしていった方がいいよなと思って直している。

Footnotes

  1. 余談だが、このフローは元々github actions上でissueにラベルを付けると動くようにしたが、料金体系変わって使いづらくなってしまって、ローカルから実行している。