用途：在正式撰写 ADR（架构决策记录）之前，先收集并确认背景信息。输出为 docs/architecture/discovery-brief.md，其中只包含经人确认的事实，另有 docs/architecture/open-questions.md 记录未知项，之后交由 adr-drafting 起草决策。
核心规则是零幻觉：任何事实在架构师确认前都不进入简报。代码发现、文档发现和推断都以问题形式呈现，而非断言。例如看到 package.json 中的 pg 与 ioredis，应问“Postgres 是主存储吗（是/否/不确定）”，而不是直接断言。已确认事实标注 [CONFIRMED YYYY-MM-DD]；未确认的代码发现标注 [FROM CODE, UNCONFIRMED YYYY-MM-DD]，只放入 open-questions.md。
事实状态分四类：CONFIRMED 可驱动决策；FROM CODE, UNCONFIRMED、UNKNOWN、PARKED 均不可驱动决策，其中 PARKED 须在 ADR 后果中注明。
流程共九阶段：扫描仓库信号但不解读；确认领域；逐个确认组件（上限 5 个，每个需一行人工描述）；确认组件间关系及人工描述；对既有 ADR 逐条分类为取代/修订/相关/张力/无关；多仓库与生态探查（角色、负责人、访问权限、既有 ADR 与 C4 图，以及合规约束如数据驻留、SOC2、HIPAA、GDPR、FedRAMP）；检查五项 MUST（领域、受压架构特性、≤5 组件、相关 ADR 分类、具名决策者）全部确认；可选的 C4 交接；最后写入一行交接摘要交给 adr-drafting。若有 MUST 未确认，技能拒绝推进并转入 open-questions.md。
风格要求：一次只问一个主题，记录前用自己的话复述答案，直接不寒暄，指名具体文件、技术与组件，避免含糊名词。
限制：资料未提供具体安装方式、平台支持或定价信息。