ハコヅミを作る #4：Claude Code のスキル /issue と /implement を作って使ってみた

プログラミング

前回（#3）で、Issue → 実装 → PR → 受入 → 本番リリースを一周しました。 今回は、その手順を Claude Code のスキルにした話です。

開発プロセスの記事では、「Claude Codeへの具体的な指示の出し方やスキルの中身は、キャンプアプリで実際に使ってから開発記録の中で書く」と予告していました。その回です。

なぜ、このタイミングでスキルにしたのか

スキルは、よく使う指示を .claude/skills/<名前>/SKILL.md に書いておき、/名前 で呼び出せるようにする仕組みです。

最初から作ることもできましたが、一周目が終わるまで待ちました。理由は2つあります。

  • 一周してみないと、書くことが決まらなかった：Closes ではなく Refs を使う、PRにACとテストの対応表を書く、E2Eのデータの名前を重ならないようにする。どれも一周目で分かったことです
  • 今なら、細かい点を覚えている：次の機能を進めたあとだと、忘れてしまいます

どちらのスキルもGitHubにIssueやPRを作る操作をするので、自分が呼んだときだけ動くように設定しました。Claudeが自分の判断で呼び出すことはありません。

---
name: implement
description: GitHub Issue を読み、ブランチ作成から実装・テスト・PR 作成まで進める（マージはしない）
argument-hint: <Issue 番号>
disable-model-invocation: true   # 人が呼んだときだけ動く
---

/issue：メモから Issue を作る

/issue ギアの編集と削除。一覧からギアを選んで編集できる。削除もできる

のように、ざっくりしたメモを渡すと、次の順に進みます。

  1. プロジェクトの設計（CLAUDE.md）と、既存のIssueを確かめる
  2. テンプレートに沿って、背景・仕様・AC・対象外の下書きを書く
  3. 下書きと「決めてほしい点」を見せて、止まる
  4. 確認を受けてから、Issueを作る

3で止まるのが一番大事なところです。ACを最終的に決めるのは自分なので、確認なしにIssueが作られると困ります。

実際に出てきた「決めてほしい点」

ギアの編集と削除では、次のような点を聞かれました。

  1. 削除は、行を消す（物理削除）でよいか
  2. 状態を「所有」以外に変えると一覧から消え、画面からは戻せなくなるが、よいか
  3. 編集画面への入口は、製品名のリンクでよいか
  4. 編集と削除を1つのIssueにまとめてよいか
  5. 削除の確認は、ブラウザ標準の確認ダイアログでよいか

2は、自分では見落としやすい点です。状態で絞り込む機能は次のIssueに回すことにして、「この時点では戻せない」と対象外の欄に明記してもらいました。

/implement：Issue から PR まで進める

/implement 15

Issue番号を渡すと、次の順に進みます。

  1. 準備：GitHubのアカウント、develop が最新かを確かめ、Issueとコメントを読む。ACが曖昧なら、実装に入る前に質問して止まる
  2. 実装：プロジェクトの規約に沿って書く（型アサーションを使わない、クエリは必ず user_id で絞る、など）
  3. テスト：ACごとに、ユニットテストかE2Eテストを書く。整形・型チェック・Lint・テストがすべて通るまで直す
  4. セルフレビュー：チェックリストで確かめる
  5. コミットとPR：Refs #番号 を付け、PRの本文にACとテストの対応表を書く
  6. 報告して止まる：マージはしない

スキルだけで、ギアの編集・削除を作った

/issue で作ったIssueを、そのまま /implement 15 で進めてもらいました。

ギアの編集画面。製品名・メーカー・カテゴリ・状態の入力欄、保存ボタン、区切り線の下に削除ボタンがある

/implement で作ったギアの編集画面。削除ボタンは、うっかり押さないよう保存から離して一番下に置いた

画面は、この記事の時点のコードを手元で動かして撮ったものです。データは#7でNotionから取り込んだ、実際のギアを入れています。

途中で止まって質問されることもなく、ブランチの作成、実装、7つのACに対応するE2Eテスト、PRの作成まで一気に進みました。PRの本文には、ACごとにどのテストで確かめたかの表が付いています。

セルフレビューでは、チェックリストの「型アサーションがないか」「クエリが user_id で絞られているか」を、目で読むのではなく grep で機械的に確かめていました。確実で、手早いやり方です。

自分がやったのは、PRを読んで理解してマージすることと、開発環境で触って「受入OK」と伝えることだけです。

使いながら直したところ

スキルは、作って終わりではなく、使いながら直していくものだと考えています。ここまでで、次の点を直しました。

画面から確かめられないACに「（自動テストで確認）」と書く

コンテナとギアを紐づける機能で、「他のユーザーのコンテナを指定して保存しようとすると、保存されない」というACがありました。 受入確認をしようとして気づいたのですが、これは画面を触っても確かめられません。今は自分しか使っていないので、「他のユーザー」のデータがないからです。

このACは、E2Eテストで確かめていました。テストの中で他人のコンテナをDBに入れ、画面を通さずに直接リクエストを送って、保存されないことを見ています。

そこで、次のようにしました。

  • /issue：画面から確かめられないACは、末尾に「（自動テストで確認）」と書く
  • /implement：PRの本文に、そのACを確かめるテストのファイルと、何を確かめているかまで書く
  • 受入確認では、「触って確かめるAC」と「テストの中身を読んで確かめるAC」を分ける

つまずいたことを、手順に足していく

実装中につまずいたことも、次に同じことで迷わないよう、/implement の手順に足しています。 たとえば、D1でテーブルを作り直すマイグレーションの注意点や、E2Eテストの書き方です（それぞれ#5、#6で書きます）。

CLAUDE.md がプロジェクトの「決まりごと」だとすると、スキルは「手順書」です。どちらも、つまずくたびに少しずつ育てています。

AIに任せる部分と、自分が手放さない部分

実際に使ってみた分担は、次のとおりです。

作業 自分 Claude Code
Issueのメモ 一言で書く 下書きにする。決めてほしい点を挙げる
AC 最終的に決める 候補を出す。抜けを指摘する
実装・テスト・PR 確認する 書く（/implement）
レビュー 読んで理解してからマージする 先にセルフレビューする
受入判断 開発環境で触って決める 結果を見て、IssueのACにチェックを付けて閉じる

開発プロセスの記事で考えていた分担が、ほぼそのまま回っています。 違ったのは、思っていたより「決めること」が多かった点です。スキルが「決めてほしい点」を必ず挙げてくれるので、判断を忘れることがなくなりました。

おわりに

スキルにしてよかったのは、毎回同じ手順を、同じ品質で踏めることです。 「Issueを読んでから実装する」「PRには Refs を付ける」といったことを毎回頼まなくても、スキルが覚えています。

スキルは今のところハコヅミのリポジトリの中にあります。共通方針どおり、2つ目のサービスを作るときに、実際に役立った部分だけを共通として切り出すつもりです。

次回は、コンテナとギアを紐づけるときの、D1でのマイグレーションの話です。

← トップページに戻る