study-repo

Study Repo

通过阅读代码库来回答问题，而不是根据文件名猜测。

流程

1. 对问题分类

确定用户需要哪种类型的答案：

• 系统概览 — 仓库的用途及其组织方式。
• 功能追踪 — 特定行为的实现方式。
• 用法核查 — 用户能否以某种方式使用 API、命令、软件包、组件或模式。
• 外部软件包行为 — 依赖项的文档约定、实现、版本或已知限制实际如何。
• 变更准备度 — 规划变更前需要了解什么。

根据分类选择所需的证据；除非有助于说明范围，否则无需告知用户分类结果。

2. 找到依据

阅读能够回答问题的最少量主要资料。以下是可选项，并非必须按顺序阅读；一旦证据足以回答问题，就停止阅读并复用当前上下文：

1. 仓库级文档和软件包／配置文件，用于了解整体情况。
2. 与问题相关的入口点、路由、命令、公共导出或测试。
3. 相关函数、类型、组件或模块的定义及调用位置。
4. 展示预期行为的现有测试或示例。
5. 对于外部软件包，查阅与已安装或指定版本相关的官方文档、发行说明、源代码、测试、示例和类型定义。

优先使用语义导航和快速搜索。文档可供参考，但在可能的情况下，应对照代码核实行为。

有合适工具时，使用它们核实软件包信息：

• 使用官方文档来源核查文档中说明的 API、配置和特定版本行为；例如，在可用时使用 Context7。
• 使用源码搜索或软件包源码检查实现、测试、示例和类型定义；例如，在可用时使用 Octocode 或 GitHub 源码搜索。
• 如果本地项目固定了软件包版本，优先检查已安装的版本；否则，说明检查的是哪个版本或分支。
• 如果文档与源码不一致，应报告冲突，而不是将其含糊带过。

3. 追踪路径

对于功能问题，从公共入口向内追踪行为，直到能够看清重要的状态变化、IO 或领域决策。

对于用法问题，核实：

• 用户会调用的公共接口。
• 必需的输入、配置、调用顺序或环境。
• 错误情形和不支持的情况。
• 能够确认用法的现有测试、示例或文档。

4. 区分确定程度

保持答案诚实：

• 事实 — 代码、测试、文档或命令输出直接支持的内容。
• 推断 — 根据结构或命名得出的可能结论。
• 未知 — 现有资料无法证实的内容。

不要把推断当作事实陈述。

输出

给出简洁的答案，包括：

• 简要回答 — 首先直接回答问题。
• 工作原理 — 仓库中的关键执行路径。
• 代码引用 — 支持答案的文件和符号。
• 注意事项 — 不支持的情况、未知之处或假设。
• 下一步 — 如果需要将其转化为代码变更，建议使用 /plan-it。

完成标准

研究完成后，用户应能了解：

• 相关行为位于何处。
• 主要流程、API 契约或软件包行为如何运作。
• 哪些证据支持答案。
• 还有哪些不确定之处（如有）。