discuss

讨论

访谈前，先确定项目根目录并阅读适用的仓库说明。如果存在 docs/wiki，请阅读其根索引、维护规则、通用语言、最近的相关索引和相关概念，确保讨论以已确认的当前状态为依据。如果存在 docs/backlog，还要以只读方式阅读其根索引和与主题相关的记录，以便提问和交接时考虑已有的拟议工作、关联关系和优先级，并完善现有记录，而非重复提议。如果没有 Wiki，请继续讨论，不要臆造项目事实；如果用户希望持久记录项目状态，则建议使用 $setup-project。

留在用户当前分支上——绝不创建、切换、合并或删除分支。

如果预检发现至少两个独立的事实调查事项，请调用 $parallel-execution，对仓库证据、项目记录和外部证据进行只读调查。在此上下文中完成综合分析、术语和 ADR 跟踪、所有提问以及用户或所有者代理的每项决定。

仅由用户调用——或由 $to-product 调用；后者会根据其自主运行约定，以所有者代理身份回答下方的每个问题。仅在这种运行模式下，将讨论作为一个批量区块输出——每个编号问题后紧接其原文答案——而不是每轮只问一个问题。

持续深入地询问用户各方面内容，直到达成共同理解；逐步梳理决策树中的每个分支，并逐一解决决策间的依赖关系。为每个问题提供建议答案。

一次只问一个问题，并等待回答。每个问题都必须严格采用以下格式：

Question X / ~Y:
Question

X 从 1 开始递增；Y 是包括当前问题在内的预估问题总数，并随讨论进展进行修订。不得使用其他计数格式。

如果可用，且绝不在自主运行模式下，使用 ask_user_question 工具提供多项选择答案；第一项始终是你的建议，并以 “(recommended)” 结尾。如果可用，请在提问前使用网页搜索调查相关工具和框架及其最佳实践。

查找任何可从环境（文件系统、工具）中发现的事实，不要向用户提问。决策由用户决定——将每项决策交由用户确认并等待回答（自主运行模式下，所有者代理须像回答其他问题一样，在区块中作答）。

按照项目 docs/wiki/maintenance.md 中的 ADR 重要性判断标准跟踪具有架构重要性的决策（没有 Wiki 时：结构变更、跨领域质量、采用或弃用技术，或难以撤销的变更——且必须拒绝一个真正的替代方案）。对于每项符合条件的决策，都提出一个编号问题，确认该决策、拒绝的替代方案及理由，以及接受的后果，以便路由后的命令能够记录该决策。预检时阅读 docs/wiki/architecture/decisions/index.md 中的 ADR 索引，并仅打开主题涉及的 ADR；如果某项结论取代了现有 ADR，请说明它取代的是哪一份 ADR。

跟踪术语。当用户使用的领域术语未出现在通用语言中、现有术语含义不同，或用多个词语指代同一概念时，提出编号问题：确认其含义，给出建议定义，并询问是否将其添加到或修正于通用语言中。收集已确认的术语以供交接；没有 Wiki 时，将其记入 $setup-project 的后续事项。

讨论完全是建议性的：只读取信息并提问，绝不调用会产生变更的技能或编辑项目记录。用户确认达成共同理解后，对每项结论进行分类，并推荐相应的、由用户调用且具有持续授权的命令：

• 应形成一个 Epic 的协同成果——多个连贯且各自具有独立价值的工作项，共同服务于一个目标——应交由 $to-epic，由其端到端规划（Epic 接收、研究决策、子项接收、细化至就绪），无需进一步暂停并等待批准。
• 其他尚未实现的期望状态（新能力、行为变更、修复、迁移）应交由 $to-backlog，由其接收已确认的独立事项，并将每项细化至就绪——包括在预检时发现现有 proposed 记录时对其进行细化，而不是另行提出重复事项。绝不要建议将目标规范发布到 wiki。
• 已描述当前主分支已接受状态的更正、澄清或持久结论应交由 $to-wiki——绝不能仅仅因为某项提案描述充分或已达成共识，就将其交由 $to-wiki。
• 已确认新增或更正的术语也应交由 $to-wiki，即使该术语源自尚未实现的提案——无论提案是否最终落地，其含义都是持久的项目用语。
• 负责人确认已采纳的技术或标准规则应交由 $to-guidance，由其研究并发布为规范指导页面。
• 已生效且具有架构重要性的决策应交由 $to-wiki，由其作为 ADR 发布。只有在提议的工作落地后才生效的决策尚不属于已接受状态：应将其与该工作一同交由 $to-epic 或 $to-backlog，由其先在记录中起草，并在验收时发布。绝不要建议发布项目尚未采纳的决策。
• 一段对话可能包含多个事项：将期望变更交由 $to-epic 或 $to-backlog，仅将独立且当前有效的持久事实交由 $to-wiki，不要重复提交提案。
• 未解决的决策应留在对话或拟议的 backlog 记录中——绝不能将其作为已接受的 wiki 知识或就绪工作来呈现。

以相同的编号格式提出一个最终交接问题，然后用每条已接受的命令结束本轮对话；每条命令都必须是一段完整、可直接复制粘贴的提示词，由 $to-epic、$to-backlog、$to-wiki 或 $to-guidance 开头，后接其应处理的已确认结论。命令必须是本轮对话的最后几行——后面不能有任何内容；有多条命令时，按执行顺序列成编号列表。绝不要调用这些命令，也不要改为自行调用 $backlog 或 $wiki——此技能只提供建议；在自主运行中，$to-product 会在讨论区块后执行建议的命令，最后几行规则仅约束此技能自身的输出。