k-audit
系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离,产出批量发现清单。触发:用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离,产出批量发现清单。触发:用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
维护 `.kflow/architecture/` 这份只记现状的系统地图,三种模式 update / check / backfill。触发:用户说"刷新 architecture"、"做架构检查"、"补这个模块的架构文档"、"方案和代码对得上吗",或 feature 阶段需要先做架构动作。不写未来规划(走 k-roadmap)。
feature 流程阶段 3——验收闭环:对照 design 核实现 + 回写 architecture / requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 k-feat-impl 完成。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进,每步具体改哪个文件由 implement 自决,写完用统一格式汇报。触发:用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险,给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发:用户说"分析这个 bug"、"找根因"、"定位问题",且已有 {slug}-report.md。
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口:标准路径从 analyze 来,快速通道从 report 直接来。触发:用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件,不顺手优化。
| name | k-audit |
| description | 系统审计——从代码中主动发现 bug 隐患、安全漏洞、性能问题、可维护性债务和架构偏离,产出批量发现清单。触发:用户说"审查系统"、"审计代码"、"扫描问题"、"找找 bug"、"有什么可以优化的"。 |
开始任何判断或动作前,先读取 .kflow/attention.md;缺失则视为骨架不完整,提示先补齐或运行 k-onboard。
k-issue 等你报 bug,k-refactor 等你指优化点,k-explore 等你提问题——但"我也不知道哪有问题,你先扫一遍看看"这个诉求没人接。k-audit 补上这块:在用户限定的范围内主动扫描,产出一份按严重度 × 性质交叉分类的发现清单。
本技能只发现、不定修。修是 k-issue / k-refactor 的事。
.kflow/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)和建议动作(k-issue / k-refactor)。
完整模板见 reference.md。
审计不能全仓库盲扫——成本高、噪音大。先帮用户把范围收窄到可执行。
问用户三样(有一样就能起步):
src/services/ 下面"用户描述已清楚直接进 Phase 2。用户说"整个项目都扫" → 推回去——建议先扫最常改的模块或最近出过问题的区域。
收敛后给用户确认:"扫 src/services/order/ 和 src/api/order.ts,约 12 个文件,看安全 / 性能 / bug 隐患三个维度。范围 OK 吗?"
按用户圈定的维度逐维扫描(用户没指定就全扫 5 维):
.kflow/architecture/ 记录不一致、分层泄漏、跨模块隐式耦合扫描时用 Glob / Grep / Read 真实读代码。每条发现必须记录 文件:行号 + 具体代码片段。
上限:每种维度最多报 5 条。不是凑数——够了就停,不够也不硬凑。
置信度口径:
high:代码路径可确认触发,影响明确medium:静态分析能定位问题,但触发条件不确定low:线索可疑,需要进一步确认但值得标记index.md:范围、总评、发现清单表格(交叉分类)finding-NN.md先写 index 再写 finding——这个顺序让 AI 先做整体判断再展开细节,避免陷入单条发现迷失全局。
index.md 末尾给优先级建议:
用户选哪条 → 路由到 k-issue 或 k-refactor。k-audit 自己不修。
| 技能 | 触发 | k-audit 怎么对待 |
|---|---|---|
k-issue | 用户报已知 bug | audit 发现 bug 后建议开 k-issue |
k-refactor | 用户指已知优化点 | audit 发现可优化点后建议开 k-refactor |
k-explore | 围绕一个问题查代码 | audit 是批量扫多个维度,不等同于 explore |
k-arch | 维护架构文档 | k-arch 维护文档,k-audit 检查代码是否偏离文档 |
k-security-review | 安全审查 | audit 的安全维度是轻量扫描,深度安全审查走专项 |
high.kflow/architecture/ 对照status: superseded + superseded-by: {新目录}reference.md — index.md / finding-NN.md 模板.kflow/reference/shared-conventions.md — 共享口径索引,按需打开具体小文件.kflow/architecture/ — 架构偏离类发现对照源