AtomGit

要解决什么问题

在 Agent 里处理「仓库」「PR」「Issue」「分支」时，默认往往会联想到 GitHub 或其它平台；若你实际用的是 AtomGit，工具名、参数（owner、repo、number、sha 等）和权限模型又和通用 Git 托管 API 不完全一致，很容易出现误用平台、在 MCP 未连通时硬跑流程，或在改文件前没拿到当前 blob 的 sha 导致更新失败。

本技能把 AtomGit 相关任务收敛成一条可执行的协作约定：先确认请求确实指向 AtomGit，再对照当前运行时暴露的 MCP 工具名规划操作，而不是凭记忆猜前缀或参数名。

技能如何工作

核心思路是 读先于写、先凑齐标识符再变更：

• 平台确认：用户只说 repo / PR / issue / branch / tag 而未提 AtomGit 时，不默认套用本技能，应先确认平台。
• 工具清单：规划任何仓库动作前，先检查运行时工具列表；若尚无 AtomGit MCP，应停止业务流，按 references/setup-and-safety.md 与官方文档在任务外完成连接，不在对话里自动装包或索要 token。
• 工具命名：以运行时暴露的精确方法名为准（如 atomgit_get_repository）；部分环境会加命名空间包装，不能照搬示例前缀。
• 常见标识符：owner + repo 用于仓库范围调用；Issue/PR 用 number（而非过时的 issue_number）；改文件需 path 与当前 sha；列表类接口注意 page / perPage。
• 安全边界：对破坏性或组织级变更，执行前需明确确认。

各主题（仓库、PR、Issue、分支、提交、发布、标签、看板、Webhook、搜索等）的细节在技能内 references/*.md 中按需查阅，避免一次性塞满上下文。

适用边界与注意点

• 仅用于 AtomGit：非 AtomGit 的托管与协作流程不应强行套用本技能。
• MCP 前置条件：首次 AtomGit 任务前，MCP 应已安装配置完成；若工具列表已显示缺失，不要等业务请求失败再补救。
• 不要假设写权限：即使能读仓库，也不代表可以合并 PR 或改组织设置；写操作前仍要核对权限与影响范围。