メニュー
对指定目录/模块/skill 进行全量代码审计（不依赖 git diff）。支持逻辑、安全、性能、架构、集成与环境、可迁移性、必要性 7 个维度的审查，特别适合审计 skills 是否绑定 Claude Code、Codex、CodeAgent 或特定机器环境。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/zhuqingxun/zqxbase --skill rpiv-loop-code-auditコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
| name | rpiv-loop:code-audit |
| description | 对指定目录/模块/skill 进行全量代码审计（不依赖 git diff）。支持逻辑、安全、性能、架构、集成与环境、可迁移性、必要性 7 个维度的审查，特别适合审计 skills 是否绑定 Claude Code、Codex、CodeAgent 或特定机器环境。 |
| argument-hint | <目标> [logic|security|performance|architecture|integration|portability|necessity] |
| allowed-tools | Read, Glob, Grep, Bash, Edit, Write |
| version | 2.17.15 |
对指定目录、文件、模块或 skill 进行全量代码审计。
从 $ARGUMENTS 中解析：
rpiv-loop:code-audit）：先在当前运行面的 skills 根目录中按 <name-with-colon-replaced-by-hyphen>/ 解析；若不存在，再扫描该 skills 根目录下 SKILL.md 的 frontmatter name 精确匹配。若当前运行面没有可发现的 skills 根目录，停止审计并要求用户提供明确路径。self / 自身：当正在执行本 skill 且能发现当前 skill 目录时，解析为当前 skill 目录；否则要求用户提供明确路径。logic | 逻辑 — 逻辑正确性security | 安全 — 安全漏洞performance | 性能 — 性能问题architecture | 架构 — 架构与设计integration | 集成 — 集成与环境兼容性portability | migration | 可迁移性 | 迁移 | 环境中立 — skills/代码的跨运行面、跨工具、跨机器迁移能力necessity | 必要性 | 价值 — 内容必要性与过度设计（该做不该做，区别于其余维度的做得对不对）logic,security 或 逻辑,安全（中英文可混用）SKILL.md 时，可迁移性维度必须执行；如果用户指定的维度不包含 portability，自动追加并在报告中说明原因。necessity 维度一律执行；如果用户指定的维度不包含 necessity，自动追加并在报告中说明原因。自动追加时执行基础检查项，仅当用户显式指定 necessity 时才进入深度模式。与 portability 的追加叠加时（目标是 skill 且用户只指定了其他维度），两条追加原因在报告中分别说明。示例：
/code-audit neuromem/services/ # 全量审查
/code-audit rpiv-loop:code-audit # 审计已安装 skill
/code-audit self architecture # 审计当前 skill 的架构
/code-audit rpiv-loop:code-audit portability # 仅审计 skill 可迁移性
/code-audit neuromem/services/ architecture # 仅架构深度审查
/code-audit neuromem/services/ 架构 # 同上（中文）
/code-audit backend/app/api/ logic,security # 逻辑+安全深度审查
/code-audit backend/app/api/ 逻辑,安全 # 同上（中文）
/code-audit rpiv-loop:code-audit necessity # 必要性深度模式（找过度设计）
CLAUDE.md、README.md（如果存在）。若目标位于当前运行面的全局 skills 目录，同时读取该运行面的全局规则文件和目标 SKILL.md。CLAUDE.md（如果存在）。docs/ 目录中的编码规范文件（如果存在）。若目标 skill 明确引用共享资源目录，只读取与本次审计相关的共享引用文件，避免把整个插件树误当目标。CLAUDE.md 和项目配置（pyproject.toml、package.json、Dockerfile 等）中识别目标运行环境（Windows/macOS/Linux/跨平台），标记为 cross_platform 如果代码需在多平台运行。.gitattributes 是否存在、是否配置了行尾符规则（* text=auto 等），记录对文件内容的潜在影响；如果目标不在 git 仓库中，记录为 not_git_repo，不要把 git 命令失败当成审计失败。cross_platform = true，在 Phase 2 的逻辑审查、集成审查和可迁移性审查中自动激活跨平台兼容性检查项。.venv/、node_modules/、__pycache__/、.git/、dist/、build/、*.pyc 等依赖、缓存和构建产物。.py、.ts、.js、.tsx、.jsx、.sh、.ps1 等；配置/规范文件包括 .toml、.yaml、.yml、.json。SKILL.md、相关 .md / .mdx 文件和被 SKILL.md 直接引用的脚本也属于主审计对象，不能因为不是传统源代码而跳过。根据参数决定执行模式：
如果当前会话明确允许启动并行审查员，启动 7 个并行审查员，每个审查员接收完整文件清单和项目上下文（含 Phase 0 的环境信息），各自独立完整阅读每个文件后审查。若当前会话未允许或工具不可用，主执行者必须按同样 7 个维度顺序执行审查，不能因为没有并行审查员而跳过维度。
维度 1 — 逻辑审查（基础）：
read_bytes() vs read_text() 是否匹配使用场景？跨平台（Windows CRLF / Unix LF / Git autocrlf）是否影响结果？==、!=、diff）时，追溯两端的完整变换链，检查是否经过了相同的预处理管道（过滤、剥离、归一化、编码转换）维度 2 — 安全审查（基础）：
维度 3 — 性能审查（基础）：
维度 4 — 架构审查（基础）：
维度 5 — 集成与环境审查（基础）：
维度 6 — 可迁移性审查（skills/runtime-portability，基础）：
<skill-root>、<plugin-root>、环境变量、相对路径或可发现路径。Read/Edit/Write/Bash/Glob/Grep、apply_patch、AskUserQuestion 等平台工具当成唯一实现；是否提供等价意图或 fallback。维度 7 — 必要性审查（necessity，基础）：
rpiv/archive/ 归档记录、守卫测试对照——该功能/章节/配置项是否有需求支撑或设计意图记录。tests/ 等目录编码了刻意的设计意图，非对称写法往往是有意为之）；② 查 PRD 与 rpiv/archive/ 归档记录；③ 查 git log 的引入 commit 及 message；④ 从上下文推断用途。跳步得出的发现禁止写入报告。not_available（普通代码仓库没有 rpiv/、没有守卫测试属正常），依赖其余证据源得出结论；不得因证据源缺失而跳过本维度。git 不可用时沿用 Phase 0 的 not_git_repo，第 ③ 步记 not_available。detail 字段，使下方 evidence_check 的记录不因通用报告模板不含该字段而丢失。necessity 的问题条目在通用字段之外额外记录：
necessity_type: confirmed|suspected # 确凿型 | 存疑型
evidence_check:
guard_tests: found|none|not_available
prd_archive: found|none|not_available
git_log: found|none|not_available
context_inference: found|none
上述 necessity_type 与 evidence_check 是 necessity 专属的附加记录，不取代下面的通用返回格式——necessity 的问题条目同时包含通用字段与这两个附加字段。
每个并行审查员或主执行者的单维度审查返回格式：
issues:
- id: CA-001
severity: critical|high|medium|low
confidence: 0-100
file: "path/to/file.py"
line: 42
issue: "一行描述"
detail: "为什么这是问题"
suggestion: "如何修复（含具体代码建议）"
如果当前会话明确允许启动并行审查员，启动 1 个审查员，执行指定维度的深度审查；否则由主执行者直接执行该维度深度审查。无论指定哪个维度，necessity 都会作为额外的基础检查项同时执行（见参数解析中的无条件追加规则），不占用深度审查名额。深度模式在基础检查项之上，额外增加专项深度检查：
logic 深度模式（基础 + 额外）：
==、!=、diff、compare 操作，追溯两端数据的完整变换链，验证变换链的对称性security 深度模式（基础 + 额外）：
performance 深度模式（基础 + 额外）：
architecture 深度模式（基础 + 额外）：
integration 深度模式（基础 + 额外）：
portability 深度模式（基础 + 额外，审计 skills 时重点执行）：
Claude、Codex、CodeAgent、AskUserQuestion、Read、Edit、Write、Bash、apply_patch、绝对路径、home 目录、plugin 源路径等，判断是必要适配还是不必要绑定。necessity 深度模式（基础 + 额外，仅在用户显式指定 necessity 时进入；自动追加时只执行基础检查项）：
组合模式（如 logic,security）：当前会话明确允许启动并行审查员时启动对应数量的并行审查员，每个执行对应维度的深度模式；否则由主执行者逐一执行指定维度。若目标是 skill 且组合中未包含 portability，自动追加 portability。necessity 的追加不设条件：无论目标类型与组合内容，一律追加并执行基础检查项，追加原因与 portability 分别说明。
confidence >= 75 的问题进入正式报告，低于 75 的归入"低置信度附录"。
CA-001），后续 deferred/todo 和 code-review-fix 都引用该 ID。severity = critical 或 high 的问题，使用 Grep 搜索该函数/类/方法在项目中的所有引用方，记录到 blast_radius 字段；若目标是 Markdown/skill 规范且没有函数符号，则搜索相关 heading、frontmatter name 或关键短语。根据审查发现计算健康度评分：
portability 时纳入平均；necessity 无条件追加，任何模式下均纳入平均）保存到 rpiv/validation/code-audit-{kebab-case-target-name}.md
rpiv/validation/ 目录不存在则创建。rpiv/validation/。当目标位于全局 skill 安装目录或其他全局配置目录时，不要把过程报告写回全局 skill 目录，除非用户明确要求。{kebab-case-target-name} 从目标路径、文件名或 skill 名称生成（如 neuromem-services、backend-app-api、rpiv-loop-code-audit）---
description: "代码审计: {target}"
status: pending
created_at: {YYYY-MM-DDTHH:MM:SS}
updated_at: {YYYY-MM-DDTHH:MM:SS}
archived_at: null
---
# 代码审计: {target}
## 健康度: {等级} ({总分}/100)
| 维度 | 评分 | 说明 |
|------|------|------|
| 逻辑正确性 | {分数} | {一句话总结} |
| 安全性 | {分数} | {一句话总结} |
| 性能 | {分数} | {一句话总结} |
| 架构 | {分数} | {一句话总结} |
| 集成与环境 | {分数} | {一句话总结} |
| 可迁移性 | {分数} | {一句话总结} |
| 必要性 | {分数} | {一句话总结} |
**统计：**
- 扫描文件数：{N}
- 发现问题数：{N}（critical: {n}, high: {n}, medium: {n}, low: {n}）
- 过滤低置信度：{N} 个
## 整体存在性评估
**结论**：{保留 | 简化保留 | 建议合并到 X | 建议废弃}（四选一）
**理由**：{该目标的核心职责；项目内是否已有承担同一职责的机制；合并或废弃的收益与代价}
> 当结论为"建议合并到 X"或"建议废弃"时，除本节叙述外，还必须在"发现的问题"列表中产出一条对应的 necessity 问题条目（带稳定 ID 与 `status: open`），并在本节标注该 ID，使该结论能进入 `code-review-fix` 闭环。结论为"保留"或"简化保留"时本节不产出问题条目——简化点已由逐条问题承载。
## 发现的问题
### Critical
id: {ID}
severity: critical
confidence: {0-100}
status: open
file: {path/to/file.py}
line: {行号}
issue: {一行描述}
detail: {为什么这是问题}
suggestion: |
{如何修复，含具体代码建议}
blast_radius: |
被 {N} 处调用：
- {caller_file}:{line}
- {caller_file}:{line}
### High
{同上格式}
### Medium
{同上格式}
### Low
{同上格式}
## 低置信度附录
以下问题置信度 < 75，可能是误报，供参考：
{同上格式，但标注 confidence 分数}
如果未发现任何问题：
## 健康度: A (100/100)
代码审计通过。未检测到技术问题。
## 整体存在性评估
**结论**：保留
**理由**：{一句话说明该目标的核心职责及其不可替代性}
necessity 时进入深度模式。追加原因需在报告中说明，与 portability 的追加原因分别陈述。line: 1 并说明原因。code-review-fix 流程（status: open 字段），修复时使用 /rpiv-loop:code-review-fix当审计报告中的 critical/high 问题被标记为 deferred 时，必须在 rpiv/todo/ 中创建对应的跟踪文件。文件格式必须遵循 record 技能的标准模板：
---
title: "{问题标题}（审计 {ID}）"
type: issue
status: open
priority: high|medium
source: rpiv/validation/{audit-report-name}.md#{ID}
created_at: {YYYY-MM-DDTHH:MM:SS}
updated_at: {YYYY-MM-DDTHH:MM:SS}
---
# {问题标题}
## 问题现象
{从审计报告中提取的问题描述}
## 根本原因
{如果审计已分析出原因则填写，否则写"待分析"}
## 影响范围
{受影响的文件和模块}
## 已知 Workaround
{如果有临时解决方案则填写，否则写"无"}
## 已尝试的方案
无
## 参考
- 审计报告：{source 路径}
关键要求：
title（不是 description）type: issueidrpiv/todo/fix-{kebab-case-name}.md