How to install cs-audit
npx skills add https://github.com/liuzhengdongfortest/codestable --skill cs-auditFull instructions (SKILL.md)
Source of truth, from liuzhengdongfortest/codestable.
name: cs-audit description: 系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离,产出批量发现清单。触发:用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。
cs-audit
启动必读
开始任何判断或动作前,先读取 .codestable/attention.md;缺失则视为骨架不完整,提示先补齐或运行 cs-onboard,不要回退到外部 AI 入口文件。
cs-issue 等你报 bug,cs-refactor 等你指优化点,cs-keep 等你说"这事记一下"——但"我也不知道哪有问题,你先扫一遍看看"这个诉求没人接。cs-audit 补上这块:在用户限定的范围内主动扫描,产出一份按严重度 × 性质交叉分类的发现清单。
本技能只发现、不定修。修是 cs-issue / cs-refactor 的事。
文件放哪儿
.codestable/audits/{YYYY-MM-DD}-{slug}/
├── index.md # 速览:范围、总评、发现清单交叉矩阵
├── finding-01.md
├── finding-02.md
└── ...
日期取审计当天。slug 短到一眼看出审计目标(auth-module、order-flow、payment-security)。
所有 audit 文档带 YAML frontmatter(doc_type 分别为 audit-index 和 audit-finding)便于 search-yaml.py 检索。
维度矩阵(交叉分类)
每个发现打两个标签:
性质:bug | security | performance | maintainability | arch-drift
严重度:P0(必须修)| P1(应该修)| P2(可以修)
交叉示例:
security×P0:SQL 注入、明文存密码bug×P1:特定边界条件下空指针,实际触发概率低performance×P2:循环内多余的对象分配,热点路径才需要改
另外每个发现带 置信度(high / medium / low)和建议动作(cs-issue / cs-refactor)。
完整模板见 reference.md。
工作流
Phase 1:范围收敛
审计不能全仓库盲扫——成本高、噪音大。先帮用户把范围收窄到可执行。
问用户三样(有一样就能起步):
- 关键词:"跟 auth / payment / upload 相关的"
- 模块 / 目录:"
src/services/下面" - 一段话描述:"最近用户反馈订单页慢,帮我扫一下订单相关代码"
用户描述已清楚直接进 Phase 2。用户说"整个项目都扫" → 推回去——建议先扫最常改的模块或最近出过问题的区域。
收敛后给用户确认:"扫 src/services/order/ 和 src/api/order.ts,约 12 个文件,看安全 / 性能 / bug 隐患三个维度。范围 OK 吗?"
Phase 2:扫描
按用户圈定的维度逐维扫描(用户没指定就全扫 5 维):
- bug 隐患:空值路径、边界条件缺失、竞态条件、错误处理吞异常、类型断言无保护
- 安全:注入风险、敏感数据暴露、权限校验缺失、不安全依赖
- 性能:N+1 查询、重复计算、无缓存热点路径、内存泄漏、无分页全量加载
- 可维护性:超长函数(> 80 行)、圈复杂度 > 15、重复逻辑块、神秘常量、循环依赖
- 架构偏离:代码违反
.codestable/requirements/adrs/已拍板决策、分层泄漏、跨模块隐式耦合
扫描时用 Glob / Grep / Read 真实读代码。每条发现必须记录 文件:行号 + 具体代码片段。
上限:每种维度最多报 5 条。不是凑数——够了就停,不够也不硬凑。
置信度口径:
high:代码路径可确认触发,影响明确medium:静态分析能定位问题,但触发条件不确定low:线索可疑,需要进一步确认但值得标记
Phase 3:定级 + 产出
- 每个发现打性质 + 严重度 + 置信度 + 建议动作
- 写
index.md:范围、总评、发现清单表格(交叉分类) - 逐条写
finding-NN.md
先写 index 再写 finding——这个顺序让 AI 先做整体判断再展开细节,避免陷入单条发现迷失全局。
Phase 4:建议下一步
index.md 末尾给优先级建议:
- "P0 的 3 条建议立刻开 issue 修"
- "P1 的 5 条可以排下个迭代"
- "P2 的 4 条有空再看"
用户选哪条 → 路由到 cs-issue 或 cs-refactor。cs-audit 自己不修。
与相邻技能的边界
| 技能 | 触发 | cs-audit 怎么对待 |
|---|---|---|
cs-issue | 用户报已知 bug | audit 发现 bug 后建议开 cs-issue |
cs-refactor | 用户指已知优化点 | audit 发现可优化点后建议开 cs-refactor |
cs-keep | 沉淀单点经验 / 决策 | audit 是批量扫多维度发现新问题,cs-keep 是把已知的事写下来 |
cs-domain | 维护 ADR / CONTEXT.md | cs-domain 写决策,cs-audit 检查代码是否偏离已拍板的 ADR |
cs-security-review | 安全审查 | audit 的安全维度是轻量扫描,深度安全审查走专项 |
守护规则
- 不盲扫全仓库——Phase 1 必须收敛范围,没范围不动手
- 每条发现必有证据——file:line + 代码片段 + 为什么构成问题。不准出现"感觉不好"、"可能有问题"类无证据发现
- 置信度必标——不准所有发现都标
high - 每种维度上限 5 条——逼 AI 挑最值得报的,不是 dump 所有发现
- 只发现不定修——cs-audit 不出代码改动。出现"顺便修了"就算越界
- 架构偏离引用 ADR——不准凭记忆判断架构应该长什么样,必须读
.codestable/requirements/adrs/对照 - 旧审计标注过期——同名模块新审计覆盖旧审计时,旧 index 标
status: superseded+superseded-by: {新目录}
退出条件
- 审计范围已和用户确认
- 各维度扫描完成,至少有一个发现(若零发现:告知用户此范围内未发现明显问题)
- index.md 含完整交叉分类表
- 每条发现 file:line + evidence + confidence
- 每种维度 ≤ 5 条
- 给用户按优先级排列的下一步建议
相关文档
reference.md— index.md / finding-NN.md 模板.codestable/reference/shared-conventions.md— 跨工作流共享口径.codestable/requirements/adrs/— 架构偏离类发现对照源
Related skills
More from liuzhengdongfortest/codestable and the wider catalog.
cs-feat-design
feature 流程阶段 1——为新功能起草 {slug}-design.md 和 {slug}-checklist.yaml,先交给 cs-feat-design-review 做人审前方案审查,再由用户整体确认为 approved。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
cs-feat-accept
feature 流程阶段 3——验收闭环:对照 design 核实现 + review 报告 + QA 报告或验收现场验证证据 + 盘点 cs-domain 候选(提示而非代写)+ 回写 requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 cs-feat-impl 完成、cs-code-review 通过;如果未单独执行 cs-feat-qa,accept 必须现场补齐同等验证证据。
cs-onboard
把新仓库或有零散文档的仓库接入 CodeStable 体系,两条路径自动判断:空仓库从零搭骨架,已有文档走审计 + 迁移映射。触发:用户说"在这个项目里用 CodeStable"、"搭 CodeStable 结构"、"初始化 CodeStable"、"迁移到 CodeStable"。
cs-brainstorm
想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
cs-feat-impl
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进,每步具体改哪个文件由 implement 自决,写完用统一格式汇报;也处理 cs-code-review 返回的 review-fix 和 cs-feat-qa 返回的 qa-fix。触发:用户说"方案确认了开始实现"、"按方案写代码"、"开工"、"修 review blocking"、"修 QA 失败项"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
cs-refactor
代码优化的子流程入口,处理"行为不变、结构变"的工作(结构 / 性能 / 可读性),按 scan → design → apply 分步执行每步人工放行。触发:用户说"优化一下 / 重构 / 重写 / 拆一下 / 性能不行 / 代码太长"且不夹带行为改动。不处理新需求 / bug / 跨模块架构重划。