【Claude Code】領域の違うエンジニア同士で自作スキルを見せ合ってみた【株式会社ライトコード】

今回はいつもと少し毛色の違う記事です。

同じ社内の 林さん と、 「お互いが自作した Claude Code のスキルを見せ合う」 という会をやってみました。

林さんはデータエンジニアで、普段は dbt を中心にデータ基盤を触っている方です。

iOS アプリ担当の僕とは守備範囲がまるっきり違うので、正直「話、噛み合うのかな...？」と半信半疑で臨んだんですね。

ところがこれが、想像していた3倍くらい収穫のある時間になりました！

それでは、早速見ていきましょう！

林さん、今日はよろしくお願いします！

よろしくお願いします！ こーさんが Claude Code のスキルをたくさん自作されていると聞いていたので、今日はずっと楽しみにしてきました。

ありがとうございます。とはいえ iOS と dbt ですからね。話が噛み合うのか、実は少しドキドキしてます。

私もです。ただ、領域が近い人同士だと、結局ツールの使い方の話で終わってしまう気もしていて。

たしかに。遠いほうが、考え方の部分だけが残るかもしれませんね。
 
それでは進め方です。今日のために、3つだけルールを決めてきました！

今回のルール

事前に3つだけルールを決めました。

• 自慢のスキルは1人1〜2個まで。数で殴らない。
• 「何をするスキルか」ではなく「なぜそう設計したか」を話す。
• 相手のスキルから、自分のプロジェクトに持ち帰れるものを最低1つ見つける。

特に効いたのが3つ目でした！

これがあるだけで、「へー、すごいですね」で終わる発表会ではなく、ちゃんと自分ごととして聞く会になるんですね。

ちなみに僕が自作したスキルは19本・合計およそ3,300行、林さんは10本とフック3本で約2,500行だそうです。だいたい同じくらいの規模ですね。

今日のラインナップ

先に、この記事で出てくる4本を並べておきますね。

僕（iOS アプリ）

• implement … 実装計画を読んで、実装から PR 作成までを1本で回すオーケストレーター。
• simulator-qa … iPad シミュレータを直接操作して、探索的なスモークテストを行う。

林さん（データ基盤）

• description-docify … 数万行の PR を、差分の「形」を検査して機械的に保証する。
• retro … PR の振り返りで得た教訓を、スキルやメモリに還元する。

気になるところから読んでいただいても大丈夫です！

僕の1本目：implement 〜開発ループを丸ごと1本に閉じる〜

まずは僕から。1本目は implement というスキルです。

.claude/plans/ に置いた実装計画書を読んで、実装 → テスト作成 → リント → 並列レビュー → コミット → PR 作成 までを、各ステップでユーザー承認を取りながら回してくれます。

自作スキルのほとんどを統括する、唯一のオーケストレーターですね！

設計上、特に気に入っているのは次の2つです。

1. トークン配分を設計思想として明言する

メインモデルは 計画の解釈・差分の検証・レビュー判断 に専念させて、定型実装は Claude Sonnet の implementer エージェント、テスト作成は test-writer エージェントに委譲します。

さらに、サブエージェントが2回失敗したらメインモデルが引き取る、というエスカレーション規則も入れています。

2. 進捗を計画書そのものに書き込む

終わった項目には、計画書に <!-- DONE --> マーカーを打ちます。

実際に手元の計画書7本に、合計84個のマーカーが打たれていました。

レビューで設計が変わったときは <!-- Changed: ... --> 付きで計画書自体を書き換えるので、計画と実装が静かに乖離していくのを仕組みで防げるわけですね。

スキルの中身を、ちょっとだけお見せします

implement は238行（＋エージェント定義2本で99行）あるので全部は載せませんが、一番の肝はこの表です。

#### 委譲判定

| タスクの性質 | 実行方法 |
|------|---------|
| 計画書に仕様が明確に記載された機械的なタスク | `implementer` に委譲 |
| 設計判断が残る・仕様が曖昧なタスク | メインモデルがインラインで実装 |
| 1〜2ファイルの微修正（委譲オーバーヘッドが節約分を上回る） | メインモデルがインラインで実装 |本当にこれだけです！

「いい感じに判断してね」と書いていた頃は毎回ブレていたのが、3行の表にしただけで安定しました。

そして実装が終わると、計画書のほうがこうなります。

## Step 2 データ層の実装 <!-- DONE -->



- [T03] Repository の実装 <!-- DONE -->

- [T04] エラー型の定義 <!-- DONE --> <!-- Changed: renamed per review feedback -->

- [T05] キャッシュ層の実装

次に開いたときに、どこから再開すればいいかが一目で分かるわけですね！

林さんの感想

委譲の判定表を明文化しているのがいいですね。「賢く判断してね」だと毎回ブレますし、ブレた理由も分からないので。

ブレるんですよ本当に（笑）。正直に言うと、この implement は分岐が多くて保守コストがかなり高いです。1つ直すと3か所直すことになったりします。

計画書が指示書であると同時に、状態を持つファイルにもなっているのも面白いです。

状態をどこに置くかは悩んだんですけど、人間が目で見て直せる場所に置きたくて。

それはすごく納得感があります。うちも実行状態を外のワークフロー基盤に持たせるかリポジトリに持たせるかで、毎回もめるんですよ（笑）

僕の2本目：simulator-qa 〜座標を目視で推測しない〜

2本目は毛色を変えて、simulator-qa です。

iPad のシミュレータを Claude が直接操作して、探索的なスモークテストをやってくれるスキルですね！

このスキルの原則はたった1つで、「座標を目視で推測しない」 これだけです。

スクリーンショットを見て「このへんがボタンっぽいから、だいたいここをタップ」とやると、当たり前ですが外しますし、外したことに気づかないまま先に進んでしまうんですよね。

なので、AXe の describe-ui で UI 要素の正確なフレームを取得してから操作する、というフローに固定しました。

壁を越えるために、スクリプトを3本同梱した

とはいえ、原則を決めただけでは越えられない壁がいくつかありました。

• simtype.sh：AXe の type が ASCII 前提で日本語を打てない問題を、クリップボード経由の Cmd+V で回避する。実行前後でユーザーのクリップボードを退避・復元する。
• simtap.sh / simswipe.sh：AXe が使えない環境向けのフォールバック。Accessibility API で Simulator ウィンドウの実画面領域を実測し、macOS のスクリーン座標に変換する。

ツールバーの高さやベゼルの余白を実測している理由は、スクリプトのコメントに残してあります。

半年後の自分が「なんでこんな謎の数字を引いてるんだ？」ってなるのが、目に見えていたので（笑）

スキルの中身を、ちょっとだけお見せします

simulator-qa は64行（＋スクリプト3本で152行）と小ぶりなスキルです。

…

記事の続きは下のURLをクリック！

https://rightcode.co.jp/blogs/57133

もっと上を目指したあなたへ

現在、ライトコードでは「WEBエンジニア」「データエンジニア」「ゲーム・XRエンジニア」「UI/UXデザイナー」「PM/PMO」などのポジションで積極採用中です！

ライトコードは、技術力に定評のある受託開発をメインにしているIT企業。

有名WEBサービスやアプリの受託開発などの企画、開発案件が目白押しの状況です！

• もっと大きなことに挑戦したい！
• エンジニアとしてもっと成長したい！
• モダンな技術に触れたい！

現状に満足していない方は、まずは一度、【Wantedly内の弊社ページ】をのぞいてみてください。

Wantedly：https://www.wantedly.com/companies/rightcode