需要只读静态审查源代码安全漏洞并产出可供 /triage…

对源码目录做只读静态漏洞扫描，生成 VULN-FINDINGS.json 和 VULN-FINDINGS.md 供分级处置。

适用场景

解决思路

1. 解析参数：<target-dir> 必填；--focus <area> 可重复，只扫描指定焦点区域并跳过 recon；--single 不进行子代理 fan-out，单次顺序扫描；--extra <file> 将文件内容逐字追加到审查简报的类别列表之后；--no-score 跳过 Step 3b 置信度评分。
2. 工具使用：优先用 Glob 和 Grep；若会话未提供，则回退到白名单只读 Bash：用 `rg --files <scope>` / `ls -R` 枚举，用 `rg -n` / `grep -rn` 搜索，用 `wc` / `head` / `file` 嗅探；不得写 helper 脚本，也不得把目标内容管道进 shell 解释器。
3. Step 1 解析 <target-dir>；不存在或没有源文件则报错停止。
4. Step 1 查找 <target-dir>/THREAT_MODEL.md；若存在，解析其 section 3 'Entry points & trust boundaries' 表和 section 4 'Threats' 表，作为 focus areas 和 threat classes 的首选 scoping 输入。
5. Step 1 若无 THREAT_MODEL.md 且无 --focus：做快速 recon，列出源码树，读入口点和 dispatch 代码，按模式 `<subsystem> (<function/file>) — <key operations>` 提议 3-10 个 focus areas，同 harness/prompts/recon_prompt.py。
6. Step 1 若给了 --focus，就只用这些焦点区域。
7. Step 1 在 fan out 前告诉用户将扫描的 focus areas 和源文件数量。
8. Step 2 除非 --single，按每个 focus area 并行 spawn 一个 Task 子代理；并发上限 10；每个子代理拿到填好 focus area 的 review brief。
9. Step 2 小目标（<15 source files）自动 fall through 到 --single。
10. 审查简报：每个子代理获得聚焦区域、TARGET、TRUST BOUNDARY（来自 THREAT_MODEL.md section 3，否则用 'untrusted input → process memory'），任务为只读源码、从代码推理候选漏洞，不 build/run/probe。
11. 报告门槛：有合理利用路径就报告；跳过风格、最佳实践、纯理论且无攻击故事的问题；不确定时用低 confidence 报告而不是丢弃；下游 triage 做严格验证，目标是不要漏。
12. 高价值内存安全（C/C++ 和 unsafe/FFI）：报告 heap-buffer-overflow、stack-buffer-overflow、global-buffer-overflow、heap-use-after-free、double-free、整数溢出影响分配或索引、format-string、由不可信大小字段驱动的无界递归或分配。
13. 高价值注入与代码执行：报告 SQL/command/LDAP/XPath/NoSQL/template injection、文件操作中的 path traversal、unsafe deserialization（pickle、YAML、native）、eval injection、XSS（但遵守下方 React/Angular 规则）。
14. 高价值认证/加密/数据：报告 authentication/authorization bypass、privilege escalation、安全检查上的 TOCTOU、hardcoded secrets、weak crypto、broken cert validation、日志或错误响应中的敏感数据（secrets、PII）。
15. 低价值：简要记录但不停止搜索：无攻击者控制的固定小偏移 null-pointer deref、assertion failures / clean error returns（正确处理，不是 bug）。
16. DO NOT REPORT：volumetric DoS / rate-limiting / resource-exhaustion；但由不可信输入驱动的无界递归、算法复杂度爆炸、ReDoS 可报告。
17. DO NOT REPORT：memory-safe 语言中 unsafe/FFI 之外的内存安全发现。
18. DO NOT REPORT：React/Angular/Vue 中 XSS，除非经由 dangerouslySetInnerHTML、bypassSecurityTrustHtml、v-html 或等价 raw-HTML escape hatch。
19. DO NOT REPORT：测试文件、fixtures、build scripts、docs、.ipynb 中的发现。
20. DO NOT REPORT：没有具体利用的 missing hardening / best-practice gaps。
21. DO NOT REPORT：env vars 和 CLI flags 作为攻击向量（operator-controlled）。
22. DO NOT REPORT：regex injection、log spoofing、open redirect、missing audit logs。
23. DO NOT REPORT：outdated third-party dependency versions。
24. 若传入 --extra <file>，将其内容逐字追加到审查简报此处（category list 后）。
25. 每个报告 finding 追踪：未信任输入从哪里进入、什么路径到达 sink、什么条件触发。
26. 输出格式：每个 finding 一个 <finding> 块，包含 <id>F-{focus_idx:02d}-{n:02d}</id>、<file>{relative/path}</file>、<line>{line_number}</line>、<category>{...}</category>、<severity>{HIGH | MEDIUM | LOW}</severity>、<confidence>{0.0-1.0}</confidence>、<title>{one line}</title>、<description>{root cause, attacker control, trigger condition, data flow from entry to sink. Cite line numbers.}</description>、<exploit_scenario>{concrete attack}</exploit_scenario>、<recommendation>{specific fix}</recommendation>。
27. 严重度定义：HIGH=可直接利用导致 RCE、数据泄露、认证绕过；MEDIUM=特定条件下显著影响；LOW=defense-in-depth。
28. 若某区域彻底阅读后无可报告项，输出一个 <finding>，category=none，并用一行说明覆盖了什么。
29. Step 3 收集所有子代理的 <finding> 块，丢弃 category=none 占位符。
30. Step 3 轻量去重：两个 finding 引用相同 file:line 且相同 category，保留描述更长者并记录重复 id；重去重交给 /triage，不要过度工程化。
31. Step 3 分配稳定 id F-001、F-002...，按 (severity desc, file, line) 排序。
32. Step 3b 若未传 --no-score，执行置信度 pass：为每个 finding 并行 spawn 一个 Task 子代理；这是廉价二次意见，只排序信号质量，不丢弃任何 finding；浅层重读并打分，不做完整可达性追踪。
33. 评分简报：对单个候选 finding 独立 confidence 评分，不决定保留，决定多可能通过严格 triage；可 Read/Grep TARGET，但不执行。
34. 评分步骤 1：重读引用代码，打开 {file} around line {line}，检查代码是否真的如描述所说。
35. 评分步骤 2：检查常见误报模式：volumetric DoS、memory-safe language、test/fixture/doc file、framework auto-escape、env-var vector、missing-hardening-only、regex/log injection、outdated dep；匹配会大幅降低 confidence，但不自动归零。
36. 评分步骤 3：按 1-10 打分：1-3 可能误报/噪声；4-5 貌似合理但推测；6-7 可信需调查；8-10 高置信清晰模式。
37. 评分输出：仅输出 `CONFIDENCE: <1-10>` 和 `REASON: <one line>`。
38. 解析评分：用分数归一化到 0.0-1.0 覆盖 finding 的 confidence，并附加 confidence_reason；按 (confidence desc, severity desc, file, line) 重新排序并重新分配 id F-001..；计算 low_confidence_count = confidence < 0.4 的 findings 数量，用于 summary line。
39. Step 4 写文件到 <target-dir>/：写 VULN-FINDINGS.json，符合 /triage ingest 形状，包含 target、scanned_at（ISO8601）、focus_areas、findings、summary；每个 finding 包含 id、file、line、category、severity、confidence、title、description、exploit_scenario、recommendation、confidence_reason。
40. Step 4 findings 按 confidence desc（再 severity、file、line）排序，使文件顶部为最高信号材料；summary 包含 total、high、medium、low、low_confidence。
41. Step 4 同时写 VULN-FINDINGS.md：先写 summary 表（id | severity | category | file:line | title），再为每个 finding 写 `### F-NNN` 小节，含完整 description。
42. Step 5 向用户汇报：1) 数量：N findings（H/M/L 分布，X low-confidence），跨 K focus areas，来自 M source files；2) 按 confidence 的 Top 3，各一行；3) 下一步命令 `> /triage <target-dir>/VULN-FINDINGS.json --repo <target-dir>`；4) 提醒这些是静态候选、未验证；执行验证的崩溃用 `vuln-pipeline run <target>`（README Step 2）。
43. 约束：绝不执行目标代码，不用 Bash、不 build、不 docker、不联网；若用户要求 reproduce 或 confirm with a PoC，拒绝并指向 vuln-pipeline。
44. 约束：不要伪造行号，每个 file:line 必须是自己 Read 或 Grep 到的；不确定精确行时引用函数并在 description 说明。
45. 约束：留在 <target-dir> 内，不跟随 symlink 或 `..` 离开目标目录。
46. 约束：Findings 是 /triage 的候选，不是最终结论；此技能从不丢弃 finding，Step 3b 只排序；/triage 做严格 N-vote 验证并移除 false positives。

适用边界 · 注意事项

• 需要对代码执行、构建、运行、网络探测或复现 PoC 来确认的漏洞，应改用 vuln-pipeline，而不是本技能。
• 目标不是源码目录、没有源文件，或主要想发现过期第三方依赖版本/仅做最佳实践审计时，本技能会跳过或低报。
• 无法提供只读文件访问、搜索和并行子代理（或至少可顺序执行 --single）的环境。