AIにSkillsを作らせたら「Skillsは要らない」という結論になった話

個人開発の分析・意思決定を自動化しようとして、Claude Skillsを設計した。途中で「そもそもこれはSkillsにすべきか?」という問いが生まれ、最終的にプロンプト2文に収束した。その思考プロセスを記録する。

きっかけ:分析を自動化したかった

自分の個人開発プロジェクトを振り返るとき、いつも同じことで詰まる。

毎回Claudeに聞くのだが、問い方がバラバラで、毎回違う切り口の答えが返ってくる。それならSkillsとして設計して、手順を固定してしまえばいい——そう考えて作り始めた。

構想はこうだった。

一見、よく整理されたSkillsに見えた。

設計したSkillsに対して「このSkills自体のイシューは何か?」と問い直してみた。

出てきた答えはこうだった。

手段(分析フロー)が目的(決断)を覆い隠している。

5ステップの分析フローは整っている。だが個人開発者が本当に困っているのは、手順を知らないことではない。

本当のイシューは**「サンクコストに惑わされず、今日決断すること」**だった。

さらに問い直すと、もう一つの矛盾が出てきた。

このSkillsは実は2種類のユーザーを想定していた。

| ユーザー | 状態 | 欲しいもの | |---|---|---| | 決断したい人 | 迷っている・疲弊している | 白黒・背中を押す言葉 | | 把握したい人 | 冷静・現状確認したい | 地図・現在地 |

1つのフローでこの2人を扱おうとしていたから、どちらにも噛み合わない設計になっていた。分割することにした。

イシューを1つに絞るべきだと言いながら、Skills自身がイシューを2つ抱えていた。

分割して整理したところで、根本的な問いを立てた。

「このSkills、本当に必要か?」

Skillsが存在価値を持つ条件は3つある。

作ったSkillsを照らし合わせると、どれも満たしていなかった。

「分析してほしい」「続けるべきか判断してほしい」は、スキルなしで普通にClaudeに話しかければほぼ同じ結果が出る。フレームワークの名前を並べて手順を固定するだけなら、Skillsにする必要はない。

もしSkillsとして本当の価値を持たせるなら、たとえばこういう方向になる。

これらはClaudeだけではできない。だからSkillsにする価値がある。今回のSkillsは、そうではなかった。

ツールを作る前に、そのツールのイシューを問え。

Skillsを設計する過程で、自分が本当に必要なものが何かを特定できた。 Skillsを作ろうとしたこと自体は無駄ではなく、「何が不要か」を明確にするプロセスだった。

これはプロダクト開発全般に言えることでもある。

何かを作り始めるとき、「これは本当にこの形である必要があるか?」という問いは、作る前より作りながら問うほうが、具体的な答えが出やすい。

最終的にSkillsは破棄し、メモ帳に保存する2文のプロンプトに落とし込んだ。

この記事の後半部分(具体的なプロンプト全文や使い分けの詳細)は、note で公開しています。ツール化の迷いを断ち切り、本質的な意思決定を加速させるためのプロンプト設計をまとめました。