// 系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离，产出批量发现清单。触发：用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。
| name | cs-audit |
| description | 系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离，产出批量发现清单。触发：用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。 |
cs-issue 等你报 bug，cs-refactor 等你指优化点，cs-explore 等你提问题——但"我也不知道哪有问题，你先扫一遍看看"这个诉求没人接。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。
审计不能全仓库盲扫——成本高、噪音大。先帮用户把范围收窄到可执行。
问用户三样（有一样就能起步）：
src/services/ 下面"用户描述已清楚直接进 Phase 2。用户说"整个项目都扫" → 推回去——建议先扫最常改的模块或最近出过问题的区域。
收敛后给用户确认："扫 src/services/order/ 和 src/api/order.ts，约 12 个文件，看安全 / 性能 / bug 隐患三个维度。范围 OK 吗？"
按用户圈定的维度逐维扫描（用户没指定就全扫 5 维）：
codestable/architecture/ 记录不一致、分层泄漏、跨模块隐式耦合扫描时用 Glob / Grep / Read 真实读代码。每条发现必须记录 文件:行号 + 具体代码片段。
上限：每种维度最多报 5 条。不是凑数——够了就停，不够也不硬凑。
置信度口径：
high：代码路径可确认触发，影响明确medium：静态分析能定位问题，但触发条件不确定low：线索可疑，需要进一步确认但值得标记index.md：范围、总评、发现清单表格（交叉分类）finding-NN.md先写 index 再写 finding——这个顺序让 AI 先做整体判断再展开细节，避免陷入单条发现迷失全局。
index.md 末尾给优先级建议：
用户选哪条 → 路由到 cs-issue 或 cs-refactor。cs-audit 自己不修。
| 技能 | 触发 | cs-audit 怎么对待 |
|---|---|---|
cs-issue | 用户报已知 bug | audit 发现 bug 后建议开 cs-issue |
cs-refactor | 用户指已知优化点 | audit 发现可优化点后建议开 cs-refactor |
cs-explore | 围绕一个问题查代码 | audit 是批量扫多个维度，不等同于 explore |
cs-arch | 维护架构文档 | cs-arch 维护文档，cs-audit 检查代码是否偏离文档 |
cs-security-review | 安全审查 | audit 的安全维度是轻量扫描，深度安全审查走专项 |
highcodestable/architecture/ 对照status: superseded + superseded-by: {新目录}reference.md — index.md / finding-NN.md 模板codestable/reference/shared-conventions.md — 跨工作流共享口径codestable/architecture/ — 架构偏离类发现对照源通过 Chrome 扩展控制真实浏览器。需要访问网页、抽取网页数据、点击按钮、填写表单、执行浏览器自动化、提取渲染后的组件证据，或以程序方式操作页面时使用。通过 DOM diff、简化 HTML 和 component evidence pack 返回节省 token 的结构化结果。适用于 browser control、web automation、page scraping、web data extraction、execute JS in browser、web_scan、web_execute_js、open browser、navigate to URL、get page content、fill form、click button、extract component、rendered DOM、computed styles、component evidence。
想法还模糊时的讨论入口，做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发：用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入，拍板后抽出 checklist。触发：用户说"开始设计方案"、"写 design doc"、"准备实现 XX"，前提是已知道做什么、为谁、怎么算成功。
feature 流程的超轻量通道——不写 design / checklist 直接动手，但先指引 AI 查 CodeStable 知识库再开工。触发：用户说"快速模式"、"fastforward"、"别那么多步骤"、"直接开干"，且需求小到不值得走 design 流程。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险，给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发：用户说"分析这个 bug"、"找根因"、"定位问题"，且已有 {slug}-report.md。
CodeStable 工作流根入口，介绍体系全貌并把诉求路由到对应 cs-* 子技能。触发：用户只输入 `cs`、说"介绍一下 codestable"、"该用哪个技能"、"不知道用哪个"，或诉求还很开放未收敛。本技能只做路由不做事。