[feat] Add zentao plugin (Claude Code + Codex dual scaffold)

新增禅道项目管理系统插件,含项目集/产品/项目/执行、需求
(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
This commit is contained in:
SkyJourney
2026-08-25 13:50:41 +08:00
co-authored by Claude Sonnet 5
parent 1606d73c41
commit 9d9e31c98e
18 changed files with 1006 additions and 4 deletions
+96
View File
@@ -0,0 +1,96 @@
---
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 })
```
删除不可逆,执行前必须确认。