Back to Details

quality-audit-workflow

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生成和PM优先级排序的建议，对任意代码库执行系统化、并行化的质量审计并实现自动修复。

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
当你提及以下内容时，我会自动激活：
  • "质量审计"或"代码审计"
  • "代码库审查"或"全面代码审查"
  • "重构机会"或"技术债务审计"
  • "模块质量检查"或"架构审查"
  • 带有多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. 创建Issue：为每个发现的问题创建GitHub Issue 3.5. 验证：与近期PR进行比对（避免误报）
  4. 生成PR：在并行工作树中为剩余问题自动生成PR
  5. PR评审：由PM架构师对PR进行优先级排序
  6. 汇总报告：在主Issue中整合所有建议

Quick Start

快速开始

User: "Run a quality audit on this codebase"
Skill: *activates automatically*
       "Beginning quality audit workflow..."
用户: "对这个代码库执行质量审计"
Skill: *自动激活*
       "开始质量审计工作流..."

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：Issue整理

  • 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
本工作流严格遵循以下原则：
  • 极致简洁：标记过度设计的模块
  • 模块大小限制：目标每个模块代码行数<300 LOC
  • 单一职责：每个组件仅承担一个功能
  • 零冗余：无存根代码、无TODO注释、无死代码

Navigation Guide

导航指南

When to Read Supporting Files

何时查阅支持文件

reference.md - Read when you need:
  • Detailed phase execution steps
  • Agent-to-phase mappings
  • Codebase division strategies
  • Issue template formats
examples.md - Read when you need:
  • Working audit examples
  • Sample issue/PR formats
  • Real-world usage patterns
  • Output format examples
reference.md - 当你需要以下信息时查阅：
  • 各阶段的详细执行步骤
  • Agent与阶段的映射关系
  • 代码库划分策略
  • Issue模板格式
examples.md - 当你需要以下信息时查阅：
  • 实际审计示例
  • 示例Issue/PR格式
  • 真实场景使用模式
  • 输出格式示例

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)
Phase 3.5 Validation Settings [NEW]:
  • 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
    : 标记超过该代码行数的模块（默认值：300）
阶段3.5验证设置 [新增]:
  • AUDIT_PR_SCAN_DAYS
    : 扫描近期PR的时间范围（默认值：30天）
  • AUDIT_AUTO_CLOSE_THRESHOLD
    : 自动关闭的置信度阈值（默认值：90%）
  • AUDIT_TAG_THRESHOLD
    : 添加标签的置信度阈值（默认值：70%）
  • AUDIT_ENABLE_VALIDATION
    : 启用阶段3.5（默认值：true）