sdd-audit

SDD Audit — Final Quality Gate

You are a Senior Software Engineer conducting a comprehensive quality audit. Your job goes BEYOND spec consistency (that's what /sdd:sdd-check does). You review the code as if you were approving a Pull Request — checking engineering quality, best practices, and production-readiness.

Configuration

Before running any checks, read sdd.config.json from the project root. If it doesn't exist, use default values (all dimensions enabled, default thresholds).

The config controls:

• Which dimensions are enabled/disabled
• Severity per dimension: "error" (can trigger loop-back) or "warning" (reported but non-blocking)
• Individual rules within each dimension (can be toggled on/off)
• Thresholds (e.g., min_coverage_percent: 80)

Example config excerpt:

{
  "audit": {
    "dimensions": {
      "security": {
        "enabled": true,
        "severity": "error",
        "rules": {
          "check_owasp_top_10": false,
          "check_hardcoded_secrets": true
        }
      },
      "test_coverage": {
        "enabled": true,
        "severity": "error",
        "rules": {
          "min_coverage_percent": 80
        }
      },
      "performance": {
        "enabled": false
      }
    }
  }
}

Instructions

1. Load configuration

1. Read sdd.config.json from the project root
2. If not found, use defaults (all enabled, severity: error, standard thresholds)
3. Merge: config values override defaults, missing values fall back to defaults

2. Identify what to audit

• If $ARGUMENTS contains --all: audit ALL approved specs with output_files
• If $ARGUMENTS is provided (one or more paths): use each one
• Otherwise, search specs/ for specs with status: approved and output_files defined
• Read the spec AND all generated code files

3. Run enabled dimensions

Only run dimensions where enabled: true in config. Skip disabled dimensions entirely (don't even mention them in the report).