用途：Discovery 用于在锁定架构决策前先梳理未知信息与隐藏约束，减少因上下文缺失导致的错误输出。适用于任何非平凡请求，核心产出是报告顶部的“Context”段落。
七个发现维度：一、谁依赖此项，包括下游服务、公开消费者及兼容性弃用路径；可用 grep -rE "import.<your-module>|require.<your-module>" 搜索仓库及相关仓库。二、当前与半年后的规模，涵盖流量、存储、成本及线性或指数级预测，未知则标注需向用户确认。三、必须保持不变的内容，如 API 契约、被报表引用的数据库列、文件格式、合规承诺。四、预算，包括月度成本上限、人力规模与时间要求；未说明时默认小项目、一人一周、每月低于 200 美元，并在报告中呈现以便纠正。五、关键失败模式，“凌晨三点故障会触发什么告警”，据此分为数据丢失、错误回答、响应慢、体验问题四级，决定投入程度。六、已尝试过的工作，可搜索 Beads、docs/decisions 或 lessons.md，避免重复。七、决策者，确认是否需要 CTO、合规评审或 RFC。
输出格式：在报告顶部写出 Context 段，列出 Consum ers、Scale、Frozen contracts、Budget、Failure-mode tier、Prior work、Decision-makers 各项，未知处标注“unknown — TBD with user”。
可跳过情况：纳米级项目、无行为变化的纯工具函数抽取、用户给出清晰复现的语音 bug 修复，跳过时需记录说明。
限制与要点：不要假设，任何假设都应作为 Context 中的问题呈现而非事实；发现工作是执行者自身职责，应先用 Glob、Grep、git 等工具尽可能自行获取答案，只向用户询问代码无法回答的部分。资料未提供具体价格、平台支持、性能数据等额外信息。