メニュー
作業依頼のプロンプトを、現在のセッションモデルの公式プロンプティングベストプラクティス (references/ に同梱) に沿って書き直し、ユーザ承認後にそのプロンプトで作業を続行する。「プロンプトを最適化して」「ベストプラクティスに沿ったプロンプトにして」「プロンプトを整えてから進めて」「/prompt-refine <プロンプト>」などで起動。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/skanehira/dotfiles --skill prompt-refineコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
実装ループ。/dev-spec が作成した GitHub issue (ゴール / 設計参照 / DoD / 非スコープ / 依存の thin 構成) を入力に、依存順に 1 件ずつ「implementer subagent → 統合レビュー → 修正 ≤2 ラウンド → PR → DoD ローカル実行 → merge → close」で自律実装するオーケストレーター。進捗は issue コメントに残し、詰まった issue は needs-human で駐車して次へ進む。人間の介入はエスカレーション時のみ。issue 作成後にユーザーが直接起動し、エスカレーション回答後の再開も本スキルの再実行で行う。「実装ループを開始」「issue を順に実装して」「残りタスクを自動で実装」などで起動。
設計ループ。ユーザーストーリー → UI スケッチ → ユースケース → 実現可能性検証 → PoC 検証 → 横断設計 (docs/design/DESIGN.md) → 機能設計 (docs/design/features/) → 設計チェック → issue ドラフトチェック → GitHub issue 生成 (親子構造) までを対話的に実行し、人間が issue を確認して実装ループへ引き渡す。 「設計フェーズを開始」「要件を整理したい」「計画を立てたい」「ユーザーストーリーを書きたい」 「技術的に実現できるか確認したい」「機能設計を書きたい」「issue に落としたい」などで起動。 docs/design/ の状態から途中再開・特定フェーズの部分実行も可能。 `cli` / `webapp` のプロダクトモード指定で CLI ツール開発時は UI スケッチ等を軽量化できる。 issue 作成後、/dev-impl がそれを 1 件ずつ実装する。
dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。
SOC 職業分類に基づく
SKILL.md を表示中
| name | prompt-refine |
| description | 作業依頼のプロンプトを、現在のセッションモデルの公式プロンプティングベストプラクティス (references/ に同梱) に沿って書き直し、ユーザ承認後にそのプロンプトで作業を続行する。「プロンプトを最適化して」「ベストプラクティスに沿ったプロンプトにして」「プロンプトを整えてから進めて」「/prompt-refine <プロンプト>」などで起動。 |
| argument-hint | <作業依頼のプロンプト> |
作業依頼のプロンプトを、いま動いているセッションモデル向けの公式プロンプティングガイドと突き合わせて書き直し、ユーザの承認を得てからそのプロンプトで作業を続行する。
$ARGUMENTS があればそれを対象にするsystem prompt に記載されている自分のモデル ID を見て、下表に従い該当する reference ファイルを Read する。
| モデル ID パターン | 読む reference |
|---|---|
claude-fable-5 系 / mythos 系 | references/fable-5.md |
claude-opus-5 系 | references/opus-5.md |
claude-opus-4 系 (4.8 等) | references/opus-4-8.md |
claude-sonnet-5 系 | references/sonnet-5.md |
| 上記以外 (haiku 等、専用ページなし) | references/general.md (汎用フォールバック) |
reference に書かれているパターン・注意点と、対象プロンプトの内容を照合し、そのプロンプトに実際に関係する観点だけを適用対象として選ぶ。
reference は「そのモデルで起こりがちな挙動のズレ」を列挙したものであり、チェックリストではない。全項目を機械的に全部盛りしない。例えば短い単発タスクのプロンプトに、長時間自律実行やメモリシステムの指示を追加する必要はない。
ユーザにしか決められない情報 (ゴールの曖昧さ、動作検証の手段、スコープ境界など) があれば AskUserQuestion で確認する。
逆に、会話履歴やリポジトリから一意に決まる情報は自動で埋め、その選択と根拠を出力に明示する。ユーザが意図との乖離に気づける状態を保つ。
書き直したプロンプト全文と、「どの observation をなぜ適用したか」の簡潔な要約を通常のテキストでユーザに提示したうえで、末尾に番号付き選択肢を テキストで 質問する（AskUserQuestion は使わない。ダイアログ UI がプロンプト全文の表示スペースを圧迫し、ユーザが書き直し内容を確認できなくなるため）。
1. このまま続行 — 書き直したプロンプトを正式な作業依頼として作業を開始する
2. 修正したい — フィードバックを踏まえて [4/6]〜[6/6] をやり直す
3. プロンプトだけ受け取る — 作業は開始せず、書き直したプロンプトの提示のみで終了する
各 reference は取得時点のスナップショットであり、公式ドキュメントの更新には自動追従しない。内容が古いと感じたら以下で再取得する (各ファイル冒頭に取得元 URL と取得日をコメントで記載している)。
curl -fsSL https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-fable-5.md > references/fable-5.md
curl -fsSL https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-opus-5.md > references/opus-5.md
curl -fsSL https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-opus-4-8.md > references/opus-4-8.md
curl -fsSL https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-sonnet-5.md > references/sonnet-5.md
curl -fsSL https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/claude-prompting-best-practices.md > references/general.md