development

用于基于用户提供的当前源码核对一个或一组 API / RPC / endpoint 的真实合同，并在服务端实现、调用方、类型/schema、测试与 OpenAPI/接口文档之间做一致性审计。适合‘这个接口返回什么/请求头和其他内部接口是否一致/鉴权怎么做/字段从哪来/源码与接口文档是否一致/给我可导入 Apifox 的 OpenAPI’。默认只做当前合同事实读取与审计，不设计新合同、不修改源码，也不把单接口问题扩张成完整系统调研。

当用户要求分析 Git 目标分支的分叉基线，并导出 origin.zip 与 content.patch 时使用；直接接收 AgentDock 可访问的仓库 URL 或路径，由 AgentDock 完成 Git、验证、打包和发布。

当用户要求把任意 Git 仓库的指定分支浅克隆、移除 Git 历史、打成 ZIP、校验并通过 AgentDock 插件发布下载时使用；直接接收 AgentDock 可访问的仓库 URL 或仓库路径，不依赖仓库映射文件。

在用户提供源码、日志、复现步骤、测试、截图或补丁，需要调查软件 Bug 时使用。以当前源码和证据确定症状、影响、根因或待验证假设、严重级别、永久解决方向、复杂度和验收要求。默认完成调查而不自动创建 Issue；用户明确要求在调查后留痕时才执行查重/Issue 持久化。根因确认后若用户要直接 `.patch`，先做 S/M/L 与 Patch Fast Lane Gate；仅 S 级合格项进入 source-patch-implementation。

用于把已经确认或需要先与用户校准的一轮业务范围，整理成可交给下游 Test Agent 执行的业务测试方案。用户明确请求业务测试方案/业务用例时由本 Skill 先承接并执行 Spec Gate；若进入 ready_for_spec，再转入 github-spec 或按用户明确选择记录跳过。随后回显 Business Understanding，与用户或已确认结论对齐 Expected Business Contract，再建立 Feature/状态维度/跨对象不变量/Gherkin/业务 Evidence。适合‘给我业务测试方案/业务用例/按用户流程怎么测/这个功能有哪些业务场景’。不负责选择 Unit/Integration/E2E、设计 Harness/故障注入或编写测试代码；这些进入技术测试方案。

用于把已经明确或需要先经过前置 Gate 的需求、结论或缺陷永久解决方向转换成可直接交给小模型/Coding Agent 的 GitHub 开发计划。用户明确请求开发/实施计划时由本 Skill 先承接并执行 Spec Gate；若进入 ready_for_spec，再转入 github-spec 或按用户明确选择记录跳过。默认采用 small-model-strict：以当前源码建立来源索引、传播图、文件结构、契约和自包含 Task DAG，冻结 Read Before Edit、Entry Preconditions、Allowed/Forbidden、Write Set、Stop Conditions、Expected Diff Shape、逐 symbol Implementation Steps、Behavior Cases、验证义务与验收。该 Skill 只负责规划，不修改源码或运行完整真实测试。

在需要围绕技术、产品、架构或实现主题与用户进行可追踪讨论时使用。正式讨论前创建或续用一个【讨论】Issue，以源码证据、当前实现/目标方案/差距、决策树、待决项和 Mermaid 图示为核心表达，按决策依赖逐步确认高杠杆问题，并在每次回答后追加可追溯的决定、理由、边界和未决项；无法写入 GitHub 时使用标准化本地交接包持续记录。

用于对当前软件项目、模块、服务、Agent、Workflow、API 或完整调用链做系统性源码调研，建立可复用的当前实现事实基线。即使用户没有明确说“调研文档/报告”，只要请求表现为完整梳理、盘点现状、分析实现到什么程度、说明系统怎么工作、梳理现有能力与缺口，并且需要跨多个源码证据形成系统认知，也应优先列为主 Skill 候选；单点事实、独立缺陷、未定方案讨论和已经明确的开发计划/测试方案请求进入对应 Skill。默认可直接在当前对话交付完整调研结论；用户明确要求创建/生成调研文档、调研报告、【调研】Issue、把刚才的源码分析/调研留档到 GitHub，或其它 Markdown/Wiki/GitHub 留痕时，仍由本 Skill 主导并进入文档持久化模式，Issue 写入只是调研工作流的持久化步骤。

用于冻结已经完成讨论或已经明确确认的目标合同，创建独立【结论】Issue。用户明确要求结论/规格、讨论收口需要冻结权威合同，或下游实施计划/技术测试方案/业务测试方案执行 Spec Gate 后进入 ready_for_spec 时使用。用户已经明确点名下游交付物时，主路由先进入对应下游 Skill，由它执行 Spec Gate；不能因为高传播且缺结论就同时把本 Skill 列为主候选。局部低传播修改可记录 spec_not_required 后跳过。

用于为已有需求、缺陷、实施计划或业务测试范围设计可交给下游 Test/Coding Agent 执行的技术测试方案。用户明确请求技术测试方案/自动化回归设计时由本 Skill 先承接并执行 Spec Gate；若进入 ready_for_spec，再转入 github-spec 或按用户明确选择记录跳过。随后重点回答‘技术上怎么测’：测试层级、现有测试复用、Harness/Environment、Fixture/Reset、Contract/E2E、故障注入、并发/恢复、Evidence、Fresh Run 与自动化维护。适合‘给我技术测试方案/自动化回归怎么做/哪些测试要迁移/怎么构建稳定可回测环境/这个改动要测哪些层’。不负责定义业务应该怎么工作，不编写测试代码，也不在当前容器声称真实测试已通过。

用于审查已经存在的业务测试方案、技术测试方案或两者组合，检查 Spec Gate/权威来源是否完整、它们是否与当前源码/已确认目标合同一致、覆盖是否充分、是否可交给下游 Agent 执行。业务计划重点审 Business Alignment、Expected Contract、Feature/State/Invariant/Gherkin；技术方案重点审 Risk/Layer、Harness/Fixture/Reset、Evidence、Fresh Run、Resilience 与自动化可维护性。默认只审计和给修改建议，不运行真实测试、不编写测试代码、不修改产品代码。

用于对用户提供的当前源码执行 S 级局部代码修改并交付可回放 `.patch`。适合根因/目标行为已经确认后用户说‘那直接 patch’‘小问题直接改’‘给我补丁’；必须先通过 Patch Fast Lane Gate：低传播、无高影响未决策、无数据迁移/外部合同/复杂状态并发/跨服务职责变化。Gate 不满足时不得因用户点名 `.patch` 强行实施，应回到缺陷调查、讨论、Spec 或开发计划。