promptify

Promptify

ユーザーのリクエストを、AI モデルが活用しやすい詳細かつ正確なプロンプトに変換します。

主なタスク

ユーザーのリクエストを、曖昧さをなくし、AI モデルが望ましい出力を生成できるよう導く、明確で具体的かつ完全なプロンプトに書き換えます。出力は、くだけた自然言語ではなく、仕様を記述する言葉として扱ってください。

ワークフロー

ユーザー入力に関するルール： このスキルでユーザーの判断、希望、または確認が必要になった場合は、必ず構造化された選択肢を含む AskUserQuestion ツールを使用してください。自由記述の質問文は使用しないでください。このルールは、ステップ 2 の確認質問の経路と、ステップ 7 の提供方法の選択にも適用されます。

1. 分析

ユーザーのリクエストを注意深く読み、以下を特定します。

• 中心的な意図と望ましい結果
• 不足しているコンテキスト（対象読者、分野、環境）
• 明示されていない制約（長さ、トーン、形式）
• 期待される出力形式

2. 出力モードを決定

分析に基づいて、次のように進めます。

• リクエストが明確で完全な場合 — 直接、書き換えたプロンプトを作成します
• 軽微な不足が 1〜2 点ある場合 — [Assumption: X] のプレースホルダーを明示して補い、そのまま進めます
• 大きな不足がある場合（対象読者、範囲、技術スタックが不明）— 書き換える前に、構造化された選択肢を含む AskUserQuestion ツールを使用して確認します（自由記述の質問文は使用しません）
• 異なる目的が複数ある場合 — 個別のプロンプトに分けます

3. 構成

プロンプトを整理するため、4 ブロックのパターンを適用します。詳細は rules/structure-four-block-pattern.md を参照してください。

• コンテキスト - 背景、対象読者、分野
• タスク - AI が行うべきこと
• 制約 - 範囲、ルール、制限
• 出力形式 - 回答の正確な構成

明確さにつながる場合に限り、4 つのブロックを使用します。一般的なプロンプトの種類については、references/prompt-blueprints.md のひな形を起点にしてください。

4. 作成

rules/ のルールを適用して、プロンプトを明確にします。

• 曖昧な表現を、測定可能な要件に置き換えます
• 不足している情報をプレースホルダーまたは質問として明示します（rules/clarity-surface-missing-info.md を参照）
• 良い回答に含める内容、または避ける内容を定義する成功基準を含めます
• 前提を明示します
• 望ましい出力が本当に曖昧な場合に限り、例を追加します
• 正確な形式（見出し、箇条書きのスタイル、長さ）を指定します
• 複雑なタスクは、順序に沿った番号付きの手順に分割します

5. 自己チェック

提示する前に、ルールのチェックリスト（rules/quality-self-check.md を参照）に照らして、作成したプロンプトを確認します。

• 曖昧な修飾語がない（be-specific）
• 不足情報を明示している（surface-missing-info）
• 成功基準を定義している（include-success-criteria）
• 前提を明示している（state-assumptions）
• 形式を指定している（specify-format）
• 曖昧な場合に限り例を示している（examples-only-when-needed）
• 埋め草や過剰な丁寧表現がない（minimal-fluff）

チェックに不合格の項目があれば修正し、再確認します。チェックリストに合格するか、2 回の修正を終えるか、いずれか早い方で終了します。

6. 出力

最終的なプロンプトを、ラベルを明確に示した Markdown ブロックとしてユーザーに提示します。プロンプト以外の解説は加えないでください。

7. 提供

プロンプトを提示した後、自由記述の質問文ではなく AskUserQuestion ツールを使って、次の選択肢を示し、どのように進めるかユーザーに尋ねます。

1. 今すぐ実行 — 生成したプロンプトを新たな指示として扱い、現在の会話コンテキストに基づいて進めます。複雑なタスクは計画し、簡単なタスクはそのまま実行し、必要に応じて確認質問を行うなど、通常の判断に従って最善の次の対応を決定します。
2. ファイルに保存 — 現在の作業ディレクトリに Markdown ファイルとしてプロンプトを書き込みます（例：promptify-<timestamp>.md。<timestamp> はエポック秒です）。ファイルのパスをユーザーに伝えます。

執筆ガイドライン

構成

• 全体的なタスクを要約する短い段落を1つ最初に記述します
• 適切な箇所でのみ、セクションに見出し（##、###、####）を使用します（レベル1のタイトルは使用しません）
• 太字、斜体、箇条書き（-）、番号付きリスト（1.、2.）を十分に活用して整理します
• 絵文字は使用しません
• 箇条書きには * ではなく、必ず - を使用します

言語

• 平易で、直接的かつ正確な言葉を使用します
• 飾り立てた表現、社交辞令、創作的な言い回しは避けます
• 自然言語ではなく、仕様やコードのように言葉を扱います
• すべての指示を明確かつ具体的にします

内容

• プロンプトは簡潔にします。元のリクエストの0.75倍から1.5倍の長さにします
• 入力にない情報を追加したり、作り出したりしません
• 不要な複雑さや冗長さを避けます

例

トリガーされる例

ユーザー：「これをプロンプト化してください：調査結果のドキュメントに照らして、すべてのスキルを監査してください。」

期待される動作：promptify のガイダンスを使用し、そのワークフローに従って、実行可能な出力を返します。

トリガーされない例

ユーザー：「JSON 形式で顧客のモックデータを生成してください。」

期待される動作：promptify を優先せず、より適切なスキルを選択するか、スキルを使わずに対応します。

トラブルシューティング

スキルがトリガーされない

• エラー：期待される場面でスキルが選択されません。
• 原因：リクエストの表現が、説明に記載されたトリガー条件に明確に一致していません。
• 解決策：説明にあるドメインやタスクのキーワードを明示して言い換え、再試行します。

ガイダンスが別のスキルと競合する

• エラー：複数のスキルからの指示が、1つのタスク内で競合しています。
• 原因：読み込まれたスキルの対象範囲が重複しています。
• 解決策：現在のステップでどのスキルを優先するかを指定し、そのワークフローを先に適用します。

出力が一般的すぎる

• エラー：具体的で実行可能な詳細が出力にありません。
• 原因：タスクの入力に、コンテキスト、制約、または目標形式が不足しています。
• 解決策：具体的な制約（環境、範囲、形式、成功基準）を追加して再実行します。