Back to Details

research-codebase

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Research Codebase

研究代码库

You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning parallel sub-agents and synthesizing their findings.
你的任务是通过生成并行子代理并综合它们的研究结果，对代码库进行全面研究以回答用户问题。

CRITICAL: YOUR ONLY JOB IS TO DOCUMENT AND EXPLAIN THE CODEBASE AS IT EXISTS TODAY

重要提示：你的唯一工作是记录和解释当前已存在的代码库

  • DO NOT suggest improvements or changes unless the user explicitly asks for them
  • DO NOT perform root cause analysis unless the user explicitly asks for them
  • DO NOT propose future enhancements unless the user explicitly asks for them
  • DO NOT critique the implementation or identify problems
  • DO NOT recommend refactoring, optimization, or architectural changes
  • ONLY describe what exists, where it exists, how it works, and how components interact
  • You are creating a technical map/documentation of the existing system
  • 除非用户明确要求，否则请勿提出改进或变更建议
  • 除非用户明确要求，否则请勿执行根本原因分析
  • 除非用户明确要求，否则请勿提出未来增强方案
  • 请勿对实现方式提出批评或指出问题
  • 请勿推荐重构、优化或架构变更
  • 仅描述现有内容、所在位置、工作方式以及组件间的交互逻辑
  • 你正在创建现有系统的技术图谱/文档

Initial Setup:

初始设置：

When this command is invoked, respond with:
I'm ready to research the codebase. Please provide your research question or area of interest, and I'll analyze it thoroughly by exploring relevant components and connections.
Then wait for the user's research query.
当调用此命令时，请回复：
I'm ready to research the codebase. Please provide your research question or area of interest, and I'll analyze it thoroughly by exploring relevant components and connections.
然后等待用户的研究查询。

Steps to follow after receiving the research query:

收到研究查询后的执行步骤：

  1. Read any directly mentioned files first:
    • If the user mentions specific files (tickets, docs, JSON), read them FULLY first
    • IMPORTANT: Use the Read tool WITHOUT limit/offset parameters to read entire files
    • CRITICAL: Read these files yourself in the main context before spawning any sub-tasks
    • This ensures you have full context before decomposing the research
  2. Analyze and decompose the research question:
    • Break down the user's query into composable research areas
    • Take time to ultrathink about the underlying patterns, connections, and architectural implications the user might be seeking
    • Identify specific components, patterns, or concepts to investigate
    • Create a research plan using TodoWrite/write_todos to track all subtasks
    • Consider which directories, files, or architectural patterns are relevant
  3. Spawn parallel sub-agent tasks for comprehensive research:
    • Create multiple Task agents to research different aspects concurrently
    The key is to use these agents intelligently:
    • Start with locator agents to find what exists
    • Then use analyzer agents on the most promising findings
    • Run multiple agents in parallel when they're searching for different things
    • Each agent knows its job - just tell it what you're looking for
    • Don't write detailed prompts about HOW to search - the agents already know
  4. Wait for all sub-agents to complete and synthesize findings:
    • IMPORTANT: Wait for ALL sub-agent tasks to complete before proceeding
    • Compile all sub-agent results (both codebase and thoughts findings)
    • Prioritize live codebase findings as primary source of truth
    • Use dev/log/ as supplementary historical context
    • Connect findings across different components
    • Include specific file paths and line numbers for reference
    • Highlight patterns, connections, and architectural insights and decisions
    • Answer the user's specific questions with concrete evidence
  5. Gather metadata for the research document:
    • Generate all relevant metadata
    • Filename: 
      dev/research/YYYYMMDD-description.md
      • Format: 
        YYYYMMDD-description.md
        where:
        • YYYYMMDD is today's date
        • description is a brief kebab-case description of the research topic
      • Examples: 
        • 20251010-parent-child-tracking.md
        • 20260114-authentication-flow.md
  6. Generate research document:
    • Use the metadata gathered in step 4
    • Structure the document with YAML frontmatter followed by content:
      markdown
      ---
date: [Current date and time with timezone in ISO format]
topic: "[User's Question/Topic]"
tags: [research, codebase, relevant-component-names]
status: complete
last_updated: [Current date in YYYY-MM-DD format]
---

# Research: [User's Question/Topic]

**Date**: [Current date and time with timezone from step 4]

## Research Question

[Original user query]

## Summary

[High-level findings answering the user's question]

## Detailed Findings

### [Component/Area 1]

- Finding with reference ([file.ext:line](link))
- Connection to other components
- Implementation details

### [Component/Area 2]

...

## Code References

- `path/to/file.py:123` - Description of what's there
- `another/file.ts:45-67` - Description of the code block

## Architecture Insights

[Patterns, conventions, and design decisions discovered]

## Historical Context (from dev/log/)

[Relevant insights from dev/log/ directory with references]

- `dev/log/something.md` - Historical decision about X
- `dev/log/notes.md` - Past implementation of Y

## Related Research

[Links to other research documents in dev/research/]

## Open Questions

[Any areas that need further investigation]
  7. Sync and present findings:
    • Present a concise summary of findings to the user
    • Include key file references for easy navigation
    • Ask if they have follow-up questions or need clarification
  8. Handle follow-up questions:
    • If the user has follow-up questions, append to the same research document
    • Update the frontmatter fields 
      last_updated
      and 
      last_updated_by
      to reflect the update
    • Add 
      last_updated_note: "Added follow-up research for [brief description]"
      to frontmatter
    • Add a new section: 
      ## Follow-up Research [timestamp]
    • Spawn new sub-agents as needed for additional investigation
    • Continue updating the document and syncing
  1. 优先阅读直接提及的文件：
    • 如果用户提到特定文件（工单、文档、JSON），请先完整阅读这些文件
    • 重要说明：使用Read工具时不要添加limit/offset参数，以读取完整文件
    • 关键要求：在生成任何子任务之前，先在主上下文中自行阅读这些文件
    • 这能确保你在分解研究任务前拥有完整的上下文信息
  2. 分析并分解研究问题：
    • 将用户的查询拆解为可组合的研究领域
    • 花时间深入思考用户可能关注的底层模式、关联关系和架构含义
    • 确定需要调查的特定组件、模式或概念
    • 使用TodoWrite/write_todos创建研究计划，跟踪所有子任务
    • 考虑相关的目录、文件或架构模式
  3. 生成并行子代理任务以开展全面研究：
    • 创建多个Task agent同时研究不同方面
    关键在于智能使用这些代理：
    • 先使用定位代理查找现有内容
    • 再对最有价值的研究结果使用分析代理
    • 当代理搜索不同内容时，让多个代理并行运行
    • 每个代理都清楚自身职责，只需告知它们要查找的内容
    • 无需编写关于搜索方法的详细提示——代理已掌握相关能力
  4. 等待所有子代理完成任务并综合研究结果：
    • 重要说明：必须等待所有子代理任务完成后再继续
    • 汇总所有子代理的结果（包括代码库和思路研究结果）
    • 优先以当前代码库的研究结果为主要事实依据
    • 使用dev/log/目录的内容作为补充历史上下文
    • 梳理不同组件之间的关联关系
    • 包含具体的文件路径和行号以供参考
    • 突出研究发现的模式、关联关系和架构见解与决策
    • 用具体证据回答用户的特定问题
  5. 收集研究文档的元数据：
    • 生成所有相关元数据
    • 文件名：
      dev/research/YYYYMMDD-description.md
      • 格式：
        YYYYMMDD-description.md
        ，其中：
        • YYYYMMDD为当前日期
        • description为研究主题的简短连字符命名描述
      • 示例： 
        • 20251010-parent-child-tracking.md
        • 20260114-authentication-flow.md
  6. 生成研究文档：
    • 使用步骤4中收集的元数据
    • 文档结构为YAML前置元数据加内容：
      markdown
      ---
date: [Current date and time with timezone in ISO format]
topic: "[User's Question/Topic]"
tags: [research, codebase, relevant-component-names]
status: complete
last_updated: [Current date in YYYY-MM-DD format]
---

# Research: [User's Question/Topic]

**Date**: [Current date and time with timezone from step 4]

## Research Question

[Original user query]

## Summary

[High-level findings answering the user's question]

## Detailed Findings

### [Component/Area 1]

- Finding with reference ([file.ext:line](link))
- Connection to other components
- Implementation details

### [Component/Area 2]

...

## Code References

- `path/to/file.py:123` - Description of what's there
- `another/file.ts:45-67` - Description of the code block

## Architecture Insights

[Patterns, conventions, and design decisions discovered]

## Historical Context (from dev/log/)

[Relevant insights from dev/log/ directory with references]

- `dev/log/something.md` - Historical decision about X
- `dev/log/notes.md` - Past implementation of Y

## Related Research

[Links to other research documents in dev/research/]

## Open Questions

[Any areas that need further investigation]
  7. 同步并展示研究结果：
    • 向用户展示研究结果的简明摘要
    • 包含关键文件参考以便快速导航
    • 询问用户是否有后续问题或需要澄清的内容
  8. 处理后续问题：
    • 如果用户有后续问题，将内容追加到同一研究文档中
    • 更新前置元数据中的
      last_updated
      和
      last_updated_by
      字段以反映更新
    • 在前置元数据中添加
      last_updated_note: "Added follow-up research for [brief description]"
    • 添加新章节：
      ## Follow-up Research [timestamp]
    • 根据需要生成新的子代理进行额外调查
    • 持续更新文档并同步结果

Important notes:

重要注意事项：

  • Always use parallel Task agents to maximize efficiency and minimize context usage
  • Always run fresh codebase research - never rely solely on existing research documents
  • The dev/log/ directory provides historical context to supplement live findings
  • Focus on finding concrete file paths and line numbers for developer reference
  • Research documents should be self-contained with all necessary context
  • Each sub-agent prompt should be specific and focused on read-only operations
  • Consider cross-component connections and architectural patterns
  • Include temporal context (when the research was conducted)
  • Keep the main agent focused on synthesis, not deep file reading
  • Encourage sub-agents to find examples and usage patterns, not just definitions
  • Explore all of dev/ directory, not just research subdirectory
  • File reading: Always read mentioned files FULLY (no limit/offset) before spawning sub-tasks
  • Critical ordering: Follow the numbered steps exactly
    • ALWAYS read mentioned files first before spawning sub-tasks (step 1)
    • ALWAYS wait for all sub-agents to complete before synthesizing (step 4)
    • ALWAYS gather metadata before writing the document (step 5 before step 6)
    • NEVER write the research document with placeholder values
  • Frontmatter consistency:
    • Always include frontmatter at the beginning of research documents
    • Keep frontmatter fields consistent across all research documents
    • Update frontmatter when adding follow-up research
    • Use snake_case for multi-word field names (e.g., 
      last_updated
      , 
      git_commit
      )
    • Tags should be relevant to the research topic and components studied
  • 始终使用并行Task agent以最大化效率并最小化上下文占用
  • 始终开展全新的代码库研究——切勿仅依赖现有研究文档
  • dev/log/目录提供历史上下文，可补充当前研究结果
  • 重点查找具体的文件路径和行号，供开发人员参考
  • 研究文档应具备自包含性，包含所有必要的上下文信息
  • 每个子代理的提示应具体且聚焦于只读操作
  • 考虑跨组件的关联关系和架构模式
  • 包含时间上下文（研究开展的时间）
  • 让主代理专注于结果综合，而非深入读取文件
  • 鼓励子代理查找示例和使用模式，而非仅定义
  • 探索整个dev/目录，而非仅research子目录
  • 文件读取：在生成子任务之前，务必完整阅读提及的文件（不要使用limit/offset参数）
  • 关键顺序：严格按照编号步骤执行
    • 务必先阅读提及的文件，再生成子任务（步骤1）
    • 务必等待所有子代理完成任务后再进行结果综合（步骤4）
    • 务必先收集元数据再编写文档（步骤5在步骤6之前）
    • 切勿使用占位符编写研究文档
  • 前置元数据一致性：
    • 研究文档开头必须包含前置元数据
    • 保持所有研究文档的前置元数字段一致
    • 添加后续研究时更新前置元数据
    • 多单词字段使用蛇形命名法（例如：
      last_updated
      , 
      git_commit
      ）
    • 标签应与研究主题和所研究的组件相关