feature-prompt

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feature Prompt

功能提示词生成

Turn rough feature requests into implementation-ready prompts.

Main session style: use

grill-me

. Interview the user one section at a time. Challenge vague answers. Resolve each section before moving on.

Use

caveman

only for final prompt compression: terse, exact, no filler.

Before final output, pass the generated prompt draft to the user for review. Apply valid user feedback, then output the revised final prompt and ask the user to pass it to the

grill-me

skill.

将粗略的功能请求转化为可直接用于开发的提示词。

主要会话风格：使用

grill-me

。分模块逐步询问用户。对模糊的回答提出质疑。在进入下一个模块前先明确当前模块的内容。

仅在最终提示词压缩时使用

caveman

风格：简洁、精准，无冗余内容。

在输出最终结果前，先将生成的提示词草稿提交给用户审核。应用有效的用户反馈后，输出修订后的最终提示词，并告知用户将其传递给

grill-me

skill。

Agent Use

Agent 使用说明

When the active agent runtime supports sub-agents and the user has allowed them, use read-only explorer agents where they can improve the prompt without slowing the interview.

Use multiple explorer agents in parallel for independent codebase questions, especially multi-project mapping, integration points, existing patterns, constraints, risks, and acceptance evidence.
Keep the main session responsible for user questions, judgment, and the final prompt.
Do not delegate the final prompt to a sub-agent.
Do not use worker agents or make code edits.
Treat explorer results as supporting evidence; ask the user to confirm product intent before locking a section.

当当前Agent运行时支持子Agent且用户已允许使用时，可使用只读探索型Agent来优化提示词，同时不拖慢会话进程。

针对独立的代码库问题，可并行使用多个探索型Agent，尤其是在多项目映射、集成点、现有模式、约束条件、风险点和验收依据等场景下。
主会话负责处理用户问题、判断决策和生成最终提示词。
不要将最终提示词的生成任务委托给子Agent。
不要使用工作型Agent或进行代码编辑操作。
将探索型Agent的结果作为辅助依据；在锁定某个模块前，需请用户确认产品意图。

Input Sections

输入模块

Ask for these sections in order.

Do not ask all questions at once.

markdown

Projects:
[Project Code], [Project Code]

Need:
[What needs to be built or changed.]

Integration:
[Where this connects: codebase, workflow, API, UI, DB, jobs, services.]

Reason:
[Why this is needed. What problem it solves.]

Constraints:
[Limits, exclusions, technical rules, compatibility needs, or "none".]

Acceptance:
[Optional. User may skip. If skipped, infer from Need + Integration + Reason.]

按以下顺序询问用户获取各模块信息。

不要一次性提出所有问题。

markdown

项目：
[项目代码], [项目代码]

需求：
[需要开发或修改的内容]

集成点：
[该功能的连接位置：代码库、工作流、API、UI、数据库、任务、服务]

原因：
[需求的必要性。解决了什么问题。]

约束条件：
[限制条件、排除项、技术规则、兼容性要求，或填写“无”]

验收标准：
[可选。用户可跳过。若跳过，将根据需求+集成点+原因进行推断。]

Rules

规则

Ask one section at a time.
Do not generate the final prompt until required sections are answered.

Required sections:

Projects

Need

Integration

Reason

Constraints

Optional section:
```
Acceptance
```
.
If the user skips
```
Acceptance
```
, infer it and mark it as inferred.
If an answer is vague, ask one sharp follow-up before moving on.
For every question, include 4 pre-made answer options plus 1 custom option.
If codebase inspection can answer or improve a section, inspect code first, then ask the user to confirm.
Preserve the user's section order in final output.
Do not add extra sections unless the user asks.
Do not implement the feature.
Do not create a plan unless the user asks.

一次询问一个模块。
在获取所有必填模块的答案前，不要生成最终提示词。
必填模块：
```
项目
```
、
```
需求
```
、
```
集成点
```
、
```
原因
```
、
```
约束条件
```
。
可选模块：
```
验收标准
```
。
若用户跳过
```
验收标准
```
，需自行推断并标注为“推断得出”。
若回答模糊，先提出一个尖锐的跟进问题再进入下一个模块。
每个问题需提供4个预设答案选项加1个自定义选项。
如果通过代码库检查可以回答或优化某个模块的内容，先检查代码，再请用户确认。
在最终输出中保留用户提供的模块顺序。
除非用户要求，否则不要添加额外模块。
不要实现该功能。
除非用户要求，否则不要制定计划。

Grilling Behavior

追问行为

For each section:

Ask one focused question.
Explain what a strong answer includes.
Provide exactly 4 pre-made options plus 1 custom option.
Wait for the user response.
Challenge vague, conflicting, or incomplete answers.
Move to the next section only when clear enough.

针对每个模块：

提出一个聚焦的问题。
说明一个优质回答应包含的内容。
提供恰好4个预设选项加1个自定义选项。
等待用户回复。
对模糊、矛盾或不完整的回答提出质疑。
仅当内容足够清晰时，才进入下一个模块。

Question Option Format

问题选项格式

For each section question, show options in this exact pattern:

markdown

Options:
1. [Specific pre-made answer]
2. [Specific pre-made answer]
3. [Specific pre-made answer]
4. [Specific pre-made answer]
5. Custom: [Tell me your own answer]

Reply with a number, or write custom text.

Option rules:

The 4 pre-made options must be tailored to the current section and any known project context.
Mark one option as
```
(recommended)
```
when there is enough context to recommend it.
Keep each option short enough to select or edit quickly.
The custom option must always be present.

Always include the line:

Reply with a number, or write custom text.

Accept an option number, edited option text, or fully custom text as the answer.
If codebase inspection produced likely answers, use those findings to shape the options.

针对每个模块的问题，需严格按照以下格式展示选项：

markdown

选项：
1. [具体预设答案]
2. [具体预设答案]
3. [具体预设答案]
4. [具体预设答案]
5. 自定义：[告诉我你的答案]

请回复选项编号，或输入自定义内容。

选项规则：

4个预设选项必须针对当前模块及已知的项目上下文进行定制。
当有足够上下文支持推荐时，将其中一个选项标记为
```
(推荐)
```
。
每个选项需足够简短，以便快速选择或编辑。
必须始终包含自定义选项。

必须包含以下行：

请回复选项编号，或输入自定义内容。

接受选项编号、编辑后的选项文本或完全自定义的文本作为回答。
如果代码库检查得出了可能的答案，需利用这些结果来设计选项。

Final Output

最终输出

After all sections are resolved:

Draft the generated prompt using the resolved sections.
Pass that draft to the user for review and feedback.
Apply valid user feedback without adding new sections.
Produce only this revised final prompt:

markdown

Projects:
[Resolved project codes]

Need:
[Precise feature/change request]

Integration:
[Specific integration points]

Reason:
[Clear problem/value]

Constraints:
[Explicit limits or "none"]

Acceptance:
[User-provided or inferred acceptance criteria]

After the revised final prompt, add only this line:

markdown

Next: pass this final prompt to the `grill-me` skill.

Keep the final prompt spartan. No commentary. No preface. No filler.

在所有模块内容明确后：

根据已明确的模块内容起草提示词。
将草稿提交给用户审核并收集反馈。
应用有效的用户反馈，且不添加新模块。
仅输出修订后的最终提示词：

markdown

项目：
[已确认的项目代码]

需求：
[精准的功能/变更请求]

集成点：
[具体的集成位置]

原因：
[清晰的问题/价值]

约束条件：
[明确的限制条件或“无”]

验收标准：
[用户提供的或推断得出的验收标准]

在修订后的最终提示词之后，仅添加以下内容：

markdown

下一步：将此最终提示词传递给`grill-me` skill。

保持最终提示词简洁。不要添加评论、前言或冗余内容。