grill-with-docs

通过文档进行深入讨论

通过对话对用户请求的计划进行压力测试，并将达成一致的领域术语和长期决策保留在项目文档中。

加载本地指导

如果可用，请在提问和梳理决策依赖关系时使用 grilling 技能，在术语和架构记录方面使用 domain-modeling 技能。通过可用的技能目录查找仓库自有的技能，并使用目录提供的位置或加载机制；不要推测同级目录。如果任一技能不可用，请继续使用下方的组合流程。不要获取或替换为外部技能。

确定文档范围

使用此工作流的请求包括：随着用户确定决策，更新本地术语表和架构决策记录。这些文档规则同样适用于使用辅助技能的情况。在只读或提议修改模式下，将拟议文本保留在对话中，不要创建或编辑文件。如果用户将写入范围限制在特定文档中，则只更新这些文档，并将其他拟议记录保留在对话中。

检查现有术语表、上下文映射、相关 ADR，以及仅用于支撑讨论所需的代码。遵循既定的文档位置和格式。如果没有约定，则使用 CONTEXT.md 记录领域术语，使用 docs/adr/ 记录符合条件的决策；只有在有已达成一致的内容需要记录时才创建这些文件。

提问、确定并记录

1. 明确用户希望解决的决策，并复用已给出的答案。对于前置条件已确定的问题进行提问，说明会产生重要影响的权衡，并在证据支持时推荐答案。输入尚未明确前，暂缓提出依赖这些输入的问题。
2. 在可用代码和文档中查找事实，而不是要求用户提供可查明的信息。明确区分已验证的行为、拟议更改和未解决的假设。产品含义和权衡由用户决定；建议或尚未回答的问题不代表达成一致。
3. 每轮回答后，检查是否存在会改变含义的歧义或冲突。只询问解决该冲突所需的澄清。清晰的回答即视为达成一致，无需仅为记录而再次确认。
4. 根据下方规则记录已达成一致的结果，然后继续提出由此解锁的问题。如果答案修订了先前的决策，则更新受影响的记录，使文档与讨论保持一致。

应记录的内容

• 领域术语： 在相关术语表中记录已明确的项目特定概念、其含义以及容易混淆的同义词。不要将实现选择、未决问题和对话历史记录在其中。如果没有现有术语表格式的约束，请在可用时遵循 domain-modeling 技能提供的格式指南；否则，给出简明定义并列出应避免使用的术语即可。
• 架构决策： 当推翻某项已确定的选择会造成显著成本、其理由原本可能不清楚，并且该选择解决了实际权衡问题或排除了显而易见选项的外部约束时，记录该选择。说明决策、选择理由，以及值得保留的重要后果或被否决的替代方案。如果没有现有 ADR 格式的约束，请在可用时遵循 domain-modeling 技能提供的格式指南；否则，简短的标题和一段说明选择及其理由的文字即可。不要为每个回答都创建 ADR。
• 其他回答： 将常规选择、暂定提案和未解决的问题留在对话中，除非用户要求将其记录到其他位置。不要自动将其转化为术语表定义、已采纳的 ADR、规范或跟踪事项。

回读每项文档更改，确认其保留了用户的原意，且没有将推断提升为已达成一致的要求。继续遵循现有的文档授权；只有当拟议的写入超出授权范围时才再次询问。

完成

当请求所需决策的重要事项均已确定或明确延期，或者用户暂停讨论时，即可结束。报告已确定的结论、仍待解决的重要问题以及已更改的文档。在只读或提议编辑模式下，请提供拟议文本并指出其目标位置，不要声称已保存。

对设计达成一致并获得记录授权，并不意味着已获准实施、提交、推送或对外发布。只有在用户授权后，才能继续执行这些操作。