用途：这是一个独立的研究命令，用于研究某个阶段（phase）应如何实现。官方提示指出它通常不是首选，绝大多数工作流应使用 {{COMMAND_PREFIX}}plan-phase，后者会自动集成研究。适合以下场景：想先研究暂不规划；规划完成后要重新研究；需要在决定某阶段是否可行前先做调查。
主要能力与角色：该命令充当编排器（orchestrator），负责解析阶段、对照路线图校验、检查已有研究、收集上下文、派生 researcher 子代理并呈现结果。使用子代理的原因是研究消耗上下文较快（WebSearch、Context7 查询、来源核验），用全新的 200k 上下文做调查，主上下文保持精简以用于用户交互。第 1 步会先规范化阶段输入再进行目录查找。
使用方式：先初始化上下文，执行 INIT=$(node {{PLATFORM_ROOT}}/get-shit-done/bin/gsd-tools.cjs init phase-op "$ARGUMENTS")，并从返回 JSON 提取 phase_dir、phase_number、phase_name、phase_found、commit_docs、has_research、state_path、requirements_path、context_path、research_path。随后解析研究者模型 RESEARCHER_MODEL=$(node {{PLATFORM_ROOT}}/get-shit-done/bin/gsd-tools.cjs resolve-model gsd-phase-researcher --raw)。
流程：1. 用 gsd-tools.cjs roadmap get-phase "${phase_number}" 校验阶段，found 为 false 则报错退出，为 true 则提取阶段编号、名称与目标。2. 用 ls .planning/phases/${PHASE}-*/RESEARCH.md 2>/dev/null 检查已有研究，存在则提供更新、查看或跳过选项并等待响应；不存在则继续。3. 用 INIT 中的路径收集阶段上下文（requirement、context、state），在编排器上下文中不内联文件内容，只呈现摘要。4. 派生 gsd-phase-researcher 代理，研究模式有 ecosystem（默认）、feasibility、implementation、comparison。研究关注点不是“该用哪个库”，而是“有哪些自己不知道的未知”，包括既定架构模式、标准技术栈、常见问题、SOTA 与训练认知差异、不应手写的部分。5. 处理代理返回：RESEARCH COMPLETE 则展示摘要并提供规划、深挖、审阅全文、完成选项；CHECKPOINT REACHED 则呈现给用户并派生继续代理；RESEARCH INCONCLUSIVE 则展示已尝试内容并提供添加上下文、换模式、手动处理选项。6. 派生继续代理，读取已有 RESEARCH.md 并带上检查点响应。
输出与质量门：结果写入 .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md。其下游消费者是 plan-phase，会读取特定小节，如“Standard Stack”决定计划所用库、“Architecture Patterns”决定任务结构、“Don't Hand-Roll”避免自造轮子、“Common Pitfalls”用于验证、“Code Examples”作为动作参考，因此研究要给出规定性结论（“Use X”而非“Consider X or Y”）。完成前需核验所有领域均已调查、否定性结论有官方文档支撑、关键断言有多个来源、置信度如实标注、小节名称与 plan-phase 预期一致。
限制与未提供信息：资料未说明该命令的收费、价格、支持平台或运行环境要求；{{PLATFORM_ROOT}}、{{COMMAND_PREFIX}} 为占位符，需按实际平台替换。除上述流程外，未提供更多功能、效果或使用步骤。