Adversarial Successor Audit

对抗性接替者审计 / Adversarial Successor Audit

假设你是一个全新的、有洁癖强迫症的接替者。前任匆忙离开，你从零开始接手。你的任务是走完所有流程，找出每一个会让新人卡住的地方。

硬约束：审计只读，不修改任何文件。输出审计报告 + 修正建议。

何时使用

• 一批改动准备提交前（尤其是涉及文档/脚本/工作流/CI 的改动）
• 项目交接前
• 工作流重构后
• 新增自动化脚本后
• 接入新 AI 工具后

流程

1. 确定审计范围

从用户上下文确定：

• 要审计的项目根目录
• 改动范围（全量 or 增量 diff）
• 交付物类型（仓库规则？自动化脚本？CI？文档？）

2. 模拟全流程

以新人身份，依次模拟以下步骤（每一步都检查 references/audit-checklist.md）：

clone → README → 安装依赖 → 初始化(setup) → 日常开发 → 提交 → 同步上游 → 合并 → 发布

每一步问自己：

• 我知道该做什么吗？（文档是否指引清晰）
• 命令能跑通吗？（依赖是否齐全、路径是否正确）
• 出错时有提示吗？（报错信息是否有用）
• 我会不会走歪？（有没有护栏防误操作）

3. 三个子模式检测

对每个发现的问题，用三个子模式深入诊断：

子模式 A — Bootstrap 死循环检测 > 生成物是否依赖生成器，而生成器本身也未入库？ > 判据：git clone 后能否在不依赖任何 git-ignored 文件的情况下完成初始化？

子模式 B — 入库边界三层判据 > 每个文件是否放对了位置？ > - 客观项目规范 → 必须入库 > - 自动化工具 → 必须入库 > - 个人偏好/隐私 → 不入库，本地生成

子模式 C — AI 可调用性检验 > 每个交互式脚本能否在无 stdin 环境下使用？ > 判据：是否支持 --yes / --type= 等非交互参数？

详见 references/sub-patterns.md。

4. 输出审计报告

格式：

# 对抗性接替者审计报告

## 审计范围

## 发现

### [严重] #1: 
- **场景**: 新人在  会遇到 
- **根因**: 
- **修正建议**: 
- **验证方式**: 

### [中等] #2: ...

### [轻微] #3: ...

## 总结
- 严重: N 项
- 中等: N 项
- 轻微: N 项
- 结论: 

不做什么

• 不审查代码逻辑正确性（那是 code review / adversarial-review 的工作）
• 不审查 UI/UX 设计
• 不修改任何文件（只读审计）
• 不做性能分析

参考

• references/audit-checklist.md — 逐步审计清单
• references/sub-patterns.md — 三个子模式详解
• references/examples.md — 实际案例（Cli-Proxy-API-Management-Center-fork）

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: calonye
• Source: calonye/AgentSkills_kelen
• License: MIT

Install and usage instructions live in the source repository linked above.