Token导航 LogoToken导航

Agent Skill · 研究检索

cs-issue(计算机问题)

用于围绕 GitHub 仓库、Issue、Pull Request、分支、提交和代码协作流程提供辅助能力。它适合让 Agent 查询项目状态、整理变更、辅助创建或检查协作事项,并把仓库中的信息转成可执行的下一步。使用时需要区分只读查询和写入操作;涉及创建 PR、修改 Issue、推送分支或访问私有仓库时,应确认 token 权限、目标仓库范围和用户授权。

cs-issue 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 19,490。

总安装 5,587周安装 240GitHub Stars 480下载 1,958核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:cs-issue(计算机问题)
来源仓库:https://github.com/liuzhengdongfortest/codestable
仓库路径:skills/cs-issue
安装命令:
npx skills add https://github.com/liuzhengdongfortest/codestable --skill cs-issue
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/liuzhengdongfortest/codestable --skill cs-issue

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

cs-issue 用于管理 bug 修复全流程,包括问题报告、根因分析与定点修复三个阶段。核心原则是“只记现象不记根因”,避免带偏后续分析,确保证据化与可追溯。文件存放于 codestable/issues/{YYYY-MM-DD}-{slug}/,包含 report、analysis、fix-note。

不直接写代码,只看当前 issue 走到哪步并决定触发哪个子技能(如 report 或 analyze)。fix-note 是必出产物,用于回溯凭证,无此记录则下次同类问题只能重查 git diff。

来源仓库内路径:skills/cs-issue

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/liuzhengdongfortest/codestable --skill cs-issu…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

cs-issue 怎么安装?

在终端执行 npx skills add https://github.com/liuzhengdongfortest/codestable --skill cs-issue。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

cs-issue 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

cs-issue 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

cs-issue 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

cs-issue 用的人多吗?

公开数据是累计安装 5,587 次,近一周安装 240 次,下载 1,958 次,GitHub 480 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

cs-issue 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
cs-issue

计算机问题 · 本页

5,587480只读未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

cs-issue

修 bug 直觉是"找到错的地方改了完事",但这个直觉路径反复制造同样的麻烦:

  1. 问题描述只在脑子里改完就忘——三个月后 bug 再现没复现步骤留存
  2. 根因没分析就动手——改了表面现象深层问题等下次爆发
  3. 修复范围扩散——发现一个 bug 顺手改五处引入新问题,无法追溯
  4. 没验收闭环——怎么判断改好了?改好了什么?没记录

issue 工作流在"看到问题"和"动手改代码"之间塞缓冲:

发现问题 → 清晰记录(report)→ 根因分析(analyze)→ 定点修复 + 验证(fix)

本技能不写任何东西,只看当前 issue 走到哪步、决定触发哪个子技能。


文件放哪儿

codestable/issues/{YYYY-MM-DD}-{slug}/
├── {slug}-report.md           ← 阶段 1 问题报告
├── {slug}-analysis.md         ← 阶段 2 根因分析
└── {slug}-fix-note.md         ← 阶段 3 修复记录(必出产物)

日期取发现 / 提报问题当天定了不动。slug 能一眼看出是什么问题(auth-token-leak、null-pointer-on-empty-list)。

{slug}-fix-note.md 是阶段 3 必出产物——无论修复简单还是复杂都要写。它不是仪式,是回溯凭证:没有它下次类似问题来你只能从 git log 反推。

所有 issue 文档带 YAML frontmatter(doc_type 分别为 issue-report / issue-analysis / issue-fix)便于 search-yaml.py 按 severity / tags / status 检索。


两条路径

标准路径(问题复杂或根因不明)

阶段子技能主导产出
1 问题报告cs-issue-report用户描述,AI 引导{slug}-report.md
2 根因分析cs-issue-analyzeAI 读代码分析,用户确认{slug}-analysis.md
3 修复验证cs-issue-fixAI 按分析定点修复,用户验证代码 + {slug}-fix-note.md + scoped-commit

阶段间有人工 checkpoint——让用户在每阶段结束有一次明确把关,防止 AI 一口气从问题跑到代码跑出来才发现走偏。

快速通道(问题简单、根因一眼确定)

下面同时满足才进:

  1. AI 读完代码后对根因高度有把握(能明确指出 file:line + 原因)
  2. 修复改动很小(1-2 处)
  3. 无跨模块影响风险

流程压缩成:AI 读代码 → 直接告知根因 + 修复方案 → 用户确认 → AI 修复 → 用户验证通过 → AI 写 {slug}-fix-note.md。只产出一份 fix-note.md,省掉 report 和 analysis。

判定口径:是否进快速通道由 cs-issue-report 的启动检查做唯一正式判定。一旦进标准路径默认不再二次改判——避免三个阶段对路径各说各话。

不能走快速通道:根因有多个候选 / 修复范围涉及多模块 / 需要先复现才能定位 / 用户希望留完整分析存档。


路由

进入本技能先 Glob codestable/issues/,自己读已有文件才有数。

当前状态触发哪个子技能
刚发现问题,没有任何文件cs-issue-report(那里判断走标准还是快速)
report.md 已存在,没 analysis.mdcs-issue-analyze
analysis.md 已存在,代码还没改cs-issue-fix
代码已改,还没修复验证记录cs-issue-fix(走验证)
不确定自己读已有文件按上表对号

用户描述的是新功能需求而不是 bug → 告诉用户走 cs-feat。


与 feature 工作流的边界

  • issue:本来应该好的东西坏了——已有代码里的 bug / 异常行为 / 文档错误 / 性能问题
  • feature:从来没有的东西要加进来——新功能 / 新能力

灰色地带:修 issue 过程中发现需要新增能力才能真正解决——先用 issue 工作流把记录和分析做完,再视情况开 feature。不在 issue 里偷偷做新功能,理由跟 feature 不在 PR 里偷偷修 bug 一样:混着改分不清这次到底改了什么范围。


相关文档

  • codestable/reference/system-overview.md — CodeStable 体系总览
  • codestable/reference/shared-conventions.md — 跨阶段共享口径
  • AGENTS.md — 全项目代码规范
  • codestable/architecture/ARCHITECTURE.md — 根因分析时可能要查

平台分布

Codex

37.23%
按下载量换算729

Claude

29.91%
按下载量换算586

Cursor

17.46%
按下载量换算342

Gemini CLI

8.48%
按下载量换算166

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills