feature-prompt

feature-prompt

为下一步生成最精简且实用的交接内容——而非实现规范。grill-with-field 会质疑计划、明确领域术语、更新 GLOSSARY.md，并且只针对难以抉择的事项提供 ADR。

输出约定

最终提示词采用以下格式：

Project:
[Full Project Matrix code, repo, path, or context. Use one line.]

What is needed:
[The change to make. One short paragraph or 2-4 bullets.]

Why it is needed:
[The problem, user pain, business reason, or workflow gap — so grill-with-field
can challenge tradeoffs, not just wording — and what happens if nothing is
built.]

Expected end result:
[Observable done state. Prefer user-visible behavior, passing checks, or a
demo flow; seeds the later acceptance criteria. Name the empty, loading,
error, and recovery behavior, each role that sees it, and one thing that must
not happen.]

Known limits:
[Hard constraints, non-goals, compatibility needs, or exclusions
already known. When intake was split, list the deferred slices as explicit
non-goals. Always include the zero-attribution rule.]

Open questions:
[Conditional. Real unresolved questions for grill-with-field to attack.]

前五个部分始终保留；没有待解决的问题时，省略 Open questions。

规则

零署名：任何输出中都不得添加或保留共同作者、AI 或工具署名。将此规则写入提示词的 Known limits。

信息收集与推断

• 从自由形式的信息开始。先推断；只有在 What is needed 不明确，或无法安全推断项目／上下文时才提问。
• 成本低时使用仓库证据：Project Matrix、当前工作目录、GLOSSARY.md、 GLOSSARY-MAP.md 和 ADR 名称。默认不要全面扫描代码。

范围与切分

• 起草前进行迷雾测试：你现在能否用一行说明目标，并将每个未决事项都表述为明确的问题？如果不能，就停止并建议使用 /wayfinder——它会梳理这些事项，并在每次会话中解决一个。不要为迷雾重重的工作编写 PR 级提示词。测试标准是迷雾，而非规模：如果大型机械性改动已无待决事项，就不算迷雾。
• 默认只做一个精简的垂直切片，规模小到可以独立审查和合并。范围宽泛的需求要拆分：本提示词只为切片 1 起草；Known limits 记录推迟的切片。如果提示词会导致冗长的盘问环节 → 在定稿前要求拆分范围；如果用户不在线 → 自行拆分，并在回复顶部注明拆分情况。
• 如果用户计划并行开展 Agent 线程，应拆分切片，以尽量减少对共享文件的耦合。

上下文与证据

• 只要存在完整的 Project Matrix 代码，就原样引用。绝不缩写项目代码或擅自创造简写。
• 引用现有文件／模块／衔接点。只有在「复用现有衔接点还是创建新衔接点」尚未解决时，才将其列入 Open questions；否则，将已确定的选择及其证据记录在提及该衔接点的约定部分，绝不另设新部分。如果搜索未找到现有衔接点，列出搜索过的术语。
• 只包含不显而易见的上下文：模型无法通过简单扫描仓库轻易推断的约束、架构特例和领域规则。省略代码中已有体现的技术栈事实。
• 如果依赖项的内部实现至关重要且不清楚 → 建议在深入盘问前，将获取定向源代码（例如 opensrc）作为后续上下文步骤。
• 保留领域词语原样。根据证据提出候选定义，并使用下方的审批流程；未解决的定义交由 grill-with-field 处理。

问题与输出规范

• 不要创建 Domain terms、Decisions、Dependents、 Risks、Doc anchors、Integration、Constraints 或 Acceptance 部分。将有用信息并入六个约定部分；用户明确提出的难以抉择事项放在 Known limits 下。
• 所有不明确的决定都放在 Open questions 下；无法通过盘问解决的事项（「需要感受／查看」）也应转交 /handoff + /prototype，再继续深入盘问。
• Open questions 仅保留影响最大的未知事项（通常为 1-5 项）。可在实现过程中决定的琐碎事项应删除。
• 对明确问题给出含糊答复（例如「尽可能快」、「所有用户」）不算回答——追问一次具体数字或明确的用户群体；如果仍含糊，就按原样放在 Open questions 下。
• 不要实现功能、创建规范或编辑 ADR。只有通过下方获批的候选术语流程，才能修改 GLOSSARY.md。
• 最终提示词应精简、直接、使用通俗英语——它是生成的成品，绝不可用压缩式简写。

候选上下文术语

仅当廉价的仓库证据或用户要求的探索揭示了 GLOSSARY.md 中缺失或过时的领域术语时，才进行此操作——切勿仅为填充术语表而进行额外探索。哪些术语符合条件、如何展示、用户不在时的回退处理以及如何应用审批结果，均见 references/context-terms.md。在最终确定提示词前展示候选术语，仅应用已批准的更新，并在保存前报告已编辑的路径。仍需审核的术语留在 Open questions 下。

Agent 使用

子 Agent：为独立工作自动派发本地任务通道——绝不使用云端 Agent；派发时说明通道数量，并在每个通道完成时报告。通道仅用于快速、独立的上下文检查——不得使用工作 Agent，不得编辑代码。

最终输出

1. 起草最终提示词。
2. 对于非平凡或基于推断的提示词，展示一次供用户更正，并将推断出的事实（项目、切片边界、最终结果）与用户陈述的内容分别列出。用户不在时 → 按草稿保存，并在顶部注明尚未确认。
3. 如果发现候选上下文术语，执行通用审批流程。
4. 核对保存前检查清单，并保存到下方路径；然后重新打开已保存的文件，确认各部分和路径与已批准的草稿一致，或在用户不在时与明确标注为尚未确认的草稿一致，然后再进行报告。
5. 仅添加：

Context updated: <relative GLOSSARY.md path> [only if edited]
Saved to: <relative path written>
Next: pass this final prompt to the `grill-with-field` skill.
Suggested next skills (optional):

- /grill-with-field: challenge assumptions, sharpen domain terms, and confirm decisions.
- /handoff + /prototype: when open questions are ungrillable and need a higher-fidelity spike.
- /to-spec: if this needs a formal spec (PRD) after grilling.

文件输出

路径

<artifacts-root>/specs/prompts/NNNN-<feature-slug>-prompt.md

解析 <artifacts-root>：如果存在 *.code-workspace 目录，则使用该目录；否则使用当前上下文的根目录（仓库根目录中的 GLOSSARY-MAP.md；旧版为 CONTEXT-MAP.md）；否则使用仓库根目录。

• NNNN — 扫描 <artifacts-root>/specs/adr/ 和 specs/prompts/，找到现有的最大四位数字并递增。这样可避免创建提示词时占用已有编号。ADR 使用独立编号序列，之后可能会重复使用提示词编号；记录的提示词路径是链接。
• <feature-slug> — 根据 What is needed 使用 kebab-case，最多 4 个词，ASCII 字符。
• -prompt — 固定后缀，标记制品类型。

冲突处理

• 按需创建 specs/prompts/。绝不覆盖已被其他制品使用的编号。绝不删除无关文件。
• 如果 Git 显示某个先前的同名提示词文件有本次会话未造成的提交记录或工作区更改，则视为手动编辑过；如果 Git 无法判断（未跟踪文件），则假定已手动编辑。
• 本次会话创建且之后未更改的同名提示词 → 原位更新。已手动编辑 → 展示差异并询问：覆盖、创建新的编号版本，还是中止。如果用户不在，则写入新的编号版本——绝不在未经确认时覆盖手动编辑的内容。

文件正文

只写入最终提示词正文——不加前言，不加自动生成的标题 — 可直接用作 grill-with-field 的输入。

保存前检查清单

• 仅出现六个允许的章节标题，顺序符合约定
• Project: 按原样写出完整的 Project Matrix 代码（如果存在）
• 对于新文件，NNNN 在 specs/adr/ 和 specs/prompts/ 中唯一；原位更新保留其自身编号；slug ≤ 4 个词， 使用 kebab-case 和 ASCII 字符，并带有 -prompt 后缀
• 拆分收集的信息：延期切片记录在 Known limits 下；包含零归因规则
• 不含占位文本（TBD、TODO、[...]），且任意两个章节之间没有矛盾
• 文件正文仅包含提示词——可直接使用，不含前言