【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skillsname: gitcode-issue-handler description: GitCode Issue 端到端处置工具根据 Issue 内容自动判断走两条路径之一(PR 路径) 克隆 fork → 代码定位 → 最小改动 → 跑测试 → 提交并推送 → 创建 PR覆盖 bug 修复 / 功能增强 / 文档补全等任何需要代码变更的诉求(Comment 路径) 仅克隆上游主仓只读分析 → 起草答复 → 提交评论覆盖答疑 / 设计澄清 / 用法说明等不需改代码的诉求。当用户提到处理 Issue / 跟进 Issue / 从 Issue 提 PR / 端到端处理 Issue / 修复 Issue或仅给出 issue_url 让 Claude 判断要不要改代码时使用此 skill用户明确说只回复 / 答疑 / 评论回复 / 不改代码则直接走 Comment 路径。 license: MITGitCode Issue 端到端处理把一条 Issue 链接跑到合适的归宿要么上游 PR 已创建要么答复评论已发布。Step 1.5 模式判定先看 Issue 内容是否需要改代码以及用户消息里的显式倾向再决定走 PR 路径还是 Comment 路径不要在没看 Issue 内容前就假设要改代码。通用约束全程中文与用户沟通和思考。PR 路径代码改动、commit message、PR 标题与描述统一用英文坚持最小修改能两行解决不要重构十行。Comment 路径评论语言跟随 Issue 正文主语言中文 Issue → 中文评论英文 Issue → 英文评论读者是 Issue 提问者本人可读性优先。写操作commit / push / PR / 评论前必须 AskUserQuestion 确认一次只问一个被审查的正文先在对话主流以代码块形式打印再发问题。不要把多行内容塞进 AskUserQuestion 的preview字段。输入参数参数必填说明issue_urlYGitCode Issue 链接如https://gitcode.com/cann/ops-math/issues/123fork_url仅PR 路径需要用户自己 fork 出来的仓库链接。PR 路径下若缺失进入 Step 1.6 询问 / 自动 fork。Comment 路径不需要 fork。base_branch仅 PR 路径用上游目标分支默认从 Issue 上下文或上游默认分支推断通常master总体流程Step 0 环境预检token / git / /tmpgit author 仅 PR 路径必检 Step 1 解析 issue_url fork_url拉取 Issue 详情抽取关键信号 Step 1.5 模式判定Issue 内容 用户显式倾向 → 推荐 PR / Comment → 用户确认 PR 路径详见 references/pr-path.md Step 1.6 fork_url 缺失时询问 / 自动 fork Step 2 克隆 fork、设置 upstream、同步 base、切工作分支 Step 3 代码定位 改动方案 → 用户确认 Step 4 最小改动 跑测试 Step 5 Commit英文→ 确认 → Push Step 6 参考 gitcode-toolkit 的 PR 创建工作流沿用仓库模板 Step 7 日志 报告 PR 链接 Comment 路径详见 references/comment-path.md Step C-2 克隆上游主仓只读 Step C-3 代码与 Issue 联合分析 Step C-4 起草答复评论语言跟随 Issue Step C-5 用户确认 → POST 评论 → GET 回查 Step C-6 日志 报告评论链接每个写操作前都先用 AskUserQuestion 让用户确认PR 路径的 Step 3 方案、Step 5 commit、Step 5 push、Step 6 PRComment 路径的 Step C-5 评论提交。一次只问一个问题。Step 0: 环境预检详见 gitcode-toolkit/references/env-check.md执行时机拿到issue_url后、解析任何业务字段前立即执行。必检项任一失败立即通过 AskUserQuestion 询问一次只问一个GitCode Token用户消息 → 环境变量GITCODE_TOKEN→ 都没有则询问git / curl / python3缺失则询问是否继续/tmp 可写Git 提交用户信息仅 PR 路径必检。先做 1~3 项基础预检git author 留到 Step 1.5 判定为 PR 后再补——Comment 答疑场景下不会无端问用户的 git 身份。读git config --global user.name/user.email两者都非空 → 标GIT_AUTHOR_SOURCEglobal任一缺失 → AskUserQuestion 让用户提供拿到后只在 work_dir 上git config禁止改~/.gitconfig全局。详见 env-check.md「5. Git 提交用户信息」。为什么 git author 不留到 Step 5 commit 前才查git commit没有 author 时会以Author identity unknown失败此时已经完成 clone改代码跑测试一整轮回头补配置浪费时间和上下文。早查早暴露——但也别比知道需要 commit更早。预检通过后输出一段简短报告格式参考 env-check.md「预检报告格式」无需用户确认直接进入 Step 1。Step 1: 解析链接并拉取 Issue1.1 URL 解析按 gitcode-toolkit/references/url-parsing.md 解析issue_url→upstream_owner,upstream_repo,issue_numberfork_url→fork_owner,fork_repo校验upstream_repo fork_repo应当成立不成立说明 fork 链接不是该 Issue 仓库的 fork立即 AskUserQuestion 让用户更正不要瞎猜。1.2 拉取 Issue 详情curl -s https://api.gitcode.com/api/v5/repos/${upstream_owner}/${upstream_repo}/issues/${issue_number}?access_token${token} \ --connect-timeout 60 --max-time 180抽出后面分析和 PR 关联用的字段字段用途titleIssue 标题用作代码定位起点 / PR 标题灵感bodyIssue 正文复现步骤、报错栈、期望行为或诉求/疑问描述labels标签bug / feature / question / docs 等影响处置策略stateclosed则提醒用户该 Issue 已关闭是否继续1.3 关键信号提取从title body里手动抽出不要让模型脑补报错信息或日志片段复现命令 / 输入样例涉及的文件路径、函数名、类名如果 Issue 中提到期望行为 vs 实际行为这些信号是后续代码定位 / 联合分析的种子缺失则在 AskUserQuestion 里问用户补一条最小复现或补一条诉求/疑问的具体描述。Step 1.5: 模式判定PR / Comment读完 Issue 后立即判定。主要靠 Issue 内容是否需要改代码来判断fork_url 是否提供不是决定因素——用户给了 fork_url 也可能后来发现 Issue 只是个问题没给 fork_url 也可能是奔着修代码来的。判定细则关键词显式优先 / 内容信号 / 推荐确认模板见references/mode-detection.md。判定结论必须以普通文本打印到对话主流含 Issue 摘要 关键信号 推荐路径 推荐理由再 AskUserQuestion 三选一「走推荐路径 / 改走另一条 / 取消」。用户改路径时吸收选择继续不要嘴硬辩护。路径确定后选 PR若 Step 0 时跳过了 git author 检查因为模式未明现在补做。然后进入PR 路径见下方概览与 references/pr-path.md。选 Comment直接进入Comment 路径见下方概览与 references/comment-path.md的 Step C-2。PR 路径概览从 Step 1.5 判定为 PR 时进入。详细步骤、命令、确认模板见 references/pr-path.md。骨架Step 1.6fork_url 缺失时 AskUserQuestion 三选一提供链接 / 自动 fork / 取消自动 fork 调 GitCode Fork API注意 409/422 已存在、403 无权限、异步未就绪三种异常处理Step 2/tmp/gitcode-issue-handler_${upstream_repo}_${issue_number}_${ts}→ clone fork → 必要时写 work_dir local 的 user.name/email仅GIT_AUTHOR_SOURCEuser时→ 配 upstream → fetch upstream →checkout -B base upstream/base→ 切${type}/issue-${issue_number}-slugtype按 Issue 性质选fix/feat/docs等与 commit type 一致Step 3读代码定位相关位置不脑补、bug 类先稳定复现并追根因、feature/docs 类直接对照诉求圈定改动面、写下假设并验证→ 输出现象/结论/涉及文件/策略/风险AskUserQuestion 让用户确认方案后再动手Step 4最小改动注释/变量名/log 文本全英文、遵循文件内既有风格、不顺手重构、不新增依赖→ 跑相关测试 → 失败回到 Step 4.1 迭代不改测试断言来过测→ 提交前自检 checklistStep 5Conventional Commits 风格英文 messagetype(scope): subject bodybody 只写这次提交改了什么、为什么这么改不要写Fixes #N/ Issue 背景叙述——Issue 关联放到 PR body 的关联的Issue章节禁止 Co-Authored-By→ 主流打印 commit 全文 git diff --stat→ 确认 → push 前再确认一次Step 6按 gitcode-toolkit 「PR 创建工作流」执行head 用${fork_owner}/${fork_repo}:branch格式PR body 必须沿用仓库模板的原章节标题按优先级git show upstream/${base_branch}:.gitcode/PULL_REQUEST_TEMPLATE.zh-CN.md→.gitcode/PULL_REQUEST_TEMPLATE.md→.github/PULL_REQUEST_TEMPLATE.md仅替换!-- ... --占位走 POST 占位 PATCH 完整 body GET 回查的套路PATCH 200 不代表写入成功Step 7写日志 报告 PR 链接关键不变量所有写操作前 AskUserQuestion被审查内容先在主流以代码块打印commit message / PR body 不塞进preview字段commit message 不含 Co-Authored-ByPR 模板章节标题原样保留。Comment 路径概览从 Step 1.5 判定为 Comment 时进入。详细步骤、命令、评论模板见 references/comment-path.md。骨架Step C-2clone 上游主仓到/tmp/gitcode-issue-handler_${repo}_${issue}_${ts}_readonly--depth200而非 1要追溯历史后缀_readonly是自我提醒全程不 add / commit / pushStep C-3用 Read / Grep 实地确认 Issue 提到的代码不脑补按问题层次答复——为什么这么实现→ 给历史 取舍是否支持 X→ 核实边界如何用 Y→ 最小可运行示例。找不到根据明确写未规约建议向 xxx 进一步确认不要在评论里塞改动方案 / patchStep C-4起草答复语言跟随 Issue 正文主语言建议结构「一句话结论 分析含file:line引用 5~10 行源码片段 边界 参考 可选建议」Step C-5主流以代码块完整打印评论 body → AskUserQuestion 三选一确认 → POST 评论 → GET 回查长 body3KB走 POST 占位 PATCH 完整 GET 验证套路Step C-6写日志 报告评论链接关键不变量Comment 路径不 fork、不切分支、不 commit、不在评论里塞代码 patch分析过程中如果发现真的需要改代码回到 Step 1.5 让用户切 PR抛弃只读目录重起一个非 readonly 工作目录。Step 7 / C-6: 日志与最终报告按 gitcode-toolkit/references/logging-conventions.md 写日志文件名logs/gitcode-issue-handler_{YYYYMMDD}_{HHMMSS}.logPR 路径记录Issue 摘要 / 模式判定结论与理由 / 工作目录 / 根因结论 / 修改文件清单 / 测试命令与结果 / commit sha / push 结果 / PR 链接Comment 路径记录Issue 摘要 / 模式判定结论与理由 / 只读工作目录 / 分析要点含 file:line/ 评论 body 全文 / 评论链接不写 token 明文最终向用户输出PR 路径Issue #${issue_number} 已处理完成 - Issue : ${issue_url} - 分支 : ${type}/issue-${issue_number}-${slug} - 提交 : sha-short subject - PR : pr_web_url - 日志 : logs/gitcode-issue-handler_xxx.logComment 路径Issue #${issue_number} 已答复Comment 路径 - Issue : ${issue_url} - 工作目录 : ${WORK_DIR}只读 - 评论 : comment html_url 或 ${issue_url}#note_id - 日志 : logs/gitcode-issue-handler_xxx.log异常处理与反模式异常速查表、反模式列表、典型使用示例见references/troubleshooting.md。遇到 push 被拒 / clone 卡住 / 评论 GET 回查为空 / 用户在确认弹窗里要求加点改动建议 / 选错路径中途切换等场景先查该文件。完整流程检查清单共通环境预检通过token / git / curl / /tmpIssue 标题/正文已抽取关键信号Step 1.5 模式判定结论已在对话主流打印并经用户确认含「关键信号 推荐理由」写操作前每一步都用 AskUserQuestion 拿到了用户确认且被审查内容在主流以代码块形式可见日志已落盘含模式判定结论 工作目录 最终产物链接不含 token 明文PR 路径专属git author 检查通过user.name user.email仅 work_dir local未污染全局~/.gitconfigfork ↔ upstream 关系已校验parent_full_name upstream_full_name允许 fork 改名base 分支已同步工作分支已切出根因方案经用户确认改动仅限确认的文件全部英文代码、注释、log 文本测试通过或手工复现已记录commit message 英文无 Co-Authored-Bybody 只写代码改动本身不含Fixes #N或 Issue 背景叙述Issue 关联放到 PR bodyPR 标题英文PR body沿用git show upstream/${base_branch}:.gitcode/PULL_REQUEST_TEMPLATE.zh-CN.md的章节标题原样仅替换!-- ... --占位关联 Issue 一栏写Fixes #issue_number类型标签按 commit type 勾一项PR 创建后用 GET 回查body/description长度非 0 与预期一致PATCH 200 不代表写入成功Comment 路径专属工作目录使用_readonly后缀全程未发生git add/commit/push评论语言与 Issue 正文主语言一致评论包含至少一处file:line引用 关键源码片段不是泛泛而谈评论 body 已在对话主流以代码块形式打印再发 AskUserQuestion 确认提交后 GET 回查评论 body 长度与内容均符合预期长 body 需走 POST 占位 PATCH 完整 GET 验证没有在评论里写改动 patch / 建议把 X 行改成 Y——那是 PR 路径的事【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考