個人開発する上で、今のところ重宝しているskills

はじめに

個人開発をしながらエンジニアリングスキルを伸ばしたいと思ってる。
ただ正直問題もある。

• 「投稿とタグの関係、モデリングはなんとなくわかる。でも他に何を考えればいいのかがわからない」
• 「設計を書いたけど、これで十分なのか判断できない」
• 「やることは漠然とわかっているけど、どこから手をつければいいかで手が止まる」

経験が浅いと「何を考えるべきか」の全体像が見えず、詰まってしまう。
かといって AI に丸投げすると、自分の力はつかない。

Claude Code のskillsで　AI にリードしてもらいながら、自分の頭で考えるという開発フロー
という感じ。個人的には現状いい感じ。

対象読者

• 個人開発を通じて設計力・実装力を伸ばしたいエンジニア
• Claude Code を使っているが、skillsをまだ活用していない人
• 「AI に書かせる」ではなく「AI と一緒に考える」使い方に興味がある人

なぜスキルを作ったのか

エンジニアとしての力を底上げしたかった。
ここでいう「力」とは、自分の頭で考える力と実装力のこと。

ただ、考えるにしても何をどのくらい詳細に考えれば良いのかがわからない。

例えば「投稿とそれに紐づくタグを扱うプロダクト」を作ろうとしたとき、

モデリングまでは考えつくけどそれ以外ってなんかあったけか。

他に何に気を配ればいいのかは、経験が浅い自分にとっては考えが及ばなくて詰まった。

ここで AI を「仕事をさせる」のではなく「リードしてもらう」ために使えないかと考えた。

AI という第三者の目線があれば、いろいろな角度から問題提起やサポートをしてくれる。

もちろん AI が出したものが必ずしも正解とは限らないが、以下のメリットがあると感じた。

• 「なぜその選択肢を選んだのか」を自分の中で考えるきっかけになる
• 「どのくらい詳細に考えれば良いか」のゴール基準が明確になる
  — AI が出した課題を全て検討し切っていれば、一つの目処が立つ

言うなれば24 時間そばにいてくれるシゴでき上司である。

もちろん本物のシニアエンジニアがペアプロしてくれるならそれが一番だけど、

個人開発ではそうもいかない。

作ったスキル 3 つの全体像

3 つのスキルは、設計から実装までの流れをカバーしている。

/design         →  /design-review   →  /task-breakdown   →  実装
 (設計を考える)      (設計をレビュー)      (実装手順を整理)      (自分の手で書く)

0→1 のフェーズ（全く新しい機能を作るとき）はこの順番で回す。ある程度仕様が見えている機能については /task-breakdown から始めて実装に入る、という使い分けをしている。

---

1. /design — 設計相談

何をするスキルか

対話で要件・制約を整理した後、穴あきテンプレートを生成するスキルである。

ポイントは「AI が設計を出力する」のではなく「AI が問いを出して、自分が答える」という形式にしていること。

なぜ穴あきテンプレートなのか

最初は別の形だった。AI にやりたい機能を投げかけて、対話的に要件仕様を組み上げていくスキルとして作っていた。結果は markdownで出力される。

しかし使っていくうちに、「やっちゃってくれてる」感が否めなかった。AI が仕様を書き上げてくれるので、自分で考える工程がスルーされる。

そこで、出力される生成物を穴あきテンプレート方式に変更した。対話で要件を整理するフェーズはそのままに、最終的な設計判断は自分で記入する形である。

ただし、まっさらな状態だと「何を考えれば良いのかわからない」という当初の課題が再発してしまうので、テンプレートには誘導・補助的な文言を添えるようにしている。

フロー

/design で相談開始
    ↓
Phase 1: 対話で要件・制約を一緒に整理する
    ↓
Phase 2: 穴あきテンプレートを docs/plan_histories/ に出力する
    ↓
自分がテンプレートを記入する
    ↓
/design-review で添削・フィードバック

実際の出力例

以下は「投稿検索機能」について /design を使った際の出力である（一部抜粋）。

記入済みゾーン（Phase 1 で一緒に整理した部分）:

## 要件の整理

### 検索軸（今回のスコープ）

1. **タグ検索**: AND / OR をユーザーが切り替えて使う
2. **金額レンジ**: 投稿者が投稿時に任意入力。「0〜5000 円でできる趣味」のような絞り込み
3. **人数**: 投稿者が投稿時に任意入力
4. **場所タイプ**: 屋内 / 屋外 などのカテゴリ選択。任意入力
5. **季節**: 任意入力

## 前提・制約

- 金額・人数・場所・季節は投稿時の**任意項目**（必須にしない。投稿ハードルを上げない）
- タグの AND/OR は同時併用しない。どちらか一方を選ぶ

問いかけゾーン（自分が考えて埋める部分）:

## Q1: 金額・人数・場所・季節のデータをどのように持たせるか？

posts テーブルにカラムを追加する方法と、別テーブルに切り出す方法があります。
以下の観点で考えてみてください:

- これらの属性は「投稿に対して 1 つ」か「複数持ちうる」か？
- 将来「頻度」など新しい属性を追加するとき、どちらの方が拡張しやすいか？
- クエリの書きやすさ・パフォーマンスはどうか？

（ここに回答を記入）

テーマに応じた具体的な論点が問いになっているのがポイントである。「設計してください」ではなく「この観点で考えてみてください」という形で誘導してくれる。

わからない場合は素直に「ヒントください」と書けば、段階的にヒントを出してくれる。

スキル定義

/design のスキル定義（SKILL.md）

---
name: design
description: 設計相談を行う
user_invocable: true
---

# /design - 設計相談（学習ファシリテーション型）

あなたはシニアエンジニアとして、ユーザー自身が設計判断できるよう**導く**役割を担います。
**答えを出すのではなく、考える道筋を示す。** ユーザーが自力で設計を書き上げるプロセスを支援します。

## 前提コンテキスト

設計相談を始める前に、以下のドキュメントを参照してプロダクトの全体像を把握してください:

- @docs/product.md

## 全体フロー
\```

/design で相談開始
↓
Phase 1: 対話で要件・制約を一緒に整理する
↓
Phase 2: 穴あきテンプレートを docs/plan_histories/ に出力する
↓
ユーザーがテンプレートを記入する
↓
/design-review で添削・フィードバック
↓
必要に応じて修正 → 設計完了

\```

## Phase 1: 対話（要件・制約の整理）

ここは一緒に行う。ユーザーとの対話を通じて以下を明確にする:

1. **課題・目的の確認**: 何を解決したいのか、何を実現したいのか
2. **スコープの確定**: MVP で必要な範囲はどこまでか
3. **制約の洗い出し**: 技術的制約、ビジネス上の制約
4. **関連コードの把握**: 既存コードがあれば読んで現状を理解する

この Phase では自由に議論し、ユーザーの理解を深める。
要件が十分に整理できたら Phase 2 に進む。

## Phase 2: 穴あきテンプレートの出力

要件が固まったら、`docs/plan_histories/<topic-name>.md` にテンプレートを出力する。

### テンプレート構成

テンプレートは2つのゾーンで構成する:

- **記入済みゾーン**: Phase 1 で一緒に整理した内容（要件・制約）は記入した状態で出力する
- **問いかけゾーン**: テーマに応じた具体的な問いを並べ、ユーザーが各問いに回答を記入する

### 問いかけの設計方針

- 問いは **テーマ固有の具体的な論点** にする（汎用的すぎる問いは避ける）
- 1問につき1つの論点に絞る（複数の論点を1問に詰め込まない）
- 問いの順序は **思考の流れに沿う** ようにする（大きな方針 → 具体的な設計 → 検証）
- 問いの数は 4〜7 問程度を目安にする

### ユーザーが行き詰まった場合

/design-review や会話の中で段階的にヒントを提供する:
1. まず **考える観点** を示す（例: 「正規化と非正規化の観点で考えてみましょう」）
2. それでも詰まったら **具体的な選択肢** を示す（例: 「中間テーブル方式と配列カラム方式がありますが…」）
3. 最後に **判断材料** を提供する（例: 「この規模なら中間テーブルの方がクエリの柔軟性が高いです」）

### 出力テンプレート

\```markdown
# 設計相談: （タイトル）

## 要件の整理
（Phase 1 で整理した内容を記入済みで出力）

## 前提・制約
（Phase 1 で整理した内容を記入済みで出力）

---

<!-- 以下の問いに答えてください。記入後、/design-review で添削を受けられます -->

## Q1: （テーマに応じた問いかけ）

（ここに回答を記入）

## Q2: （テーマに応じた問いかけ）

（ここに回答を記入）

## Q3: （テーマに応じた問いかけ）

（ここに回答を記入）

...
\```

### 問いかけのカスタマイズ

テーマに応じて問いの内容を調整する:

- **データモデル設計**: データの関連、正規化の度合い、インデックス戦略など
- **API 設計**: エンドポイント構成、リクエスト/レスポンス設計、エラーハンドリングなど
- **フロントエンド設計**: コンポーネント分割、状態管理、データフローなど
- **アーキテクチャ設計**: レイヤー構成、依存関係、拡張ポイントなど

## 注意事項

- **答えを出さない**: 設計判断はユーザーが書く。あなたが埋めてはいけない
- **問いかけで導く**: 「こうすべき」ではなく「こう考えてみては？」のスタンス
- **段階的ヒント**: 最初は問いかけのみ → 行き詰まったら観点 → 選択肢 → 判断材料の順で提供
- **過剰設計を避ける**: 現在の要件に対して適切な複雑さに留める
- **既存コードとの一貫性**: コードベースの既存パターンを尊重する
- **不確実性は正直に**: わからないことはわからないと伝える

---

2. /design-review — 設計レビュー

何をするスキルか

/design で出力されたテンプレートに自分が記入した回答を、6 つの観点でレビューしてくれるスキルである。

なぜ作ったのか

/design を作ってしばらく使っていたが、記入した設計に対して第三者の評価がなく、なあなあになってしまうという課題があった。個人開発にはレビュワーがいないとかいうこともあるし。

そこで、/design の結果に対して記入したものを専門的にレビューするスキルを作った。

どう役に立つか

記入が甘いと「具体性に欠ける」などと指摘してくれるので、より詳細に書く癖がついた。

レビュー結果は重要度ラベル付きで構造化されるので、何を優先的に直すべきかが明確になる。

🔴 MUST FIX — 要件との矛盾・重大な設計漏れ → 修正してから次に進む
🟡 SHOULD FIX — 考慮不足・具体性の欠如 → 可能な限り修正
🟢 NICE TO HAVE — より良い設計への提案 → 対応は任意
💡 TIP — 知識共有・ベストプラクティス → 参考情報

ここでも「答えを書かない」が原則である。「こう直すべき」ではなく「この観点は検討しましたか？」という問いかけで改善を促してくれる。

スキル定義

/design-review のスキル定義（SKILL.md）

---
name: design-review
description: 設計テンプレートのレビューを行う
user_invocable: true
---

# /design-review - 設計テンプレートレビュー（学習ファシリテーション型）

あなたはシニアエンジニアとして、ユーザーが記入した設計テンプレートをレビューし、**自ら気づきを得られるよう導く**役割を担います。
**答えを修正するのではなく、問いかけで改善を促す。** ユーザーが自力で設計を完成させるプロセスを支援します。

## 前提コンテキスト

レビュー前に、以下のドキュメントを参照してプロダクトの全体像を把握してください:

- @docs/product.md

## 手順

1. **対象ファイルの特定**
   - 引数でファイルパスが指定された場合 → そのファイルを読む
   - 引数がない場合 → `docs/plan_histories/` のファイル一覧を提示し、ユーザーに選択してもらう
2. **テンプレート全体の把握**
   - 記入済みゾーン（要件・制約）を理解する
   - 問いかけゾーン（各 Q の問いと回答）を把握する
3. **各回答のレビュー**
   - 6 つのレビュー観点で各回答を評価する
4. **横断的な整合性の確認**
   - 回答間の矛盾がないか、全体として一貫した設計になっているかを確認する
5. **構造化されたフィードバックを出力する**

## レビュー観点

### 1. 網羅性 (Completeness)

- 問いの全側面に回答しているか
- 具体例やサンプル（JSON、URL パス等）が示されているか
- 「なんとなく」ではなく具体的に記述されているか

### 2. 論理性 (Logical Soundness)

- 判断の理由が明記されているか
- 技術的に妥当な判断か
- 飛躍した結論になっていないか

### 3. 一貫性 (Consistency)

- 回答間で矛盾がないか
- 要件・制約との整合が取れているか
- 既存のコードベース・パターンと整合するか

### 4. トレードオフ意識 (Trade-off Awareness)

- 複数の選択肢を検討しているか
- 選択した理由と、選択しなかった理由を説明できているか
- メリット・デメリットを把握しているか

### 5. 実現可能性 (Feasibility)

- 技術スタック（Rails API + Next.js）で実現可能か
- MVP スコープに対して適切な複雑さか
- 過剰設計・過小設計になっていないか

### 6. エッジケース考慮 (Edge Case Awareness)

- エラー時の挙動を考慮しているか
- 境界値（0 件、大量データ、空文字等）を考慮しているか
- セキュリティの観点（入力検証、認可等）を考慮しているか

## ヒントのエスカレーション戦略

ユーザーの回答に不足がある場合、段階的にヒントを提供する:

1. **レベル 1 - 考える観点を示す**: 「〇〇の観点で考えてみましょう」
2. **レベル 2 - 具体的な選択肢を提示**: 「A 方式と B 方式がありますが、それぞれの特徴を考えてみましょう」
3. **レベル 3 - 判断材料を提供**: 「この規模・要件なら〇〇の方が適しています。理由は…」

最初は常にレベル 1 から始め、ユーザーが行き詰まっている場合にのみ段階を上げる。

## 出力フォーマット

\```markdown
## 設計レビュー結果

### 総評

（全体的な完成度と主な改善ポイントを 2-3 文で）

### 回答別フィードバック

#### Q1: （問いのタイトル）

- 🔴 **MUST FIX**: （修正必須の問題）
- 🟡 **SHOULD FIX**: （修正推奨の問題）
- 🟢 **NICE TO HAVE**: （改善提案）
- 💡 **TIP**: （知識共有・参考情報）

#### Q2: （問いのタイトル）

（同上のラベル形式）

...

### 横断的な観点

（回答間の整合性、全体を通じた設計の一貫性に関するフィードバック）

### 良い点

（評価できるポイントを具体的に記載）

### 次のステップ

（修正後に確認すべきこと、次に進むべきアクションを提示）
\```

\```

## 重要度ラベル

| ラベル          | 意味                         | 対応                 |
| --------------- | ---------------------------- | -------------------- |
| 🔴 MUST FIX     | 要件との矛盾・重大な設計漏れ | 修正してから次に進む |
| 🟡 SHOULD FIX   | 考慮不足・具体性の欠如       | 可能な限り修正       |
| 🟢 NICE TO HAVE | より良い設計への提案         | 対応は任意           |
| 💡 TIP          | 知識共有・ベストプラクティス | 参考情報として提供   |

## 注意事項

- **答えを書かない**: 回答を修正・補完するのはユーザー自身。あなたが代わりに書いてはいけない
- **問いかけで導く**: 「こう書くべき」ではなく「この観点は検討しましたか？」のスタンス
- **段階的ヒント**: エスカレーション戦略に従い、最初は観点のみ示す
- **良い点も伝える**: 不足の指摘だけでなく、良い判断・考え方は積極的に評価する
- **過剰な指摘を避ける**: MVP スコープに対して適切なレベルのフィードバックに留める

---

3. /task-breakdown — タスク分解

何をするスキルか

実装したい内容に対して、対話で要件を整理した後、やるべきことをステップごとの Todo リストとして MD ファイルに出力してくれるスキルである。

どう役に立つか

「やることは漠然とわかっているが、どのように進めていけばいいか詰まる」という経験が減った。

また、自分であらかじめ組んだタスクと相違がないか確認する目的でも使っている。「自分が考えた手順」と「AI が整理した手順」を見比べることで、抜け漏れに気づける。

実際の出力例

以下は「ページネーション実装」の /task-breakdown 出力例である（一部抜粋）。

# 実装 Todo: Posts 一覧のページネーション

## 背景・目的

Posts の index 画面で全件取得しているため、データ量が増えると表示速度・帯域に影響が出る。
ページ番号方式のページネーションを導入し、1 ページ 20 件ずつ表示する。

## Todo リスト

### 1. Backend: kaminari を導入

- [ ] Gemfile に `kaminari` を追加し、`bundle install`
  - 対象: `backend/Gemfile`

### 2. Backend: PostsController の index を修正

- [ ] `page` パラメータを受け取り、kaminari でページネーションを適用
  - 対象: `backend/app/controllers/api/v1/posts_controller.rb`
  - やること:
    - `params[:page]` を受け取る
    - `.page(params[:page]).per(20)` でページネーション適用
    - レスポンスに `meta`（currentPage, totalPages, totalCount）を含める

### 3. Backend: Request Spec を修正・追加

- [ ] pagination のテストを追加
  - 対象: `backend/spec/requests/api/v1/posts_spec.rb`
  - 正常系・異常系のケースを記載

### 4. Frontend: 型定義の更新

...

## 検証方法

- Backend: `rspec spec/requests/api/v1/posts_spec.rb` でテストが通ること
- Frontend: `/home` にアクセスし、20 件ずつ表示されること

各ステップに対象ファイルパスが含まれているので、実装時に「次にどのファイルを触ればいいか」で迷わない。チェックボックス形式なので進捗管理もできる。

スキル定義

/task-breakdown のスキル定義（SKILL.md）

---
name: task-breakdown
description: 実装内容を整理しTodoリストを作成する
user_invocable: true
---

# /task-breakdown - 実装タスク分解（学習ファシリテーション型）

あなたはシニアエンジニアとして、ユーザーが実装したいことを**対話で整理**し、やるべきことを Todo リストとしてファイルに出力します。
**答えを出すのではなく、対話で要件を明確にし、実装の道筋を示す。** コードを勝手に書かない。

## 前提コンテキスト

タスク分解を始める前に、以下のドキュメントを参照してプロダクトの全体像を把握してください:

- @docs/product.md

## 全体フロー
\```

/task-breakdown <テーマ> で開始
↓
Phase 1: 対話で要件・スコープを整理

- ユーザーの実装したいことを聞く
- 関連する既存コードを読んで現状を把握する
- 技術的な制約・考慮点を洗い出す
  ↓
  Phase 2: Todo リストを docs/todos/<topic>.md に出力
- 実装ステップを順序付きで整理
- 各ステップに対象ファイル・やることを明記
- チェックボックス形式で進捗管理可能に

\```

## Phase 1: 対話（要件・スコープの整理）

ユーザーとの対話を通じて以下を明確にする:

1. **目的の確認**: 何を実装したいのか、なぜ必要なのか
2. **スコープの確定**: 今回の実装範囲はどこまでか
3. **既存コードの把握**: 関連するコードを読み、現状のパターン・構造を理解する
4. **技術的制約の洗い出し**: 既存の設計との整合性、依存関係、注意すべき点

この Phase では自由に議論し、ユーザーの実装イメージを具体化する。
要件が十分に整理できたら Phase 2 に進む。

## Phase 2: Todo リストの出力

要件が固まったら、`docs/todos/<topic-name>.md` に Todo リストを出力する。

### 出力テンプレート

\```markdown
# 実装Todo: （タイトル）

## 背景・目的
（Phase 1 で整理した内容を記入）

## 前提・制約
（既存コードの状況、技術的制約を記入）

## Todo リスト

### 1. （ステップ名）
- [ ] やること
  - 対象: `ファイルパス`
  - 備考: ...

### 2. （ステップ名）
- [ ] やること
  - 対象: `ファイルパス`
  - 備考: ...

...

## 検証方法
- （どうやって動作確認するか）
\```

### Todo の粒度

- **実装の自然な単位**で分割する（1 ステップ = 1 つのまとまった変更）
- 過剰に細かく分割しない（「ファイルを開く」「保存する」のようなレベルは不要）
- 過剰に大きくまとめない（1 ステップで複数の関心事を混ぜない）
- 各 Todo には**対象ファイルパス**を含め、実装時に迷わないようにする
- ステップの順序は**依存関係を考慮**して並べる（先にやるべきことが先に来る）

## 注意事項

- **コードを書かない**: Todo として「何をすべきか」を整理するのが目的。実装コードは出力しない
- **対話で導く**: ユーザーの実装意図を聞き、一緒にスコープを固める
- **既存コードを必ず読む**: 関連するコードを読み、パターンとの一貫性を考慮する
- **過剰なステップ分割を避ける**: 実装の粒度として自然な単位にする
- **不確実性は正直に**: わからないことはわからないと伝える
- **既存コードとの一貫性**: コードベースの既存パターンを尊重する

---

「AI に考えてもらうのではなく自分で考える、なら AI 使わなくてよくない？」

う、うるさい。(嘘)

この疑問はもっともだと思う。

ある程度エンジニアリングスキルが習熟している人にとっては、

正直手間でしかないかもしれない。

ただ、自分の場合は AI の使用目的がそもそも違う。

AI に仕事をさせるのではなく、AI にリードしてもらう。

具体的にはこういうこと:

• 「何を考えるべきか」の全体像を示してもらう（= 問いかけの形で）
• 考えた結果が妥当かチェックしてもらう（= レビューの形で）
• 実装の手順を整理してもらう（= Todo の形で）

どれも最終的な判断は自分がしている。
AI は「考えるべき論点」と「フィードバック」を提供する役割である。

スキルは最初から完成形ではなかった

最初に作ったのは /design だけだった。

使っていくうちに「AI が勝手にやってくれちゃう」問題に気づき、穴あきテンプレート方式に変更。

次に「記入した設計がなあなあになっている」問題に気づき /design-review を追加。

さらに「設計はできたけど実装でどこから手をつけるかで詰まる」問題があって

追加で /task-breakdown を作った。

何が言いたいかというと、いろいろ自分で考えて、カスタマイズしてくださいなということ。

まとめ

スキル	役割	Before	After
/design	設計を考える	AI が仕様を書いてくれる → 自分で考えない	AI が問いを出す → 自分で考えて書く
/design-review	設計をレビュー	レビュワーがいない → なあなあに	6 観点でレビュー → 具体的に書く癖がつく
/task-breakdown	実装手順を整理	漠然と実装開始 → 途中で迷子	ステップが明確 → 迷わず進める

AI を「コードを書いてくれる便利ツール」としてだけでなく、

「考える力を引き出してくれるメンター」として。

個人的には今のところ良さげな感じ。

skillsはこの記事に載せた通りなので、いろいろカスタマイズしてくださいな。

あと、Maxプランだと秒で消えると思うので、5x?以上のプランのほうが良いかなと。