メニュー
引导 A2C-SMCP 各项目的版本发布流程——单一来源改版本号 → 打 vX.Y.Z tag → 推送触发 CI 发布 → 发布后验收。覆盖 SDK 包发布（PyPI / crates.io）与协议文档部署（GitHub Pages 自动 + 公司服务器手动）。当需要发布新版本、部署文档站点，或排查发布流程问题时使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | release |
| description | 引导 A2C-SMCP 各项目的版本发布流程——单一来源改版本号 → 打 vX.Y.Z tag → 推送触发 CI 发布 → 发布后验收。覆盖 SDK 包发布（PyPI / crates.io）与协议文档部署（GitHub Pages 自动 + 公司服务器手动）。当需要发布新版本、部署文档站点，或排查发布流程问题时使用。 |
| argument-hint | [project] [version] |
A2C-SMCP 各项目的发布共享同一骨架，但发布目标不同（SDK 包 / 文档站点）。本 Skill 引导通用流程，项目差异见 resources/<project>.md。
核心工作方式：发布是不可逆的对外动作。每个关键步骤（打 tag、推送、触发部署）执行前必须用 AskUserQuestion 向用户确认；发布后必须做验收检查，不要默认 CI 成功。
1. 前置检查 → 2. 版本号管理 → 3. 推送触发发布 → 4. 发布后验收
工作树干净 单一来源改版本 tag/commit 推送 制品可达 + 版本正确
版本已更新 bump 生成 tag CI 自动发布
每个项目把上述四步映射到自己的工具链。动手前先读 resources/<project>.md（当前已文档化：a2c-smcp-protocol、oasp-protocol）。其他项目暂无 resource 时，先读该仓库的 .github/workflows/*publish*.yml、pyproject.toml / Cargo.toml 确认实际机制，不要凭经验臆测。
a2c-smcp-protocol、python-sdk、rust-sdk。留空则用 AskUserQuestion 确认当前所在仓库。major/minor/patch）。留空则读取项目当前版本，询问用户本次 bump 级别。确认 gh 可用（涉及 CI run / release 查询）。
发布前必须全部通过，任一不满足则停止并提示用户：
| 检查项 | 方法 |
|---|---|
| 工作树干净 | git status --porcelain 无输出 |
| 在发布分支 | 通常为 main，与远端一致（git fetch 后无落后） |
| 版本单一来源 | 版本号只在一处定义（Python: pyproject.toml；Rust: Cargo.toml），其余文件由 bump 工具同步 |
| 测试/CI 绿 | 最近一次主干 CI run 成功（gh run list） |
| 变更已记录 | CHANGELOG / release notes 已更新（如项目有此约定） |
项目特有的前置项见 resources/<project>.md。
目标产物是一个 vX.Y.Z git tag（A2C-SMCP 约定 tag 前缀 v）。
| 工具 | 项目 | 命令 |
|---|---|---|
| bump-my-version | Python（python-sdk、a2c-smcp-protocol） | bump-my-version bump <patch|minor|major>，自动改全部版本字符串、commit、打 v{new} tag |
| Cargo | Rust（rust-sdk） | 手动改 Cargo.toml 版本，commit，git tag vX.Y.Z |
bump-my-version 的
[tool.bumpversion.files]会同步多个文件（含文档里的版本字符串）。改版本号只跑 bump 工具，不要手改个别文件，否则单一来源被破坏、各处版本不一致。
执行 bump 前用 AskUserQuestion 与用户确认 bump 级别与最终版本号。
推送 commit 与 tag 是触发 CI 发布的动作，执行前用 AskUserQuestion 明确确认。
git push origin <branch> # 推送 bump commit
git push origin vX.Y.Z # 推送 tag
各项目 CI 的触发条件与发布目标不同：
| 项目 | 触发 | 发布目标 |
|---|---|---|
| python-sdk | publish.yml | PyPI |
| rust-sdk | GitHub release published → publish.yml | crates.io |
| a2c-smcp-protocol | push main（docs/mkdocs 变更）→ deploy-pages.yml | GitHub Pages（自动）；公司服务器需手动 inv docs.deploy，见 resource |
| oasp-protocol | CI docs.yml 仅 workflow_dispatch 且硬编码 0.1.0——版本化发布走本地 inv docs.deploy --version=X.Y.Z | GitHub Pages + 公司服务器；服务器同步用 inv docs.push-to-server（tar-over-SSH），见 resource |
rust-sdk 走 crates.io 时由 GitHub Release 发布触发，可能还需
gh release create vX.Y.Z——动手前读该仓库 workflow 确认。 文档类项目的版本号未必来自pyproject.toml（如 oasp 由 changelog 顶部驱动），发布前确认版本来源，见 resource。
CI 跑完不等于发布成功，必须验收。通用项：
gh run list --workflow=<publish.yml> --limit 1，确认最近一次 conclusion 为 success。pip index versions <pkg> 或访问 PyPI 页面，新版本可见。/latest/（或新版本路径）返回 200。项目特有验收项（如文档站点的 versions.json、多发布目标）见 resources/<project>.md。
| 反模式 | 正确做法 |
|---|---|
| 手改个别文件的版本号 | 只跑 bump 工具，保持单一来源同步 |
| 推送 tag 不与用户确认 | 不可逆对外动作前用 AskUserQuestion 确认 |
| 假设 CI 一定成功 | 发布后查 gh run list + 验制品可达 |
| 对未文档化项目凭经验臆测 | 先读该仓库的 publish workflow 与版本配置 |
| 文档发布只发 GitHub Pages | 协议仓库公司服务器需手动部署，见 resource |
| 服务器部署任务打印 ✅ 就当成功 | 部分项目 git-pull 同步会静默假报成功，须验服务器实际刷新，见 resource |
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 时发现步骤错误、分支遗漏、文档过时等问题时调用。