메뉴
作業依頼のプロンプトを、現在のセッションモデルの公式プロンプティングベストプラクティス (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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? 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