context-analyzer

铁律：在没有建立最小充分上下文前，不要直接下结论，更不要直接修改代码。

工作流

• [ ] Step 1: 先扫结构 ⚠️ REQUIRED
  • [ ] 1.1 查看根目录、关键子目录和配置文件。
  • [ ] 1.2 忽略构建产物与依赖目录，聚焦真实源码和文档。
• [ ] Step 2: 自动发现约束文档 ⚠️ REQUIRED
  • [ ] 2.1 优先读根目录文档、AGENTS.md、README、贡献与安全文档。
  • [ ] 2.2 如果存在 docs/、.github/ 或特定规范文件，再按主题补读。
• [ ] Step 3: 锁定任务相关代码
  • [ ] 3.1 用文件名、符号名、配置项和调用链缩小范围。
  • [ ] 3.2 识别入口、核心模块、依赖边界和风险区域。
• [ ] Step 4: 输出上下文摘要
  • [ ] 4.1 给出关键文件、已知约束、未知点和下一步建议。
  • [ ] 4.2 区分“已确认事实”和“待验证假设”。

输出目标

• 任务相关文件清单。
• 需要遵循的规范来源。
• 关键数据流、依赖和调用链摘要。
• 仍然缺失的信息和最小下一步。

常见项目切入点

• package.json：确认脚本、依赖和实际工具链。
• server/api、pages、components、composables：判断前后端边界与调用链。
• lib/auth.ts、lib/auth-client.ts、middleware/auth.global.ts、server/api/auth/*：排查认证与权限流时优先检查。
• README、AGENTS.md、CONTRIBUTING.md、SECURITY.md：优先提取项目规则与协作约束。

反模式

• 把仓库里所有文件都读一遍，导致分析失焦。
• 看到相似文件名就假定实现细节一致。
• 不区分事实和猜测，直接给出实现建议。

交付前检查

• [ ] 已定位任务相关文件，而不是泛泛而谈。
• [ ] 已优先扫描实际存在的规范文档。
• [ ] 已把结论、证据和未知点分开表述。
• [ ] 输出足以支撑下一步规划或实现。