Skip to content
cccskills
FreePublished on GitHub

issue-triage

GitHub Issue 处理协作流程。当用户收到 issue 需要分析和回复时使用。通过"诊断 → 定性 → 决策 → 回复"四步法，从一个 issue 产出准确的根因分析和得体的用户回复，避免误判问题类型或回复不专业。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub
Works withGitHub
See how to install

Files included (1)

  • SKILL.md6.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

用户收到了一个 GitHub Issue（bug 报告、疑问、feature request），需要 AI 协助分析问题、判断是否要做、起草回复。AI 全程主导推进，用户只在关键节点做判断。

核心原则

  • 先诊断后开口 — 没看完代码不下结论，没找到根因不定性
  • 对用户诚实 — 是 bug 就认，是架构限制就说清楚，不甩锅也不画饼
  • 量化成本 — "成本高"不是结论，要说清楚高在哪：改几个文件、涉及哪些模块、有没有测试条件
  • 给替代方案 — 不做不等于不管，要告诉用户现在怎么绕过

工作流程

第 1 步：获取 Issue 内容

目标： 拿到 issue 的完整信息。

方法：

  1. 用户提供 issue 链接或仓库地址
  2. 通过 gh issue view 或 WebFetch 获取 issue 详情
  3. 提取关键信息：用户环境、复现步骤、期望行为、实际行为、用户的猜测

输出： 向用户简要转述 issue 内容，确认理解无误。

禁止： 只看标题就开始分析。必须读完 issue 全文。

第 2 步：代码诊断

目标： 在代码中找到根因。

方法：

  1. 从 issue 描述中提取关键词（功能名、错误信息、页面名等）
  2. 在代码中定位相关链路：从前端入口 → IPC 调用 → 后端处理 → 底层实现
  3. 画出完整调用链，标注每个环节的文件和行号
  4. 确认根因：代码哪里出了问题，或者代码为什么不支持用户的场景

输出： 向用户展示：

  • 完整调用链（文件 + 行号）
  • 根因的一句话总结
  • 必要时附关键代码片段

禁止：

  • 没读代码就猜原因
  • 只看一个文件就下结论（要追完整条链路）

第 3 步：定性

目标： 判断这个 issue 属于哪种类型。

类型判断标准应对策略
Bug在产品设计范围内，行为不符合预期排期修复
架构限制用户场景超出产品的设计前提解释现状，评估是否值得扩展
Feature Request产品本身没问题，用户想要新能力评估成本和优先级
使用问题用户操作方式不对，但产品可以做得更友好回复指引，考虑优化体验

关键判断： 区分"该做但做错了"（bug）和"没打算做"（架构限制/feature）。

输出： 向用户说明定性结论和理由，等用户确认后再往下走。

第 4 步：决策（做还是不做）

目标： 基于根因和定性，给出做/不做的建议。

评估四个维度

  1. 改动范围 — 改几行 / 改一个模块 / 新增一个模块
  2. 影响面 — 只动一个文件 / 要改多个文件的调用链 / 要重构
  3. 测试条件 — 有没有环境能复现和验证（没环境 = 高风险）
  4. 用户绕过成本 — 用户自己能不能用其他方式解决

决策矩阵

改动范围有测试条件用户可绕过建议
小（几行）有—直接修
中（一个模块）有—排期做
大（新模块/重构）有否评估后排期
大（新模块/重构）没有是记下需求，暂不做
任意没有是告知绕过方案，需求记下

输出： 向用户说明建议和理由。如果建议不做，要量化成本（改几个文件、涉及哪些模块、为什么没法测）。

等用户确认决策后，再进入回复环节。

第 5 步：起草回复

目标： 写一条专业、得体、有信息量的 issue 回复。

回复结构（三层）

  1. 解释场景定位 — 这个功能是为什么场景设计的，让用户理解"为什么当前不支持"
  2. 给出实际影响 — 对用户来说，没有这个功能影响大不大，有没有替代方案
  3. 说明后续计划 — 如果做，给方向；如果不做，诚实说明成本和原因

语气原则

  • 感谢反馈 — 用户花时间提 issue 值得尊重
  • 不甩锅 — 不说"你用错了"，说"这个场景我们还没覆盖到"
  • 给具体建议 — 不只说"不行"，要告诉用户现在怎么办
  • 量化成本 — 让用户理解不是不想做，是客观上成本高

回复模板

Hi @{用户名}，感谢反馈！

**1. 功能定位**
{这个功能是为什么场景设计的，为什么当前不支持用户的场景}

**2. 对你的实际影响**
{用户现在能不能绕过，怎么绕过，核心功能是否受影响}

**3. 关于{用户期望的能力}**
{成本说明 + 后续计划}

输出： 回复草稿，等用户确认后发布。

禁止：

  • 不经用户确认就直接发布到 GitHub
  • 用技术黑话回复非技术用户
  • 只说结论不解释原因

第 6 步：发布

用户确认回复内容后：

  1. 通过 gh issue comment 发布评论
  2. 根据定性结果打标签（bug / enhancement / wontfix / question）
  3. 如果需要记录为需求，提醒用户是否要加到需求池

过程中的沟通规范

AI 主导的节奏

  1. 每一步完成后主动推进到下一步
  2. 关键结论让用户确认后再往下走（定性、决策、回复内容）
  3. 技术细节 AI 自己搞定，只向用户展示结论

必须等用户确认的节点

步骤确认什么
第 1 步"issue 内容我理解的对吗？"
第 3 步"这个定性你认同吗？"
第 4 步"这个决策你同意吗？"
第 5 步"回复内容可以发吗？"

不需要问用户的

事项直接做
代码怎么查AI 自己追链路
根因怎么分析AI 自己判断
成本怎么量化AI 自己评估

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

article-study

Free

带用户精读一篇文章/文档并真正学透（不是出摘要）。五步：抽干货 → 切讲次 → 每讲跑「学-考-讲」循环 → 对号入座 → 实操+测验+讲错题+蒸馏。每讲产出 HTML 课件 + 笔记落盘；讲完必考一次，用户复述后必须挑不精确处拧紧；抽象概念上可交互演示（能点能跑）；全程用用户自己的业务场景当案例；学完出多题型自动判分测验卷，最后把收获蒸馏回用户的工具。核心触发条件是用户要的是"学会"而不是"要一份结果"，例如"我们一起学这篇文章/这个链接"、"带我学"、"精读"、"我想学会 X"、"这篇我看不懂你给我讲讲"。有具体材料（链接、本地文件、PDF，或用户自己的 skill/文档/代码）时直接开跑；只有学习意图而没材料时仍走本 skill，但开工第一件事是和用户一起把材料定下来，禁止凭记忆开讲。不适用于：只要一份总结/摘要/教程长文，用户读完就完、不需要答题（用 readable-output）、只是搜集资料做调研（使用可用的网页/平台取材工具）、帮我写 PRD/测试用例（用 prd-test-writer）、以及用户其实是想让你直接把活干了（那就直接做）。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

backend-logic-design

Free

和用户一起把一个功能「看不见的部分」敲定：数据存哪、谁写谁读、怎么加载、怎么保存、默认值和升级、核心执行规则、出问题时怎么办、旧东西怎么迁。每条规则带编号、案例和状态（已定 / 方案里有但你没拍板 / 待你定 / AI 定），用户只回答带案例的新选择题、过目没拍过板的规则；给用户看的是按「你会问的问题」分组的问答卡片（最绕的逻辑配可点的模拟器）；最后请另一家模型只读查边界，问题闭环后封成后端逻辑包，PRD、测试用例和代码审核按规则编号追溯。触发：前端交互已定、用户说「还有很多后端逻辑 / 加载 / 配置要讲清楚」「有没有遗漏的边界条件」「规则讲清楚」；或没有界面但规则复杂的功能（调度、同步、配置、额度、迁移）。分三档用：规则多且互相影响出完整包；少量清楚的变化只出规则表；行为不变的技术修复跳过。不适用于：页面长什么样、怎么排（用 page-solution-design）；写 PRD / 测试用例（本 skill 的规则包是它们的输入）；纯代码重构、性能调优、架构巡检报告。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

case-radar

Free

案例雷达。给一个新东西（新工具/新概念/新生态），扫一遍生态找好玩的真实案例，重点是抓"真物"（截图/源码/演示）而不是 GitHub 主页，输出可浏览的 HTML 案例集。当用户说"看看大家用 X 做了什么"、"扫一下 X 生态"、"市面上 X 有什么新玩法"、"给我看 X 的真物案例"、"/case-radar"时触发。不适合：① 已有明确目标的深度调研（使用可用的调研工具直接研究）② 写文章/出 PRD（用 writing-assistant / prd-test-writer）③ 单纯求知不需要 HTML（直接问就好）。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

comic-maker

Free

教程漫画「小课堂」：你的 IP 当老师（没有就先生成一个），3:4 竖版，一期默认 6–9 页（用户要几页就几页），固定有「开课」封面和「下课」结尾，交给 Codex 内置 imagegen 出图并核对。当用户说"画漫画"、"做一套漫画讲XXX"、"用漫画解释"、"小课堂"、"换个老师 / 换角色"时触发。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

dual-agent-collaboration

Free

让 Codex 与 Claude Code 通过本机 CLI 组成“主执行者 + 独立审查者”的对称协作闭环。用于用户要求两个模型一起完成、交叉校核、独立审查、修到 ACK，或任务涉及产品需求收敛、复杂方案、跨模块开发、迁移、安全、重要重构和高质量交付时；无论从 Codex 还是 Claude Code 启动，都由当前模型主持，并完整调用另一方完成需求挑战、方案门禁、实现冷审和最终验收。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

find-top-three

Free

通过自适应获取上下文、读取证据、建立可修正的用户模型和进行战略判断，帮助用户找出当前阶段最重要的三件事。适用于用户询问“最重要的三件事”“我现在应该先做什么”，需要梳理人生或职业优先级，在多个目标之间犹豫，思考自由、收入、个人业务、内容创作或创业重点，或者希望模型持续了解自己后再给建议；不用于简单待办排序，也不用于目标已经确定的项目计划。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

See all skills by yunshu0909

Report a problem with this skill