SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场mcp-attribution-worktree

mcp-attribution-worktree

编程与开发

查看项目

更新于 10-16 04:39

技能介绍

用途

MCP Attribution Worktree 是一个面向 MCP 与 skills 归因问题的维护工作流技能。它的目标是把归因问题的处理从临时性调试转变为可审计、可追踪的流程：从本地报告 API 获取待处理问题，基于运行证据判断问题是否可修复，并在可修复时一路推进到代码修复与 PR 创建。

主要能力

  • 从本地报告 API 拉取待处理的 MCP 与 skills 相关归因问题。
  • 在做出任何状态决定前，先查看问题详情与代表性运行记录。
  • 将失败映射到具体的 mcp/src 工具、config/source/skills 内容，或归类为环境 / 评分器 / 重复噪声。
  • 用简洁证据更新归因问题，owner 固定为 codex，并链接外部 GitHub 工作。
  • 将每个可操作的修复隔离在独立的 Worktrunk worktree 与分支中。
  • 将可操作问题推进到仓库修复与 PR 创建，而不是止步于状态更新。
  • 当后续评审或评估反馈表明方向不完整或错误时，从已有 GitHub issue 或 PR 继续迭代。
  • 在评估接口可用时运行真实的 PR 后评估，并据此决定是否需要下一轮修复。

使用方式

该技能通过本地报告 API 与命令行工具协同工作。常用命令包括：

curl -s 'http://127.0.0.1:5174/api/attributions?category=tool&resolutionStatus=todo&limit=50'
curl -s 'http://127.0.0.1:5174/api/attributions?category=skill&resolutionStatus=todo&limit=50'
curl -s "http://127.0.0.1:5174/api/attributions/<issueId>"
curl -s "http://127.0.0.1:5174/api/runs/<caseId>/<runId>/result"
curl -s "http://127.0.0.1:5174/api/runs/<caseId>/<runId>/trace"
curl -s "http://127.0.0.1:5174/api/runs/<caseId>/<runId>/evaluation-trace"
wt switch --create feature/attribution-<slug>
gh issue create --repo TencentCloudBase/CloudBase-MCP
gh pr view <number> --comments --repo TencentCloudBase/CloudBase-MCP
gh pr create --repo TencentCloudBase/CloudBase-MCP
curl -s -X POST http://127.0.0.1:5174/api/evaluations

工作流要点：一次只处理一个问题，不跨问题混用证据、笔记或 worktree；在选定代表性运行前先执行已有产物预检（读取问题详情、当前笔记、已有 externalUrl、关联 GitHub issue 或 PR 的状态）；至少阅读一次运行的结果与 trace，并尽量阅读 evaluation-trace；在判断问题是否可操作前检查 mcp/src 或 config/source/skills 中的相关实现。

适用场景

  • 自动处理待处理的 MCP 归因问题。
  • 查看工具与 skills 归因积压，修复真实问题并用证据更新归因。
  • 在隔离 worktree 中修复有价值的 MCP 归因问题。
  • 判断某个工具问题是真实的 mcp/src bug 还是评估噪声。
  • 在评审意见后继续迭代已有 issue 或 PR。
  • 打开 PR 后运行真实评估，若仍失败则进行下一轮修复。

限制

该技能不适用于：没有归因证据的通用 bug 修复；无法映射到 mcp/src 或 config/source/skills 的无关归因类别；与特定归因问题无关的批量仓库变更；在文档化报告 API 端点之外的直接数据库或后端变更。

操作规则要求：仅通过本地报告 API 更新归因问题；owner 固定为 codex；在未阅读至少一次相关运行的结果与 trace 前不得更改 resolutionStatus；没有明确关闭证据（如已有 GitHub issue、PR、已合并修复或已验证的重复项）不得标记为 resolved；若存在未读或未处理的 PR 评论、评审意见、评审决定或 issue 评论，不得标记为 resolved；若证据不完整，保持 todo 或移至 in_progress 并明确说明缺失内容。若 Worktrunk 不可用，应停止并报告缺失，而不是静默回退到共享检出。不得为多个归因问题复用同一个 worktree。

关于模型导向的修复启发式：当归因证据显示模型因工具或技能以不熟悉的方式暴露仓库特定语义而失败时，优先采用减少模型翻译工作的修复方式，将行为映射到模型已熟悉的概念（如 MongoDB updateOne/updateMany、HTTP 方法、SQL CRUD 动词、文件系统路径约定或常见 SDK 惯用法）；保持面向模型的指导简短且高信号；明确命名危险默认值或陷阱；当契约清晰度是真正缺口时，优先修改工具描述、参数描述、技能措辞或生成文档，而不是直接跳到实现变更。

关于 CloudBase 技能内容：当修复属于 CloudBase 技能内容时，应编辑 config/source/skills/ 作为事实来源，不要将根 skills/ 目录视为这些外部技能的来源。

关于子代理：若支持子代理，优先每个问题一个子代理，每个子代理只拥有一个问题；若不可用，则串行处理并保持严格的一次一个问题上下文。

关于评估：若存在真实评估接口，优先将归因保持在 in_progress，直到修复分支或 PR 通过新一轮评估；不要仅凭推理声称验证成功，应使用评估 API 与最终运行结果。

该技能还包含必需预检与必需关闭预检清单，要求在开始新诊断或代码迭代前、以及在将归因改为 resolved 前，按顺序完成对关联 GitHub 产物最新状态的重新检查。