SkyJourneyandClaude Sonnet 5
9d9e31c98e
新增禅道项目管理系统插件，含项目集/产品/项目/执行、需求 （story/epic/requirement）、Bug、任务、测试、计划与发布、反馈工单 八个工作流技能，自动配置 MCP 连接（禅道「个人中心 → 获取凭证」 自助生成 14 天 Token）。 MCP Server 是团队自建的 zentao-mcp 网桥（部署在 pm.ops.yixiong-tech.com/mcp），基于开源 openapi-mcp-server 二次开发。 Claude 侧走 userConfig 钥匙链 + 自定义 token 头；Codex 侧受限于官方 插件格式只支持 bearer_token_env_var，走 Authorization: Bearer——网桥 那边已经加了 preferred_header/bearer_mode 配置项统一归一化处理，两条 路径都验证过连通。 三轮审查（静态字段对照 openapi.json、跨文件一致性、真实端点实测） 修正过程中发现的问题，技能文档里引用的工具名全部跟服务器真实注册 的 118 个工具核对过。 同步更新：.claude-plugin/marketplace.json、.agents/plugins/marketplace.json、 README.md、CLAUDE.md 的插件索引与说明；README 补充「获取凭证」操作 截图（已脱敏）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016pFx6jnym6kRWRQ5JyDUNv
97 lines
3.4 KiB
Markdown
97 lines
3.4 KiB
Markdown
---
|
||
name: zentao-bug
|
||
description: "禅道 Bug 管理：创建、查询、解决、关闭、激活 Bug。当用户说「提个 bug」「这个 bug 修好了」「bug 关掉」「查一下未解决的 bug」时使用。"
|
||
---
|
||
|
||
# 禅道 Bug 管理
|
||
|
||
**前置：先读 `zentao-shared`（尤其"路径参数不出现在 inputSchema 里"一节）。**
|
||
|
||
---
|
||
|
||
## 状态机
|
||
|
||
```
|
||
激活(open) ──resolve 解决──▶ 已解决(resolved) ──close 关闭──▶ 已关闭(closed)
|
||
▲ │
|
||
└──────────────────── activate 激活（重新打开）────────────────┘
|
||
```
|
||
|
||
`close` 也可以直接对一个未解决的 bug 使用（跳过 resolve 直接关闭，比如确认不是真实
|
||
问题），但更常见的路径是先 resolve 再 close。
|
||
|
||
---
|
||
|
||
## 查
|
||
|
||
```
|
||
get_products_productID_bugs(productID, ...)
|
||
get_projects_projectID_bugs(projectID, ...)
|
||
get_executions_executionID_bugs(executionID, ...)
|
||
get_bugs_bugID(bugID) 详情
|
||
```
|
||
|
||
用户问"未解决的 bug"时先确认要看哪个维度（产品/项目/执行），三个列表接口过滤范围不同。
|
||
|
||
---
|
||
|
||
## 建
|
||
|
||
```
|
||
post_bugs({ payload: { productID, title, openedBuild, project?, execution?, severity?,
|
||
pri?, type?, steps?, story? } })
|
||
```
|
||
|
||
`productID`/`title`/`openedBuild` 三个必填——**`openedBuild`（影响版本）容易漏**，
|
||
不是可选项，**是字符串数组**，元素是版本 ID，主干传 `["trunk"]`（不是单个字符串
|
||
`"trunk"`），可以同时关联多个版本。
|
||
|
||
`type`（Bug 类型）受限枚举：`codeerror` 代码错误 | `config` 配置相关 | `install` 安装部署
|
||
| `security` 安全相关 | `performance` 性能问题 | `standard` 标准规范 | `automation` 测试脚本
|
||
| `designdefect` 设计缺陷 | `others` 其他。
|
||
|
||
`severity`（严重程度）/`pri`（优先级）不传默认都是 3。
|
||
|
||
`story` 字段可以关联一个相关需求（story ID）。
|
||
|
||
---
|
||
|
||
## 解决（resolve）
|
||
|
||
```
|
||
put_bugs_bugID_resolve({ bugID, payload: { resolution, resolvedDate?, resolvedBuild?,
|
||
assignedTo?, comment? } })
|
||
```
|
||
|
||
`resolution` 必填，受限枚举：`fixed` 已解决 | `notrepro` 无法重现 | `bydesign` 设计如此 |
|
||
`duplicate` 重复Bug | `external` 外部原因 | `postponed` 延期处理 | `willnotfix` 不予解决 |
|
||
`tostory` 转为需求。
|
||
|
||
**先跟用户确认具体是哪种解决方式再调用**（`zentao-shared` 全局约定：状态流转类操作先
|
||
确认）——`fixed` 和 `willnotfix`/`notrepro` 对提交者的观感完全不同，不要因为用户说
|
||
"这个处理一下"就默认填 `fixed`。`tostory` 这个选项比较特殊，选它意味着这个 bug 会被
|
||
转成一条需求，用之前跟用户确认清楚是不是真的要转。
|
||
|
||
---
|
||
|
||
## 关闭（close）/ 激活（activate）
|
||
|
||
```
|
||
put_bugs_bugID_close({ bugID, payload: { comment? } })
|
||
put_bugs_bugID_activate({ bugID, payload: { openedBuild?, assignedTo?, comment? } })
|
||
```
|
||
|
||
都没有必填字段。关闭前确认这个 bug 确实该关了（比如已经 resolve 过，或者提交者认可
|
||
不是真实问题）；激活是把已关闭/已解决的 bug 重新打开，一般用于验证不通过要打回。
|
||
|
||
---
|
||
|
||
## 改 / 删
|
||
|
||
```
|
||
put_bugs_bugID({ bugID, payload: {...} })
|
||
delete_bugs_bugID({ bugID })
|
||
```
|
||
|
||
删除不可逆，执行前必须确认。
|