discovery

需求探索

概述

在规划或编码之前，先理解问题。提出有帮助的问题。探查边界情况。尽早指出不明确的需求。

开始需求探索前，先阅读原则技能。利用它检查领域语言、边界、状态、契约、运维风险和权衡。

首先选择交互深度：

• 轻量需求探索：适用于非正式探索、只需提问的请求，或编写文件会增加不必要负担的情况。提出最重要的 1-3 个问题，或总结已知信息。最后在聊天中简要总结，并列出尚待解答的问题。
• 完整需求探索：适用于主题复杂、答案将用于后续规划或实现，或用户要求设计文档的情况。集中提出 3-7 个问题，并按需反复沟通，最后撰写一份独立的设计文档。

仅在答案会改变对设计的理解时提问。 每批问题都应便于回答，每次最多 7 个。按重要性排序。先问高层问题，再按需深入。

可探讨的主题：

• 目标/结果（成功的标准）
• 受众/用户及其使用场景
• 约束（时间、预算、技术、语气、范围）
• 当前状态（现有内容、应避免的事项）
• 已知痛点和故障模式
• 关键假设和未知因素

指出边界情况、滥用情形和不明确的场景。明确说明尚未充分定义的需求。

需求探索结束时，决定是否保存设计文档：

• 如果用户提出了此要求、需求探索得出了不应遗漏的决策或约束，或后续规划/实现很可能依赖探索结果，则撰写一份独立的设计文档。
• 否则，在聊天中总结有用的结论，不要创建文件。

开始时宣布：“我将使用需求探索技能来了解设计空间。”

原则的使用

• 使用顶层原则来选择问题并总结答案。
• 需要时，阅读原则技能中的更深入内容：shape code by domain、keep boundaries sharp、states are values、 evolve contracts deliberately、performance is not optional 和 design for operation。
• 使用原则名称来描述设计事实、权衡和风险。
• 在文档中记录领域术语、状态模型、信任边界、长期契约、运维约束和风险。

设计文档

此文档用于记录设计，不是计划或评审。

• 设计文档记录对问题的理解、目标、约束、决策、选项、权衡、排除的方案、风险、边界情况和待解问题。
• 计划列出构建设计中某部分的具体实现步骤。
• 评审列出对某个文档（例如实现、计划或设计）的审查结果。

设计文档保存到： <repository-root>/designs/YYYY-MM-DD_HH:MM_<design-name>.md

如果 designs/ 不存在，则创建该目录。

默认使用以下结构；也可根据主题需要调整章节名称，并增删章节：

# Design: <Name>

## Summary
<1-3 sentences describing the problem, intended outcome, and current design understanding.>

## Context
<Relevant background, users/audience, existing state, constraints, and why this matters.>

## Goals
<Bulleted outcomes this design should support.>

## Non-Goals
<Bulleted boundaries for what this design is not trying to solve. Skip if not useful.>

## What We Learned
<Important discoveries, domain facts, user needs, constraints, assumptions, and edge cases.>

## Design Shape
<Current conceptual model, requirements, principles, interfaces, UX shape, system behavior, or other design-relevant structure. Keep this at design level, not implementation-task level.>

## Options Considered
<Candidate approaches, including approaches ruled out. Capture why they matter and why they were accepted, rejected, or deferred.>

## Risks and Edge Cases
<Known failure modes, abuse cases, unclear scenarios, and places where the design may break down.>

## Open Questions
<Unresolved decisions or unknowns that future discovery, planning, or review should address. Skip only if none remain.>

设计文档规则

• 仅在探索结束时，并且只有在需要保存结果时，才编写设计文档；除非用户明确要求继续探索。
• 如果用户要求不要写入文件，或只想进行简短讨论，则不要编写设计文档。
• 如果不编写文档，请在结束时简要总结当前的理解、重要权衡和待解问题。
• 设计文档必须独立完整，不得依赖此前的聊天内容。
• 保留将来可能有用的经验，尤其是约束、被否决的方法和未解决的问题。
• 不要包含有序的实施任务、文件级变更清单、验证命令或路线图。
• 如果某个章节会造成冗余，不必强行添加；让文档保持实用。
• 如果用户要求从探索转入规划或实施，只有在重要背景信息可能丢失时，才先提议保存设计文档。

交互说明

• 深入探讨。
• 不要制定计划、路线图或实施步骤，也不要编写代码。
• 如果用户要求提供计划或代码，并且现有上下文已足够，请退出探索阶段。如果设计背景内容较多且尚未记录，请先询问用户是否要保存这些内容，再进行切换。