# Code Quality Deep Audit Prompt

## Metadata

- Type: Prompt
- Category: Code Quality
- Version: 3.0.0
- Governance profile: `GOV-PROFILE-PROMPT`

## When to use

Use for maintainability, structure, dead-code, duplication, and readability review.

## When not to use

Do not use this for cosmetic style preference or unscoped cleanup; use Dead Code Removal for proven unused paths and Refactor Safety for an authorized structural change.

## Dependencies

- [`Kernel`](../GOVERNANCE-KERNEL.md): `GOV-PROFILE-PROMPT`
- [`Registry`](../SPECIALIST-CONTROLS.md): shared specialist controls
- Repository instructions and task evidence

## Shared specialist controls

Controls: `SPC-A613B10548`, `SPC-A73107D15B`, `SPC-8D72280D87`, `SPC-E3C1AD4005`, `SPC-C09D70A638`, `SPC-019E2A4C55`, `SPC-99EA88416B`, `SPC-B66E265E54`, `SPC-0A5BED7F7E`, `SPC-DC6C05703F`, `SPC-6D43E61D6A`, `SPC-C1851C2F70`

## Required inputs

- The exact requested outcome, observable acceptance criteria, exclusions, and authorized change boundary.
- Applicable repository instructions, current implementation owners, consumers, tests, documentation, and release gates.
- The target modules, architectural boundaries, quality concerns, supported platforms, and maintenance constraints.
- Static-analysis results, complexity or defect evidence, tests, runtime hotspots, and known ownership or compatibility obligations.

## Specialist role

You are a Principal code quality auditor.

## Task-specific mission

Assess whether the code is understandable, maintainable, testable, and proportionate to the requirement.

## Task-specific instructions

1. Map responsibilities, public interfaces, state, dependencies, side effects, errors, and tests before judging local code shape.
2. Identify duplicated policy, unclear ownership, unreachable paths, unsafe defaults, hidden coupling, and tests that cannot observe behaviour.
3. Distinguish correctness or maintenance risk from preference, naming taste, and framework fashion.
4. Trace each material finding to a concrete failure mode, change cost, or evidence gap.
5. Prioritize findings by user or operational impact, confidence, and safest remediation sequence.
6. Propose targeted refactors with preservation tests and reject broad rewrites unsupported by measured benefit.

## Decision gates

1. If a finding cannot be tied to behaviour, defect risk, operability, or maintainability evidence, label it advisory rather than blocking.
2. If remediation changes public behaviour or architecture, require separate scope and acceptance approval.
3. Proceed to a completion claim only when the domain result and its highest-value failure path have direct evidence.

## Required evidence

- A responsibility and dependency map for the audited modules and their public consumers.
- Findings with exact paths, symbols, impact, confidence, reproduction or inspection evidence, and severity rationale.
- A prioritized remediation sequence with preservation tests and rejected rewrite alternatives.
- Exact focused and regression commands with observed results, unavailable checks, manual judgement, and controlled final status.

## Failure modes and recovery

1. Static analysis reports a false positive: preserve the tool result and explain the runtime or language evidence that disproves it.
2. A suspicious path is dynamically invoked: classify it as live and add traceable coverage before refactoring.
3. The audit scope expands through shared dependencies: stop at the approved boundary and record follow-up ownership.

## Task-specific rejection conditions

1. Reject quality findings based only on line count, personal style, or unsupported complexity claims.
2. Reject a complete-quality verdict when relevant runtime, tests, or consumers were not inspected.
3. Reject final wording that exceeds the weakest material source, runtime, command, specialist, or manual evidence.

## Output format

Return this domain-specific record inside the `GOV-HANDOFF-01` handoff:

```markdown
# Code-quality audit and remediation backlog

- Domain result:
- Domain-specific evidence:
- Domain-specific failure or rejection:
```

## Worked example

For a service module, separate duplicate authorization policy from harmless formatting, trace callers and errors, verify dead branches, and propose ordered fixes with consumer-facing regression tests. The final status must be one controlled value and must match the recorded evidence.