A2C-SMCP 体系新增功能的流程门控。强制协议先行——任何涉及协议的 Feature 必须先在协议仓库通过评审、合并、发布后,代码仓库才可跟进实现。当用户提出新功能需求或 Feature Request 时调用。
以架构师视角审查代码变更,关注模块边界、DRY 复用性、测试完整性、协议合规和长期可维护性。当需要审查 PR、工作区变更或提交代码时使用。
以架构师视角分析并修复问题,强制 plan 模式,杜绝补丁式修复。涉及协议时严格按协议来,协议有问题则协议先行调整,代码再跟进。当遇到 Bug 反馈、错误日志或功能异常时使用。
把一个较大的 A2C-SMCP Epic / Story / GitHub Issue(或 Jira / CNB Issue)科学拆成多个可独立交付的子任务,输出含依赖图与集成回归守护的拆分方案,并在对应平台用 sub-issue 能力下单。A2C 特有:涉及协议的拆分强制「协议先行」——协议子任务置于依赖图根,代码仓库子任务 blocked-by 它。当用户说「拆分这个任务」「把 Epic 拆成子任务」「分解 Story」「给个切刀方案」时触发。
指导第三方 MCP Server 开发者通过标准 MCP Resource 协议暴露 window://(桌面状态)与 skill://(能力包)资源,接入 A2C-SMCP Desktop / SKILL 通道。当为 MCP Server 增加 A2C-SMCP 集成、把服务实时状态暴露给 Desktop、或通过 MCP 分发 SKILL 时使用。
反馈 A2C-SMCP Marketplace Skill 的问题或改进建议。自动识别当前会话中使用的 Skill,提取优化点,收集版本信息,提交 GitHub Issue 到 a2c-smcp-skills 仓库。当使用某个 Skill 时发现步骤错误、分支遗漏、文档过时等问题时调用。
审查 enhance-skill 提交的 GitHub Issue,评估建议合理性,与用户商议后实施改进。用于 marketplace 维护者持续提升 Skill 质量。
引导 A2C-SMCP 各项目的版本发布流程——单一来源改版本号 → 打 vX.Y.Z tag → 推送触发 CI 发布 → 发布后验收。覆盖 SDK 包发布(PyPI / crates.io)与协议文档部署(GitHub Pages 自动 + 公司服务器手动)。当需要发布新版本、部署文档站点,或排查发布流程问题时使用。