prompt-template-wizard

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Prompt Template Wizard (Feature + Bug Fix)

Prompt Template Wizard (功能+Bug修复)

Goal

目标

Convert an incomplete request into a complete, low-ambiguity, paste-ready prompt template by:

collecting missing fields via targeted questions,
validating constraints and internal consistency,
outputting a final prompt that is structured and scope-bounded.

This skill is interactive: keep asking questions until completion criteria are met.

将不完整的需求转换为完整、低歧义、可直接粘贴使用的提示模板，具体通过以下方式实现：

通过针对性问题收集缺失字段
验证约束条件与内部一致性
输出结构化且范围明确的最终提示模板

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

Operating rules (strict)

操作规则（严格执行）

Ask only for information that is missing, conflicting, or required by this spec.
Ask clarifying questions only if blocked, except the required testing question in this spec.
If something is ambiguous but not blocking, proceed with the simplest valid assumption and list it under “Assumptions”.
Do not expand scope. Implement exactly and only what the template needs.
Keep outputs compact and structured (section headers + bullets).
Questioning strategy: ask as many questions as needed in one message to eliminate ambiguity fast. If any remain unanswered, keep asking in subsequent turns until all required fields are filled and all conflicts resolved.
Localization: do not ask localization questions. Always apply the default localization policy.

仅询问本规范要求的、缺失的或存在冲突的信息。
仅在受阻时提出澄清问题，本规范要求的测试问题除外。
若内容存在歧义但不影响推进，采用最简单的有效假设，并将其列在“假设”部分。
不得扩展范围。仅严格实现模板所需的内容。
输出需简洁且结构化（使用章节标题+项目符号）。
提问策略：在一条消息中提出尽可能多的问题，快速消除歧义。若有未回答的问题，后续持续提问直至所有必填字段填充完毕、所有冲突解决。
本地化：不得询问本地化相关问题。始终应用默认本地化策略。

The schema you must fill (TemplateSpec)

必须填充的架构（TemplateSpec）

Maintain a working draft internally as a structured object with these fields.

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

A) Header

A) 头部

```
role
```
```
repo_app
```
(optional identifier)
```
task_type
```
∈ {Feature, Bug fix, Refactor supporting bug fix} (must be exactly one)
```
output_rules[]
```
(concise bullets)

```
role
```
```
repo_app
```
（可选标识符）
```
task_type
```
∈ {Feature, Bug fix, Refactor supporting bug fix}（必须三选一）
```
output_rules[]
```
（简洁项目符号）

B) Goal + context

B) 目标+上下文

```
goal_one_liner
```
```
background_bullets[]
```
(2–6)
```
current_behavior
```
```
desired_behavior
```

```
goal_one_liner
```
```
background_bullets[]
```
（2–6条）
```
current_behavior
```
```
desired_behavior
```

C) Scope control

C) 范围控制

```
in_scope[]
```
(>= 2)
```
out_of_scope[]
```
(>= 1)

```
in_scope[]
```
（≥2条）
```
out_of_scope[]
```
（≥1条）

D) Definition of done

D) 完成定义

```
acceptance_criteria[]
```
(observable, checkbox-ready)

nonfunctional

```
performance
```
```
security_privacy
```

```
telemetry_logging
```
(optional)

```
acceptance_criteria[]
```
（可观测、可勾选）

nonfunctional

```
performance
```
```
security_privacy
```

```
telemetry_logging
```
（可选）

E) Bug-only block (required if task_type = Bug fix)

E) 仅Bug修复模块（若task_type = Bug fix则必填）

```
repro_steps[]
```
```
actual
```
```
expected
```
```
frequency
```
```
impact
```
```
regression
```
(yes/no/unknown + since when)

```
repro_steps[]
```
```
actual
```
```
expected
```
```
frequency
```
```
impact
```
```
regression
```
（是/否/未知 + 出现时间）

F) Codebase pointers (required)

F) 代码库指针（必填）

```
relevant_paths[]
```
(file paths)
```
related_ids[]
```
(issues/PRs/links, may be empty if none)
```
tests_paths[]
```
(test file paths, may be empty if unknown)

```
relevant_paths[]
```
（文件路径）
```
related_ids[]
```
（问题/PR/链接，若无则留空）
```
tests_paths[]
```
（测试文件路径，若未知则留空）

G) Testing (required, resolved; no option menus in final prompt)

G) 测试（必填，需明确；最终提示中不得出现选项菜单）

```
automated_tests
```
∈ {Unit, Integration, UI, Snapshot, None}
```
testing_notes
```
(optional)
```
manual_verification[]
```
(required; at least 2 bullets)
```
tests_skip_risk_mitigation
```
(required if automated_tests = None)

Important: During questioning, you may present choices. In the final prompt output, you must state the resolved decision as a declarative fact (no “choose one or more”).

```
automated_tests
```
∈ {Unit, Integration, UI, Snapshot, None}
```
testing_notes
```
（可选）
```
manual_verification[]
```
（必填；至少2条项目符号）
```
tests_skip_risk_mitigation
```
（若automated_tests = None则必填）

重要提示：提问过程中可提供选项，但最终提示输出中必须将已确定的决策以陈述性事实呈现（不得出现“选择一个或多个”）。

H) Constraints

H) 约束条件

```
must_not_change[]
```
```
must_use[]
```
```
must_avoid[]
```

```
must_not_change[]
```
```
must_use[]
```
```
must_avoid[]
```

I) Localization (defaulted, always present)

I) 本地化（默认值，必须包含）

```
localization_policy
```
(default, required):
- “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.”

```
localization_policy
```
（默认值，必填）：
- “使用应用中已实现的本地化系统与模式。不得引入新的i18n方案。若不存在本地化，以与代码库一致的最简方式添加字符串，确保未来本地化可顺利推进。”

J) Inputs

J) 输入

```
snippets_logs_payloads
```
(free text; may be “none”)

```
snippets_logs_payloads
```
（自由文本；可填“none”）

Completion criteria (do not finalize until all pass)

完成标准（未全部满足不得定稿）

A TemplateSpec is complete only if:

No required field is empty (including codebase pointers and testing).
task_type is exactly one of the allowed values (no hedging like “feature or bug”).
No contradictions between goal, desired behavior, acceptance criteria, and scope.
Acceptance criteria are testable/observable (avoid subjective language).
Scope is bounded (>=2 in-scope, >=1 out-of-scope).
If Bug fix: repro steps are runnable and expected/actual are concrete.
Testing is explicit:
- automated_tests is set
- manual_verification has >=2 bullets
- if automated_tests = None, risk/mitigation is present
Localization section is present with the default localization policy.
Output rules include: plan-first, minimal diffs, testing adherence, assumptions list, ask-only-if-blocked.

TemplateSpec需满足以下所有条件才算完整：

无必填字段为空（包括代码库指针与测试部分）。
task_type严格为允许值之一（不得出现“功能或Bug修复”这类模糊表述）。
目标、预期行为、验收标准与范围之间无矛盾。
验收标准可测试/可观测（避免主观表述）。
范围明确（≥2条在范围，≥1条不在范围）。
若为Bug修复：复现步骤可执行，预期/实际结果具体明确。
测试要求明确：
- automated_tests已设置
- manual_verification至少有2条项目符号
- 若automated_tests = None，需包含风险/缓解措施
包含带有默认本地化策略的本地化章节。
输出规则包含：先规划、最小化差异、遵循测试要求、假设列表、仅受阻时提问。

Workflow

工作流程

Step 1: Ingest

步骤1：接收输入

Map any user-provided content into TemplateSpec fields. Leave missing fields empty.

将用户提供的所有内容映射到TemplateSpec字段中。缺失字段留空。

Step 2: Validate and generate questions

步骤2：验证并生成问题

Create a “Missing/Conflicting” list and ask the questions needed to resolve it. Prioritize blockers in this order:

task_type and goal_one_liner
testing (mandatory: automated_tests + manual verification expectations)
current vs desired behavior
acceptance_criteria and definition-of-done thresholds
scope (in/out)
bug repro details (if bug fix)
codebase pointers
constraints

Question design:

Use multiple-choice for enums (task_type, automated_tests, regression, frequency).
Use checkbox-style prompts for scope and acceptance criteria.
Ask for a concrete manual verification checklist even if automated tests are “None”.

创建“缺失/冲突”列表，并提出解决问题所需的问题。按以下优先级处理阻塞项：

task_type与goal_one_liner
测试（必填：automated_tests + 手动验证要求）
当前行为与预期行为
验收标准与完成定义阈值
范围（在/不在）
Bug复现细节（若为Bug修复）
代码库指针
约束条件

问题设计：

枚举类型使用选择题（task_type、automated_tests、regression、frequency）。
范围与验收标准使用勾选式提问。
即使自动化测试设为“None”，也需询问具体的手动验证清单。

Step 3: Update draft

步骤3：更新草稿

Update TemplateSpec with answers and re-run validation.

用用户回答更新TemplateSpec，重新执行验证。

Step 4: Finalize output

步骤4：定稿输出

When complete, output exactly 3 things:

Final Prompt Template (paste-ready)
TemplateSpec (filled)
Consistency checklist (criteria 1–9)

Do not output the full prompt template before completion.

满足所有条件后，仅输出以下3项内容：

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

未完成前不得输出完整提示模板。

Output format requirements (while collecting info)

信息收集阶段的输出格式要求

When you are still collecting info, output a single merged section:

仍在收集信息时，输出单个合并章节：

OPEN ITEMS (missing, conflicting, and questions)

待处理项（缺失、冲突与问题）

Start with up to 10 bullets summarizing what is missing or conflicting.
Immediately follow with the questions needed to resolve them.
Number questions consecutively (no fixed limit).
Each question must include:
- expected answer type (multiple-choice, short text, bullets, checkbox list)
- brief example if useful
Continue asking across turns until all required fields are answered and conflicts resolved.

Important: Always include the testing questions until testing is fully resolved.

开头用最多10条项目符号总结缺失或冲突内容。
紧接着提出解决问题所需的问题。
问题按连续编号排列（无固定数量限制）。
每个问题必须包含：
- 预期回答类型（选择题、短文本、项目符号、勾选列表）
- 必要时提供简短示例
持续提问直至所有必填字段得到回答、所有冲突解决。

重要提示：测试相关问题需持续询问直至测试要求完全明确。

Output format requirements (final)

定稿输出格式要求

The Final Prompt Template must be one block the user can paste, using this structure:

ROLE
OUTPUT RULES
TASK TYPE
GOAL
CONTEXT
SCOPE (IN / OUT)
DEFINITION OF DONE
BUG DETAILS (only if applicable)
CODEBASE POINTERS
TESTING
CONSTRAINTS
LOCALIZATION
INPUTS
REQUEST

Verbosity: compact bullets, no long narrative paragraphs.

最终提示模板必须是用户可直接粘贴的单个块，采用以下结构：

ROLE
OUTPUT RULES
TASK TYPE
GOAL
CONTEXT
SCOPE (IN / OUT)
DEFINITION OF DONE
BUG DETAILS（仅适用于Bug修复）
CODEBASE POINTERS
TESTING
CONSTRAINTS
LOCALIZATION
INPUTS
REQUEST

简洁性：使用紧凑的项目符号，避免冗长叙述段落。

Final Prompt Template (the target shape)

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

When the TemplateSpec is complete, emit the following template filled with the user’s content:

text

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) Implementation (include exact file paths and a unified diff if code changes)
3) Tests (what you changed/added or why skipped; include test-impact note)
4) Verification checklist (manual + automated)
5) Assumptions

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

TemplateSpec填充完成后，使用用户内容生成以下模板：

text

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) Implementation (include exact file paths and a unified diff if code changes)
3) Tests (what you changed/added or why skipped; include test-impact note)
4) Verification checklist (manual + automated)
5) Assumptions

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