prompt-master を読む: Claude スキルでプロンプトを書き直す仕組みと限界

誰の何を減らすのか: 再プロンプトの往復

README が挙げる問題は明確で、曖昧なプロンプトを投げ、出力がずれ、書き直し、またずれる、という往復である。README はこれを「attempt 4」でようやく欲しい答えに届く例として説明し、その間の API 呼び出しを無駄と位置づける。対象読者は、Claude、ChatGPT、Codex、Grok、Gemini、Cursor、Claude Code、GitHub Copilot、Midjourney、Stable Diffusion、Sora、ElevenLabs、Zapier など複数のツールをまたいで指示を出す人である。ここで押さえておきたいのは、このスキルが出力を生成するのではなく、出力を生成させるための指示文を生成するという一段挟まった位置にあることだ。したがって節約されるのはモデルの推論コストではなく、書き直しの回数そのものであり、効果は「1 回で当たる率」に依存する。README はこの率を数値で示していない。

8 段階のパイプラインで何が起きるか

README の「How It Works」は処理を 8 項目に分けている。まず対象ツールを判定し、適切なアプローチへ黙って振り分ける。次に意図を 9 次元（task、input、output、constraints、context、audience、memory、success criteria、examples）で抽出する。不足が致命的な場合に限り、最大 3 問の確認質問を出す。続いてプロンプト設計の型を選んで適用するが、これはユーザーには見せないと明記されている。適用する技法として role assignment、few-shot examples、XML 構造、grounding anchors、memory block が挙げられ、「safe techniques only」と修飾されている。6 番目が他と性格を異にする。リクエストが「最新」に依存する場合、公式のプロバイダドキュメントに対してモデル名と制御パラメータの鮮度を確認するという工程である。7 番目で出力を変えない語を削るトークン効率の監査を行い、最後にコピー可能な 1 ブロックと 1 行の戦略メモを返す。注目したいのは 6 番目と 7 番目で、前者はモデル名の陳腐化という現実的な失敗を潰しにいっており、後者は「最良のプロンプトは最長のものではない」という README の主張を工程として実装した形になっている。

導入は ZIP アップロードか git clone か

README は 2 つの経路を示し、片方を推奨、もう片方を「Not Suggested」と明示している。推奨は Claude.ai のブラウザからで、リポジトリを ZIP としてダウンロードし、claude.ai のサイドバーから Customize、Skills、Upload a Skill と進んでアップロードする。もう一つは Claude Code のスキルディレクトリへ直接 clone する方法で、README のコマンドは次のとおり。

mkdir -p ~/.claude/skills git clone https://github.com/nidhinjs/prompt-master.git ~/.claude/skills/prompt-master

設定キーや環境変数の類は README には一切出てこない。パスは ~/.claude/skills/prompt-master のみである。呼び出し方は自然言語と明示の 2 系統が用意されている。自然言語の例としては「Write me a prompt for Cursor to refactor my auth module」のように依頼する形、明示の例としては /prompt-master の後に改行して要件を書く形が示されている。README が clone を非推奨にしている理由は書かれていない。推測は避けるが、更新のたびに手動で pull する必要が出る点を嫌っている可能性はある。いずれにせよ、どちらの経路でもスキル本体のファイル構成や依存関係は README からは分からない。

出力例が示す設計思想: 記述子の羅列と仕様の明文化

README には完全な入出力例が 2 つ載っている。1 つ目は Midjourney 向けで、入力は「雨の夜に立つリアルな侍」のプロンプトを書いてほしいという一文。出力はカンマ区切りの記述子を並べ、末尾に --ar 16:9 --v 6 --style raw を付け、negative 行で blurry、low quality、watermark、cartoon、anime、extra limbs を除外する形になっている。README 自身の解説によれば、狙いは散文より記述子の羅列、照明とムードを前方に固定、アスペクト比とバージョンの固定、ネガティブ指定によるスタイルの漂流防止である。2 つ目は Claude Code 向けで、Notion 風のランディングページを作らせる指示である。こちらは様相がまったく違い、Objective、Stack、Design Spec、Sections to build in order、Animations、Constraints、Done When という見出しで構成され、背景色 #ffffff、本文色 #1a1a1a、罫線色 #e5e7eb、フォント Inter の 400/500/600/700、基本スペーシング 8px、角丸 6px（カード）と 4px（ボタン）、影は 0 1px 3px rgba(0,0,0,0.08) のみ、といった値が列挙される。セクションは 8 つを順序付きで指定し、アニメーションは IntersectionObserver の threshold 0.15、duration 500ms ease-out、カードのスタッガー 100ms といった実装レベルまで踏み込む。制約として単一 HTML ファイル、埋め込み CSS と JS、Google Fonts 以外の外部依存なし、375px と 1440px の両方でピクセル単位の一致、と畳みかける。同じスキルが、画像向けには短い記述子の束を、コード向けには仕様書に近い長文を返している。これが 4 番目の工程「型の選択」の実体だと考えられる。

確認できない部分と、確認すべき前提

ここは率直に書く。README は具体的な出力例を 2 つ示しているが、スキル本体がどう実装されているかは分からない。SKILL.md に相当するファイルがあるのか、複数ファイル構成なのか、プロンプトのテンプレートをどこかに持つのかは、与えられた情報からは判断できない。9 次元の抽出や 8 段階のパイプラインが、モデルへの指示として書かれているのか、外部スクリプトで処理されているのかも不明である。6 番目の「公式ドキュメントに照らしてモデルの鮮度を確認する」工程も、Claude がその場で Web を見に行く前提なのか、モデル名の一覧を静的に持つのかで挙動が変わるが、記述は無い。トークン数の表示（例では「Light (~60)」）が実際の計測値なのか概算ラベルなのかも、README からは読み取れない。同様に、スキルがどの入力で自動起動し、どの入力では起動しないのかというトリガー条件は書かれていない。導入を決める前に、自分の環境で /prompt-master が認識されるか、日本語の依頼でも同じパイプラインが走るかを試す価値がある。README の例はすべて英語であり、日本語入力時の挙動についての記述は存在しない。

ライセンスと更新の追跡コスト

ライセンスは MIT と明示されている。商用利用や改変、再配布の可否については MIT の条文そのものが定めるところであり、ここで法的な助言はしない。実務上気にすべきは条文より運用で、README にはバージョン番号もリリースノートも CHANGELOG も無い。リポジトリの最終 push は 2026-08-24 と記録されているが、これはタグ付けされたリリースを意味しない。Claude.ai にアップロードした ZIP は、元リポジトリが更新されても自動では変わらない。手元のスキルがどの時点のものかを知る手段が README には用意されていないため、更新を取り込むには ZIP を落とし直して再アップロードするか、clone したディレクトリで git pull してからアップロードし直すことになる。clone を README が非推奨としている以上、推奨経路を選ぶと更新は手作業になる。プロンプト設計の型はモデルの世代交代で陳腐化しやすいので、この更新コストは無視できない。

代わりに何を使うか: 手書きテンプレートとの比較

現実的な比較対象は、競合製品ではなく、自分で持っているプロンプトのテンプレート集である。違いは明確だ。テンプレート集は静的なテキストで、対象ツールごとに 1 枚ずつ用意し、人間が空欄を埋める。prompt-master は対象ツールを判定し、9 次元のうち欠けている情報を最大 3 問で聞き返し、型を選び、トークン効率の監査まで通す。つまり判断の一部をモデルに委ねる。手書きテンプレートの利点は、git で差分を追え、レビューでき、CI で検証できることにある。prompt-master の出力はチャット上の 1 ブロックで、README の例を見る限りファイルとして保存されるわけではない。逆にテンプレート集の弱点は、対象ツールが増えるたびに人が書き足す必要がある点で、README が挙げる 20 以上のツール名を列挙しているのはこの弱点への対処と読める。どちらが優れているかではなく、判断をモデルに渡すか、リポジトリに固定するかの違いである。チームで同じプロンプトを再現したいなら後者、個人が多数のツールへ都度書き分けるなら前者が向く。

どんなときに使わないほうがよいか

最初に挙げるべきは、出力の再現性が要件になっている場面である。prompt-master は毎回モデルが意図を解釈してプロンプトを組み立てるため、同じ依頼から同じ文字列が出る保証は README には書かれていない。プロンプトをテスト対象にしているチームには向かない。次に、プロンプトが長大になることを避けたい場面。README のコーディング例は Design Spec から Done When まで含む相当な分量で、これは「短くする」ではなく「曖昧さを消す」方向の最適化である。対象モデルのコンテキスト上限が厳しい場合は、生成されたプロンプト自体を削る作業が別途必要になる。3 点目は、社外に出す指示文を統制したい場合。型の選択がユーザーに見えないと README が明記している以上、どの技法が適用されたかを事後に監査するのは難しい。4 点目は、Claude 以外を主軸にしている場合。このスキルは Claude に読み込ませて使うものであり、ChatGPT や Gemini 用のプロンプトを生成することはできても、それらの環境でスキルとして動くわけではない。

編集部の結論

向いているのは、Claude.ai を日常的に使い、Cursor や Claude Code、Midjourney など複数のツールへ同じ意図を配り直す回数が多い人である。向かないのは、プロンプトをコードとしてリポジトリで管理し、差分レビューや自動テストの対象にしたいチームで、このスキルはファイルを生成せずチャット上でテキストを返すだけに見える。採用前に確認すべきは、ZIP をアップロードした後にスキルがどのトリガーで起動するか、/prompt-master の明示呼び出しが自分の環境で動くか、そして生成されたプロンプトを自分の手元で一度実行して意図どおりの出力が返るかである。README にはバージョン番号も CHANGELOG も無く、更新があったときに何が変わったかを追う手段が提示されていない点も、導入前に把握しておきたい。

公式情報源

1. Issues
2. License: MIT
3. nidhinjs/prompt-master on GitHub
4. README