用途：审查现有项目，找出代码中已存在但从未正式记录的架构决策，例如技术选型、架构模式、约定与权衡，并输出按优先级排序的候选 ADR 列表。用户决定创建哪些，技能再对每个获批项调用 adr-manage。
主要能力与流程：
- 初始定位：读取 .agents/MEMORY.md（若存在）了解已知技术栈与上下文；读取 docs/adr/ 列出已有 ADR，避免重复提议；未指定路径时默认当前仓库根目录。
- 项目检查：按顺序探索，先看目录结构（如 find . -maxdepth 3 -type d | grep -v node_modules | grep -v .git | grep -v pycache），推断 monorepo 或单体、分层或按领域划分等；再读依赖清单（Node/JS/TS 的 package.json、package-lock.json、tsconfig.json；Python 的 pyproject.toml、requirements.txt、setup.cfg、Pipfile；JVM 的 pom.xml、build.gradle、build.gradle.kts；.NET 的 .csproj、.sln；Rust 的 Cargo.toml；Go 的 go.mod），提取框架、ORM、消息队列、测试工具、打包器、认证库、云服务客户端等信号；然后在源码中查找架构模式证据（分层目录、Repository/Service/Controller/Handler/UseCase/Interactor、依赖注入等）；最后查看已有 ADR，仅读标题与 ## Decision 部分。
- 候选识别：纳入非显而易见、影响多部分系统、回退成本高、新人可能质疑的决策；排除已被现有 ADR 覆盖、技术栈默认选项或纯实现细节。典型类别包括语言/运行时、总体架构、持久化、API/协议、认证、状态/UI、测试、可观测性、模块化、CI/CD。
- 候选展示：按高/中/低优先级列出，每项含编号、标题、证据、为何算决策、是否已有 ADR，并询问用户要记录哪些（全部/仅高优先级/自选编号）。
- 创建：对每个获批候选调用 adr-manage，传入建议标题、证据、推断的决策、隐含替代方案，以及整批统一商定的决策者与语言。
限制与行为准则：不得编造决策，证据含糊时标注不确定性并降为低优先级；不提议琐碎项（如“使用 Git”）；不重复已有 ADR 覆盖的决策；质量优先于数量。语言优先用会话上下文偏好，其次项目记忆，最后用户消息语言。具体安装方式与收费信息暂未提供。