Back to Details

feature-prompt-full

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Feature Prompt Full

Feature Prompt Full

Turn rough feature requests into an implementation-ready prompt and prepare the downstream feature chain.
This is the full variant of 
feature-prompt
. It keeps the same section-by-section clarification flow, then directs the user through:
  1. /grill-with-docs
  2. /to-prd
  3. /to-issues
  4. /tdd
将粗略的功能需求转换为可用于落地的提示词，并准备好后续的功能开发流程。
这是
feature-prompt
的完整版本。它保留了分阶段梳理的流程，之后会引导用户完成以下步骤：
  1. /grill-with-docs
  2. /to-prd
  3. /to-issues
  4. /tdd

Chain Approval

流程确认

Before asking feature questions, show the chain suggestion and get user approval.
Use this exact shape:
markdown
Suggested chain:
1. `/feature-prompt-full` - clarify the feature and produce the final prompt.
2. `/grill-with-docs` - challenge the prompt against docs, domain language, ADRs, and codebase context.
3. `/to-prd` - convert the reviewed context into a PRD/spec.
4. `/to-issues` - split the PRD into independently implementable vertical slices.
5. `/tdd` - implement each issue with red-green-refactor.

Approve this chain before I start, or tell me what to change.
Do not begin the section interview until the user approves the chain.
在询问功能相关问题前，需向用户展示建议的流程并获得确认。
请严格使用以下格式：
markdown
Suggested chain:
1. `/feature-prompt-full` - 梳理功能需求并生成最终提示词。
2. `/grill-with-docs` - 结合文档、领域语言、ADR和代码库上下文验证提示词。
3. `/to-prd` - 将经过验证的上下文转换为PRD/规格文档。
4. `/to-issues` - 将PRD拆分为可独立实现的垂直模块。
5. `/tdd` - 采用红-绿-重构方式实现每个任务。

请先确认此流程，或告知需要调整的内容。
在用户确认流程前，不要开始分阶段询问。

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或进行代码编辑。
  • 将探索结果作为辅助依据；在锁定某一阶段前，需请用户确认产品意图。

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
Projects:
[项目代码], [项目代码]

Need:
[需要开发或修改的内容。]

Integration:
[功能对接的位置：代码库、工作流、API、UI、数据库、任务、服务。]

Reason:
[需求产生的原因。解决了什么问题。]

Constraints:
[限制条件、排除项、技术规则、兼容性要求，或填写"none"。]

Acceptance:
[可选。用户可跳过。若跳过，将根据Need + Integration + Reason推断。]

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 the PRD, issues, or TDD implementation inside this skill.
  • 每次仅询问一个阶段的信息。
  • 在获取所有必填阶段的信息前，不要生成最终提示词。
  • 必填阶段：
    Projects
    、
    Need
    、
    Integration
    、
    Reason
    、
    Constraints
    。
  • 可选阶段：
    Acceptance
    。
  • 若用户跳过
    Acceptance
    ，需自行推断并标注为“推断所得”。
  • 若回答模糊，先提出一个明确的跟进问题，再进入下一阶段。
  • 每个问题需提供4个预设选项加1个自定义选项。
  • 若通过代码库检查可回答或优化某阶段的信息，先进行代码检查，再请用户确认。
  • 最终输出中保留用户提供的阶段顺序。
  • 除非用户要求，否则不要添加额外阶段。
  • 不要直接实现功能。
  • 不要在此skill内生成PRD、任务或TDD实现代码。

Grilling Behavior

验证逻辑

For each section:
  1. Ask one focused question.
  2. Explain what a strong answer includes.
  3. Provide exactly 4 pre-made options plus 1 custom option.
  4. Wait for the user response.
  5. Challenge vague, conflicting, or incomplete answers.
  6. Move to the next section only when clear enough.
针对每个阶段：
  1. 提出一个聚焦的问题。
  2. 说明优质答案应包含的内容。
  3. 提供恰好4个预设选项加1个自定义选项。
  4. 等待用户回复。
  5. 对模糊、冲突或不完整的回答提出质疑。
  6. 仅当信息足够清晰时，才进入下一阶段。

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
Options:
1. [具体预设答案]
2. [具体预设答案]
3. [具体预设答案]
4. [具体预设答案]
5. Custom: [告诉我你的自定义答案]

Reply with a number, or write custom text.
选项规则：
  • 4个预设选项必须适应当前阶段及已知的项目上下文。
  • 当有足够上下文支持时，标记其中一个选项为
    (recommended)
    。
  • 每个选项需简洁，便于快速选择或编辑。
  • 必须始终包含自定义选项。
  • 必须包含以下内容：
    Reply with a number, or write custom text.
  • 接受选项编号、编辑后的选项文本或完全自定义的文本作为答案。
  • 若代码库检查得出可能的答案，需结合这些结果来设定选项。

Draft Review

草稿审核

After all sections are resolved:
  1. Draft the generated prompt using the resolved sections.
  2. Pass that draft to the user for review and feedback.
  3. Apply valid user feedback without adding new sections.
  4. Produce the revised final prompt plus the next command chain.
所有阶段的信息确认完成后：
  1. 根据已确认的信息生成提示词草稿。
  2. 将草稿提交给用户审核并收集反馈。
  3. 应用用户的有效反馈，不要添加新的阶段。
  4. 生成修订后的最终提示词及后续命令流程。

Final Output

最终输出

After user review, produce only this:
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]

Next:
1. Pass this final prompt to `/grill-with-docs`.
2. After the grill is resolved, run `/to-prd`.
3. After the PRD is approved, run `/to-issues`.
4. Implement approved issues with `/tdd`.
Keep the final prompt spartan. No preface. No filler.
用户审核通过后，仅需输出以下内容：
markdown
Projects:
[已确认的项目代码]

Need:
[精准的功能/修改需求]

Integration:
[具体的集成点]

Reason:
[明确的问题/价值]

Constraints:
[明确的限制条件或"none"]

Acceptance:
[用户提供的或推断所得的验收标准]

Next:
1. 将此最终提示词传递给`/grill-with-docs`。
2. 验证完成后，运行`/to-prd`。
3. PRD确认通过后，运行`/to-issues`。
4. 使用`/tdd`实现已确认的任务。
最终提示词需简洁，不要添加前言或冗余内容。