Back to Details

quality-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Quality Audit Workflow

质量审计工作流

Purpose

用途

Orchestrates a systematic, parallel quality audit of any codebase with automated remediation through PR generation and PM-prioritized recommendations.
通过PR生成和产品经理优先级排序建议，对任意代码库进行系统化的并行质量审计并提供自动化修复方案。

When I Activate

触发条件

I automatically load when you mention:
  • "quality audit" or "code audit"
  • "codebase review" or "full code review"
  • "refactoring opportunities" or "technical debt audit"
  • "module quality check" or "architecture review"
  • "parallel analysis" with multiple agents
当你提及以下内容时我会自动加载：
  • "quality audit" 或 "code audit"
  • "codebase review" 或 "full code review"
  • "refactoring opportunities" 或 "technical debt audit"
  • "module quality check" 或 "architecture review"
  • 多Agent并行分析相关需求

What I Do

功能说明

Execute a 7-phase workflow that:
  1. Familiarizes with the project (investigation phase)
  2. Audits using parallel agents across codebase divisions
  3. Creates GitHub issues for each discovered problem 3.5. Validates against recent PRs (prevents false positives)
  4. Generates PRs in parallel worktrees per remaining issues
  5. Reviews PRs with PM architect for prioritization
  6. Reports consolidated recommendations in master issue
执行包含7个阶段的工作流：
  1. 熟悉项目（调研阶段）
  2. 并行审计 调用多Agent对代码库各分区进行审计
  3. 创建 GitHub issue记录所有发现的问题 3.5. 校验 对比近期PR避免误报
  4. 并行生成PR 在独立工作树中为每个剩余问题生成PR
  5. PM评审 由PM架构师对PR进行优先级排序
  6. 输出报告 在主issue中汇总所有建议

Quick Start

快速开始

User: "Run a quality audit on this codebase"
Skill: *activates automatically*
       "Beginning quality audit workflow..."
User: "Run a quality audit on this codebase"
Skill: *activates automatically*
       "Beginning quality audit workflow..."

The 7 Phases

7个阶段详解

Phase 1: Project Familiarization

阶段1：项目调研

  • Run investigation workflow on project structure
  • Map modules, dependencies, and entry points
  • Understand existing patterns and architecture
  • 运行项目结构调研工作流
  • 梳理模块、依赖和入口点
  • 理解现有开发模式和架构

Phase 2: Parallel Quality Audit

阶段2：并行质量审计

  • Divide codebase into logical sections
  • Deploy multiple agent types per section (analyzer, reviewer, security, optimizer)
  • Apply PHILOSOPHY.md standards ruthlessly
  • Check module size, complexity, single responsibility
  • 将代码库划分为逻辑分区
  • 为每个分区部署多种类型Agent（分析器、评审员、安全专家、优化器）
  • 严格执行PHILOSOPHY.md规范
  • 检查模块大小、复杂度、单一职责原则符合度

Phase 3: Issue Assembly

阶段3：问题归集

  • Create GitHub issue for each finding
  • Include severity, location, recommendation
  • Tag with appropriate labels
  • Add unique IDs, keywords, and file metadata
  • 为每个发现的问题创建GitHub issue
  • 包含严重等级、位置、修复建议
  • 打上对应标签
  • 添加唯一ID、关键词和文件元数据

Phase 3.5: Post-Audit Validation [NEW]

阶段3.5：审计后校验 [新增功能]

  • Scan merged PRs from last 30 days (configurable)
  • Calculate confidence scores for PR-issue matches
  • Auto-close high-confidence matches (≥90%)
  • Tag medium-confidence matches (70-89%) for verification
  • Add bidirectional cross-references between issues and PRs
  • Target: <5% false positive rate
  • 扫描过去30天（可配置）内合并的PR
  • 计算PR和issue匹配的置信度得分
  • 自动关闭高置信度匹配项（≥90%）
  • 标记中等置信度匹配项（70-89%）待人工核验
  • 在issue和PR之间添加双向交叉引用
  • 目标：误报率<5%

Phase 4: Parallel PR Generation

阶段4：并行PR生成

  • Create worktree per remaining open issue (
    worktrees/fix-issue-XXX
    )
  • Run DEFAULT_WORKFLOW.md in each worktree
  • Generate fix PR for each confirmed open issue
  • 为每个剩余未关闭issue创建独立工作树（
    worktrees/fix-issue-XXX
    ）
  • 在每个工作树中运行DEFAULT_WORKFLOW.md
  • 为每个确认的未解决问题生成修复PR

Phase 5: PM Review

阶段5：PM评审

  • Invoke pm-architect skill
  • Group PRs by category and priority
  • Identify dependencies between fixes
  • 调用pm-architect skill
  • 按类别和优先级对PR分组
  • 识别修复项之间的依赖关系

Phase 6: Master Report

阶段6：总报告生成

  • Create master GitHub issue
  • Link all related issues and PRs
  • Prioritized action plan with recommendations
  • 创建总览GitHub issue
  • 关联所有相关的issue和PR
  • 输出带优先级的行动计划和建议

Philosophy Enforcement

规范强制校验

This workflow ruthlessly applies:
  • Ruthless Simplicity: Flag over-engineered modules
  • Module Size Limits: Target <300 LOC per module
  • Single Responsibility: One purpose per brick
  • Zero-BS: No stubs, no TODOs, no dead code
  • Anti-Fallback (#2805, #2810): Detect silent degradation and error swallowing patterns
  • Structural Analysis (#2809): Flag oversized files, deeply nested code, and tangled dependencies
本工作流严格执行以下规则：
  • 极致简洁：标记过度设计的模块
  • 模块大小限制：每个模块目标LOC<300
  • 单一职责：每个代码块仅承担一个功能
  • 零冗余：不允许存根、TODO注释、死代码
  • 反降级设计（#2805, #2810）：检测静默降级和错误吞噬模式
  • 结构分析（#2809）：标记过大文件、深层嵌套代码和混乱依赖

Detection Categories

检测类别

Standard Categories

标准类别

CategoryWhat It Detects
SecurityHardcoded secrets, missing input validation
ReliabilityMissing timeouts, bare except clauses
Dead CodeUnused imports, unreachable branches, stale TODOs
Test GapsFiles without tests, tests without assertions
Doc GapsPublic functions without docstrings, outdated docs
类别检测内容
安全硬编码密钥、缺失输入校验
可靠性缺失超时、裸except语句
死代码未使用的导入、不可达分支、无效TODO
测试缺口无测试的文件、无断言的测试
文档缺口无文档字符串的公共函数、过时文档

Extended Categories

扩展类别

CategoryWhat It Detects
Silent Fallbacks
except: pass
, broad catches that return defaults silently, fallback chains that mask failures
Error SwallowingCatch blocks with no logging/re-raise, error-to-None transforms, catch-all discarding exceptions
Structural IssuesFiles >500 LOC, functions >50 lines, nesting >4 levels, >5 parameters, circular imports
DocumentationPoint-in-time content, unprofessional tone (pirate speak, chatbot artifacts), quality/correctness gaps
Hardcoded LimitsNon-configurable numeric caps (
[:N]
, 
max_X = N
), silent truncation without logging, data loss from processing limits
类别检测内容
静默降级
except: pass
、无提示返回默认值的宽泛捕获、掩盖故障的降级链
错误吞噬无日志/重新抛出的捕获块、错误转None逻辑、丢弃异常的全捕获
结构问题文件>500 LOC、函数>50行、嵌套>4层、参数>5个、循环导入
文档问题时间点相关内容、不专业语气（海盗梗、聊天bot痕迹）、质量/准确性缺口
硬编码限制不可配置的数值上限（
[:N]
、
max_X = N
）、无日志的静默截断、处理限制导致的数据丢失

Multi-Agent Validation (v3.0)

多Agent校验（v3.0）

Every finding is validated by 3 independent agents (analyzer, reviewer, architect). A finding is confirmed only if ≥2 agents agree. This eliminates false positives before any fixes are attempted.
每个发现的问题都需要经过3个独立Agent（分析器、评审员、架构师）校验，只有≥2个Agent达成一致时问题才会被确认，在尝试修复前就能消除误报。

Iterative Loop with Escalating Depth (v3.0)

深度递进迭代循环（v3.0）

Cycle 1: SEEK → VALIDATE (3 agents) → FIX → decision
Cycle 2: SEEK (deeper) → VALIDATE → FIX → decision
Cycle 3: SEEK (deepest) → VALIDATE → FIX → decision
...continues if thresholds not met
Loop rules:
  • Minimum 3 cycles always run
  • Continue past 3 if: any high/critical findings remain, or >3 medium findings
  • Maximum 6 cycles (safety valve)
  • Each cycle: fresh eyes, dig deeper, challenge prior findings
  • Fixes use the full DEFAULT_WORKFLOW approach (understand → test → implement → verify)
Run via recipe:
bash
amplihack recipe execute quality-audit-cycle.yaml --context '{"target_path": "src/amplihack", "min_cycles": "3", "max_cycles": "6"}'
Cycle 1: SEEK → VALIDATE (3 agents) → FIX → decision
Cycle 2: SEEK (deeper) → VALIDATE → FIX → decision
Cycle 3: SEEK (deepest) → VALIDATE → FIX → decision
...未达到阈值则继续循环
循环规则：
  • 至少运行3个循环
  • 存在高/严重等级问题或中等问题>3个时，3个循环后继续执行
  • 最多运行6个循环（安全阈值）
  • 每个循环：全新视角、更深层挖掘、质疑之前的结论
  • 修复采用完整DEFAULT_WORKFLOW流程（理解→测试→实现→验证）
通过recipe运行：
bash
amplihack recipe execute quality-audit-cycle.yaml --context '{"target_path": "src/amplihack", "min_cycles": "3", "max_cycles": "6"}'

Configuration

配置项

Override defaults via environment or prompt:
Core Settings:
  • AUDIT_PARALLEL_LIMIT
    : Max concurrent worktrees (default: 8)
  • AUDIT_SEVERITY_THRESHOLD
    : Minimum severity to create issue (default: medium)
  • AUDIT_MODULE_LOC_LIMIT
    : Flag modules exceeding this LOC (default: 300)
Recurse Loop Settings (v2.0):
  • max_cycles
    : Maximum audit cycles before stopping (default: 3)
  • validation_threshold
    : Minimum validators that must agree (default: 2)
Phase 3.5 Validation Settings:
  • AUDIT_PR_SCAN_DAYS
    : Days to scan for recent PRs (default: 30)
  • AUDIT_AUTO_CLOSE_THRESHOLD
    : Confidence % for auto-close (default: 90)
  • AUDIT_TAG_THRESHOLD
    : Confidence % for tagging (default: 70)
  • AUDIT_ENABLE_VALIDATION
    : Enable Phase 3.5 (default: true)
可通过环境变量或提示词覆盖默认配置：
核心设置：
  • AUDIT_PARALLEL_LIMIT
    ：最大并发工作树数量（默认：8）
  • AUDIT_SEVERITY_THRESHOLD
    ：创建issue的最低严重等级（默认：中等）
  • AUDIT_MODULE_LOC_LIMIT
    ：超过该LOC的模块会被标记（默认：300）
递归循环设置（v2.0）：
  • max_cycles
    ：最大审计循环次数（默认：3）
  • validation_threshold
    ：最少需要同意的校验者数量（默认：2）
阶段3.5校验设置：
  • AUDIT_PR_SCAN_DAYS
    ：扫描近期PR的时间范围（天）（默认：30）
  • AUDIT_AUTO_CLOSE_THRESHOLD
    ：自动关闭的置信度百分比（默认：90）
  • AUDIT_TAG_THRESHOLD
    ：标记待核验的置信度百分比（默认：70）
  • AUDIT_ENABLE_VALIDATION
    ：是否启用阶段3.5（默认：开启）