本文へ移動
cccskills
無料GitHub で公開

issue-triage

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

yunshu0909/yunshu_skillshub
インストール方法を見る

含まれるファイル（1）

  • SKILL.md6.0 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

用户收到了一个 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 自己评估

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

article-study

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

yunshu0909/yunshu_skillshub7712026年10月11日 更新

backend-logic-design

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

yunshu0909/yunshu_skillshub7712026年10月11日 更新

case-radar

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

yunshu0909/yunshu_skillshub7712026年10月11日 更新

comic-maker

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

yunshu0909/yunshu_skillshub7712026年10月11日 更新

dual-agent-collaboration

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

yunshu0909/yunshu_skillshub7712026年10月11日 更新

find-top-three

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

yunshu0909/yunshu_skillshub7712026年10月11日 更新

yunshu0909 のスキルをすべて見る

このスキルの問題を報告する