用途：在编辑前先摸清系统，不在缺乏仓库证据时提出结构性改动。
主要流程：识别项目类型（Web 应用、API、移动端、monorepo 或库）；定位 entrypoints、配置与 build/test/lint 脚本；从 manifest 与 import 中提取真实技术栈，而非凭猜测；梳理领域目录、分层与边界（UI、API、数据、认证）；列出现有约定（命名、状态、错误、测试、CI）；列出风险（技术债、关键文件、缺少测试的区域）；之后才提出与既有约定一致的最小改动计划。
检查对象：manifests（package.json、pnpm-workspace.yaml、Cargo.toml、Podfile、Package.swift、.xcodeproj）；框架（Next.js、Vite、Expo、SwiftUI、Nest、Express、Prisma）；路由与 entrypoints（app/、pages/、src/main、App.tsx、ContentView）；数据（Prisma/Drizzle schema、migration、HTTP client）；认证与中间件；测试与 CI（.test.、Playwright、GitHub Actions）；环境变量与 secrets（不暴露值）。
最小报告：技术栈与大致版本；架构 3–6 条要点；需遵守的约定；风险热点；建议的下一步。
规则：以文件证据优先于通用模式记忆；文档与代码冲突时以代码为准；discovery 期间不做顺手重构；保留本地风格，未经明确要求不强行套用其他架构；若用户要求结构设计，改用 software-architecture；monorepo 中须声明在范围内的包/应用。
完成标准：确认技术栈与 entrypoints；列出主要约定；识别风险与关键依赖；给出与请求成比例的变更计划。
限制：资料未提供具体安装命令、价格或平台支持说明。