audit-anything

审计任何内容

执行结构化审计，而不是一般的代码审查。审计技能负责范围、证据规范、严重性、覆盖范围、结论和报告持久化。配对的领域技能提供领域术语和检查标准。不要让领域技能将审计变成实施工作。

配对流程

flowchart TD
    A["Audit request"] --> B{"Named domain skill?"}
    B -- "Yes" --> C["Pair audit + domain skill"]
    B -- "No" --> D{"Domain obvious?"}
    D -- "Yes" --> E["Select best matching skill"]
    D -- "No" --> F["Ask one concise question"]
    C --> G{"Skill available and allowed?"}
    E --> G
    G -- "Yes" --> H["Load domain instructions"]
    G -- "No or explicit-only" --> I["Use composition checklist"]
    F --> I
    H --> J["Run audit loop"]
    I --> J

配对约定

1. 根据请求或目标产物确定审计领域。如果用户指定了其他技能，请阅读该技能并与本技能配合使用。
2. 如果未指定领域技能，但领域显而易见，请使用最合适的可用技能；例如，视觉/UI 设计审查使用 frontend-design，明确要求架构审查时使用 improve-codebase-architecture，模式审查使用 database-schema-designer，Agent 工作流审查使用 ai-agent-workflow。
3. 如果领域确实模糊，请先提出一个简洁的问题，以免在错误的目标上浪费精力。
4. 不要默默调用标记为仅显式调用或模型禁用的技能。请用户调用该技能，或按照 references/compositions.md 中的相应检查清单继续。
5. 配对技能的创作或规划工作流必须服从审计模式。除非用户明确要求修复，否则不要重新设计、重构、安装依赖项或修复代码。

审计模式

选择满足请求的最窄模式：

模式	目标	最低证据要求
变更审计	差异、提交或 PR	完整差异、相关调用路径、测试
模块审计	文件、组件、服务或工作流	入口点、依赖项、状态流、测试
系统审计	架构或领域模型	目录映射、模块边界、数据/控制流、ADR 或文档
在线产品审计	正在运行的应用	实际交互、截图，以及适用时的控制台/网络输出
契约审计	API、模式、事件或数据模型	接口、调用方、约束、迁移、失败场景
文档审计	计划、规范、信息架构、用户流程、报告	完整产物、引用来源、与实现的一致性

对于仅希望发现缺陷的代码变更审查，优先使用 review-agent。如果用户要求更全面的审计、领域评估或持久化报告，请使用本技能。

执行循环

flowchart LR
    A["Frame audit"] --> B["Read local conventions"]
    B --> C["Establish baseline"]
    C --> D["Collect evidence"]
    D --> E["Apply domain checklist"]
    E --> F{"Hard evidence satisfied?"}
    F -- "No" --> G["Downgrade or mark incomplete"]
    F -- "Yes" --> H["Classify findings"]
    G --> H
    H --> I["Assign verdict"]
    I --> J["Persist report"]

流程

1. 明确审计范围。 记录目标、领域、配对视角、模式、预期用户、约束，以及审计范围属于变更、模块、系统、线上产品、合同还是文档。
2. 了解本地约定。 在评估目标前，阅读适用的 AGENTS.md、README、文档、ADR、术语表和现有审计报告。
3. 建立基线。 运行相关的只读检查，例如测试、类型检查、Lint、构建、架构验证或依赖检查。未经授权，不要运行破坏性命令或请求外部服务。
4. 检查并收集证据。 阅读完整的指定对象以及足够的周边代码或文档，以了解其行为。对于线上产品，应实际操作真实流程并记录可观察到的证据。
5. 结合配对视角评估。 使用 references/compositions.md 中的领域检查清单。常见维度包括正确性、安全性、可靠性、性能、可维护性、状态处理、可测试性、可观测性、无障碍性和文档中说明的意图。
6. 仅报告可执行的发现。 每项发现都必须包含具体影响、证据和最小可行的修复方向。不要纳入推测性问题、既有且超出所述范围的问题，或不会妨碍理解行为的风格细节。
7. 如实说明覆盖范围。 列出检查过、抽样检查过以及无法验证的内容。缺少访问权限、凭据、服务或可运行环境时，结论应为不完整，而非通过。
8. 保存报告。 除非用户要求仅在聊天中输出，否则在存在 docs/ 目录时，将完整报告写入 docs/audits/YYYY-MM-DD-<domain>-<target>.md。如果没有 docs/ 目录，则保存到操作系统临时目录，并提供绝对路径。
9. 在聊天中总结。 先给出结论和影响最大的发现，然后说明报告路径和建议的下一步行动。

证据门槛

flowchart TD
    A["Evidence"] --> B{"Source-backed and reproducible?"}
    B -- "No" --> C["Discard or mark speculative"]
    B -- "Yes" --> D{"Hard gate passed?"}
    D -- "No" --> E["Fail or incomplete"]
    D -- "Yes" --> F{"Any P0 or P1 finding?"}
    F -- "Yes" --> G["Fail"]
    F -- "No" --> H{"Only P3 gaps?"}
    H -- "Yes" --> I["Pass"]
    H -- "No" --> J["Conditional pass"]

发现与结论

使用以下优先级：

• P0：阻止发布，或存在严重的正确性、安全性或数据丢失问题。
• P1：影响较大的缺陷或风险，应尽快修复。
• P2：一般缺陷、缺口或可维护性问题。
• P3：值得改进的细节或文档问题。

使用以下一种结论：

• Pass：没有 P0/P1 级发现，且所有约定的硬性门槛均已通过。
• Conditional Pass：没有 P0/P1 级发现，但仍有 P2/P3 级问题。
• Fail：存在一项或多项 P0/P1 级发现，或有硬性门槛未通过。
• Incomplete：缺少必要的访问权限、交互、构建、测试或证据。

每项发现都必须包含：

1. 一行简短的祈使式标题，并标明优先级。
2. 证据，包括文件/行号、命令输出、请求/响应、截图、架构定义或工件引用。
3. 受影响的场景或用户工作流。
4. 说明其对配对领域有何影响。
5. 明确且最小化的下一步修改，而非模糊建议。

报告格式：

# <Domain> Audit: <Target>

Date: YYYY-MM-DD
Scope: <artifact or boundary>
Pairing: audit + <skill or explicit lens>
Mode: <audit mode>

## Verdict

<Pass / Conditional Pass / Fail / Incomplete>

## Flow evidence

Use one or more Mermaid diagrams when they clarify state, sequence, ownership, trust boundary, or failure path. Prefer a diagram for any workflow that spans multiple components or decision points.

## Findings

### [P1] <Imperative finding title>

- Evidence: <path:line, output, screenshot, or quote>
- Impact: <affected workflow and why it matters>
- Next change: <smallest concrete fix direction>

## Coverage

- Inspected: <list>
- Sampled: <list>
- Not verified: <list and why>

## Roadmap

1. <Immediate / P0-P1 action>
2. <Structural action>
3. <Polish or documentation action>

阅读 references/compositions.md，了解特定领域的配对视角、检查问题和硬性证据要求。