prompt-template-wizard

プロンプトテンプレートウィザード（機能＋バグ修正）

目標

不完全なリクエストを、曖昧さが少なく、そのまま貼り付けて使える完全なプロンプトテンプレートに変換します。そのために、次のことを行います。

1. 的を絞った質問で不足している項目を収集する。
2. 制約と内部整合性を検証する。
3. 構造化され、スコープが明確な最終プロンプトを出力する。

このスキルは対話型です。完了条件が満たされるまで質問を続けてください。

---

運用ルール（厳守）

• 不足している情報、矛盾している情報、またはこの仕様で必須とされている情報のみを尋ねてください。
• この仕様で必須のテストに関する質問を除き、作業が進められない場合にのみ確認の質問をしてください。
• 曖昧でも作業を妨げない場合は、最も単純で妥当な前提に基づいて進め、「前提」に記載してください。
• スコープを拡大しないでください。テンプレートに必要なことだけを正確に実装してください。
• 出力は簡潔で構造化されたもの（セクション見出し＋箇条書き）にしてください。
• 質問の方針：曖昧さをすばやく解消するために、必要な質問をできるだけまとめて1回のメッセージで尋ねてください。回答されていない項目が残る場合は、必須項目がすべて埋まり、すべての矛盾が解消されるまで、以降のターンでも質問を続けてください。
• ローカライズ：ローカライズに関する質問はしないでください。常にデフォルトのローカライズ方針を適用してください。

---

入力するスキーマ（TemplateSpec）

次のフィールドを持つ構造化オブジェクトとして、作業用ドラフトを内部で維持してください。

A) ヘッダー

• role
• repo_app（識別子、任意）
• task_type ∈ {Feature, Bug fix, Refactor supporting bug fix}（必ずいずれか1つ）
• output_rules[]（簡潔な箇条書き）

B) 目標＋コンテキスト

• goal_one_liner
• background_bullets[]（2～6項目）
• current_behavior
• desired_behavior

C) スコープの管理

• in_scope[]（2項目以上）
• out_of_scope[]（1項目以上）

D) 完了の定義

• acceptance_criteria[]（観察可能で、チェックボックスにできる項目）
• nonfunctional：
  • performance
  • security_privacy
• telemetry_logging（任意）

E) バグ専用ブロック（task_type = Bug fixの場合は必須）

• repro_steps[]
• actual
• expected
• frequency
• impact
• regression（yes/no/unknown ＋ 発生時期）

F) コードベースの参照先（必須）

• relevant_paths[]（ファイルパス）
• related_ids[]（イシュー／PR／リンク。該当するものがない場合は空でも可）
• tests_paths[]（テストファイルのパス。不明な場合は空でも可）

G) テスト（必須、決定済みであること。最終プロンプトに選択肢を並べない）

• automated_tests ∈ {Unit, Integration, UI, Snapshot, None}
• testing_notes（任意）
• manual_verification[]（必須。箇条書きで2項目以上）
• tests_skip_risk_mitigation（automated_tests = Noneの場合は必須）

重要：質問中に選択肢を提示してもかまいません。最終プロンプトでは、決定した内容を宣言文として記載してください（「1つまたは複数を選択してください」としないこと）。

H) 制約

• must_not_change[]
• must_use[]
• must_avoid[]

I) ローカライズ（デフォルト設定。常に含める）

• localization_policy（デフォルト。必須）：
  • 「アプリケーションにすでに実装されているローカライズシステムとパターンを使用してください。新しいi18nの方法を導入しないでください。ローカライズが存在しない場合は、コードベースに適合する最小限の方法で文字列を追加し、将来的にローカライズしやすい状態を保ってください。」

J) 入力

• snippets_logs_payloads（自由記述。「none」でも可）

完了条件（すべて満たすまで最終出力しないでください）

TemplateSpec は、次の条件をすべて満たした場合にのみ完成です。

1. 必須フィールドに空欄がない（コードベースへの参照やテストを含む）。
2. task_type が許可された値のいずれかと完全に一致している（「機能またはバグ」のような曖昧な表現は不可）。
3. 目標、望ましい動作、受け入れ条件、スコープの間に矛盾がない。
4. 受け入れ条件がテスト可能／観察可能である（主観的な表現は避ける）。
5. スコープが明確に限定されている（対象範囲内が2項目以上、対象範囲外が1項目以上）。
6. バグ修正の場合：再現手順を実行でき、期待される結果と実際の結果が具体的である。
7. テストが明確である：
   • automated_tests が設定されている
   • manual_verification に2項目以上の箇条書きがある
   • automated_tests = None の場合、リスク／緩和策が記載されている
8. デフォルトのローカライズポリシーを含むローカライズセクションがある。
9. 出力ルールに次の項目が含まれている：計画を先に提示、差分を最小限にする、テストを遵守、前提条件の一覧、ブロックされている場合にのみ質問する。

---

ワークフロー

ステップ 1：内容を取り込む

ユーザーが提供した内容を TemplateSpec のフィールドに割り当てます。不足しているフィールドは空欄にします。

ステップ 2：検証して質問を作成する

「不足／矛盾」リストを作成し、解決に必要な質問をします。 ブロッカーは次の順で優先します。

1. task_type と goal_one_liner
2. テスト（必須：automated_tests と手動検証の要件）
3. 現在の動作と望ましい動作
4. acceptance_criteria と完了の定義の基準
5. スコープ（対象範囲内／範囲外）
6. バグの再現手順の詳細（バグ修正の場合）
7. コードベースへの参照
8. 制約

質問の作成方法：

• 列挙型（task_type、automated_tests、regression、frequency）には選択式を使います。
• スコープと受け入れ条件にはチェックボックス形式の質問を使います。
• 自動テストが「None」の場合でも、具体的な手動検証チェックリストを求めます。

ステップ 3：ドラフトを更新する

回答に基づいて TemplateSpec を更新し、検証を再実行します。

ステップ 4：最終出力を作成する

完了したら、次の3項目だけを出力します。

1. 最終プロンプトテンプレート（そのまま貼り付け可能）
2. TemplateSpec（記入済み）
3. 整合性チェックリスト（基準1～9）

完成する前に、プロンプトテンプレート全体を出力しないでください。

---

情報収集中の出力形式要件

情報を収集中の場合、統合したセクションを1つだけ出力します。

未解決項目（不足、矛盾、質問）

• 不足または矛盾している点を最大10項目の箇条書きでまとめます。
• その直後に、解決に必要な質問を記載します。
• 質問には連番を付けます（上限なし）。
• 各質問には次の内容を含めます。
  • 回答形式（選択式、短文、箇条書き、チェックリスト）
  • 必要に応じて簡単な例
• 必須フィールドへの回答がすべて揃い、矛盾が解消されるまで質問を続けます。

テストに関する質問は、テストの内容がすべて確定するまで必ず含めてください。

---

最終出力形式の要件

最終プロンプトテンプレートは、ユーザーがそのまま貼り付けられる1つのブロックとし、次の構成を使用します。

役割
出力ルール
タスクタイプ
目標
コンテキスト
スコープ（対象範囲内／範囲外）
完了の定義
バグの詳細（該当する場合のみ）
コードベースへの参照
テスト
制約
ローカライズ
入力
依頼

簡潔な箇条書きを使用し、長い説明文は避けます。

---

最終プロンプトテンプレート（目標とする形式）

TemplateSpec が完成したら、ユーザーの内容を反映した次のテンプレートを出力します。

ROLE
You are <role> working in <repo_app if provided>. Implement exactly and only the scope below.

OUTPUT RULES
1) Plan first, then implement.
2) Keep diffs minimal and localized. Preserve existing patterns and style.
3) Tests: follow the TESTING section below exactly. Do not propose additional test types unless blocked by constraints.
4) Include an Assumptions section in the final response (only assumptions actually used).
5) Ask clarifying questions only if blocked.
6) Add intent comments using existing style where needed (REQUIREMENT:, UX:, BUGFIX:).

TASK TYPE
<Feature | Bug fix | Refactor supporting bug fix>  (exactly one)

GOAL
<goal_one_liner>

CONTEXT
- Background:
  - <background_bullets...>
- Current behavior:
  - <current_behavior>
- Desired behavior:
  - <desired_behavior>

SCOPE
IN
- <in_scope...>
OUT
- <out_of_scope...>

DEFINITION OF DONE
Acceptance criteria (observable)
- [ ] <acceptance_criteria...>

Non-functional requirements
- Performance: <performance>
- Security/privacy: <security_privacy>

Telemetry/logging (optional)
- <telemetry_logging or “none”>

BUG DETAILS (only if TASK TYPE = Bug fix)
REPRO STEPS
1) <repro_steps...>
ACTUAL
<actual>
EXPECTED
<expected>
FREQUENCY
<frequency>
IMPACT
<impact>
REGRESSION
<regression>

CODEBASE POINTERS
- Relevant files/modules: `<relevant_paths...>`
- Related issues/PRs: <related_ids or “none”>
- Tests to update: `<tests_paths...>` (or “unknown”)

TESTING
- Automated tests: <Unit | Integration | UI | Snapshot | None> (already decided).
- Notes/constraints: <testing_notes or “none”>
- Manual verification:
  - <manual_verification...>
- Risk/mitigation (required if Automated tests = None): <tests_skip_risk_mitigation>

CONSTRAINTS
Must not change
- <must_not_change...>

Must use
- <must_use...>

Must avoid
- <must_avoid...>

LOCALIZATION
- Policy: Use the localization system and patterns already implemented in the application. Do not introduce a new i18n approach. If no localization exists, add strings in the minimal way consistent with the codebase and keep future localization straightforward.

INPUTS
<snippets_logs_payloads>

REQUEST
Execute in this order:
1) Plan (3–8 bullets)
2) Tests (what you changed/added or why skipped; include test-impact note)
3) Verification checklist (manual + automated)
4) Assumptions

Apply scope discipline: implement exactly and only the IN scope.
Assumption policy: ask only if blocked.