prompt-template-wizard

提示词模板向导（功能 + Bug 修复）

目标

将不完整的请求转化为完整、歧义少、可直接粘贴的提示词模板，具体方法如下：

1. 通过有针对性的问题收集缺失字段，
2. 验证约束条件和内部一致性，
3. 输出结构清晰且范围明确的最终提示词。

此技能为交互式技能：持续提问，直至满足完成标准。

---

操作规则（严格）

• 只询问本规范要求或缺失、冲突的信息。
• 除非遇到阻碍，否则只在本规范要求时提出澄清问题。
• 如果某项存在歧义但不构成阻碍，采用最简单的有效假设继续，并将其列在“假设”下。
• 不要扩大范围。严格且仅实现模板所需内容。
• 输出应简洁且结构清晰（章节标题 + 项目符号）。
• 提问策略：在一条消息中尽可能多地提问，以快速消除歧义。如果仍有未解答的问题，则在后续轮次继续提问，直至所有必填字段均已填写且所有冲突均已解决。
• 本地化：不要询问本地化相关问题。始终采用默认本地化策略。

---

必须填写的架构（TemplateSpec）

在内部将工作草稿维护为包含以下字段的结构化对象。

A) 标题

• role
• repo_app（可选标识符）
• task_type ∈ {Feature，Bug fix，Refactor supporting bug fix}（必须且只能选一个）
• 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) 仅适用于 Bug 的部分（当 task_type = Bug fix 时为必填）

• repro_steps[]
• actual
• expected
• frequency
• impact
• regression（是/否/未知 + 起始时间）

F) 代码库指引（必填）

• relevant_paths[]（文件路径）
• related_ids[]（Issue/PR/链接；没有时可留空）
• tests_paths[]（测试文件路径；未知时可留空）

G) 测试（必填，且须明确；最终提示词中不得提供选项菜单）

• automated_tests ∈ {Unit，Integration，UI，Snapshot，None}
• testing_notes（可选）
• manual_verification[]（必填；至少 2 项）
• tests_skip_risk_mitigation（当 automated_tests = None 时必填）

重要：提问时可以提供选项。输出最终提示词时，必须以陈述事实的方式写明已确定的决定（不得使用“选择一个或多个”）。

H) 约束

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

I) 本地化（始终存在，默认填写）

• localization_policy（默认值，必填）：
  • “使用应用中已有的本地化系统和模式。不要引入新的 i18n 方案。如果不存在本地化机制，请以符合代码库的最精简方式添加字符串，并确保便于将来进行本地化。”

J) 输入

• snippets_logs_payloads（自由文本；可填写“无”）

完成标准（全部通过前请勿定稿）

只有满足以下条件，TemplateSpec 才算完整：

1. 所有必填字段均非空（包括代码库指针和测试）。
2. task_type 必须严格为允许值之一（不得使用“功能或 Bug”之类模棱两可的表述）。
3. 目标、期望行为、验收标准和范围之间不得存在矛盾。
4. 验收标准必须可测试／可观察（避免主观表述）。
5. 范围有明确边界（范围内 >=2 项，范围外 >=1 项）。
6. 如果是 Bug 修复：复现步骤必须可执行，预期结果和实际结果必须明确具体。
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. Bug 复现详情（如果是 Bug 修复）
7. 代码库指针
8. 约束

问题设计：

• 枚举项（task_type、automated_tests、regression、frequency）使用多选题。
• 范围和验收标准使用复选框形式的提示。
• 即使自动化测试为“None”，也要询问具体的手动验证清单。

步骤 3：更新草稿

根据回答更新 TemplateSpec，并重新运行验证。

步骤 4：输出最终内容

完成后，严格输出以下 3 项：

1. 最终提示词模板（可直接粘贴）
2. TemplateSpec（已填写）
3. 一致性检查清单（标准 1–9）

完成前不要输出完整提示词模板。

---

收集信息期间的输出格式要求

仍在收集信息时，输出一个合并的部分：

待处理事项（缺失内容、冲突和问题）

• 开头列出最多 10 条要点，概述缺失或冲突之处。
• 随后立即提出解决这些问题所需的问题。
• 问题按顺序连续编号（数量不限）。
• 每个问题都必须包含：
  • 预期回答类型（多选、简答、要点、复选框列表）
  • 有用时提供简短示例
• 持续在后续轮次中提问，直到所有必填字段均已回答且所有冲突均已解决。

测试问题必须始终保留，直到测试内容完全明确。

---

最终输出格式要求

最终提示词模板必须为一个可供用户直接粘贴的区块，并使用以下结构：

角色
输出规则
任务类型
目标
背景
范围（范围内／范围外）
完成定义
Bug 详情（仅适用时）
代码库指针
测试
约束
本地化
输入
请求

详细程度：简洁要点，不要写冗长的叙述段落。

---

最终提示词模板（目标格式）

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.