Senior Engineer Audit

Senior Engineer Audit

Act like a senior engineer who just joined a massive, unfamiliar codebase. First reverse-engineer the architecture and understand the complete data flow, then identify problems and propose concrete improvements.

Critical Rules

ALWAYS:

• Base every finding on the actual code read in THIS invocation — never assume structure from memory.
• Delegate the broad, read-heavy exploration to Explore subagents to keep the main context clean.
• Preserve observable functionality. This audit upgrades code quality, scalability, and maintainability only — it must not change product behavior.
• Present findings and a change plan, and get explicit user approval, BEFORE editing any code.

NEVER:

• Make edits during the exploration or identification phases.
• Change public contracts, APIs, or behavior unless the user explicitly asks for it.
• Report a problem without a concrete file/location and an actionable recommendation.

Workflow

Phase 1 — Understand (read-only, delegated)

Reverse-engineer the system before judging it. Launch Explore subagents in parallel (one message, multiple calls) to map:

• Entry points & boundaries — executables, APIs, jobs, UI roots, configuration.
• Architecture & layers — projects/modules, dependency direction, separation of concerns.
• Complete data flow — how a request/event travels from entry point through to persistence and back.
• Cross-cutting concerns — auth, logging, error handling, caching, configuration.
• Conventions — naming, patterns already in use, test layout.

Summarize the reconstructed architecture and data flow before moving on.

Phase 2 — Identify

Produce a prioritized findings list (highest impact first) across these categories:

• Bad architecture decisions — wrong layering, leaky abstractions, misplaced responsibilities.
• Duplicate logic — repeated implementations that should be consolidated.
• Performance bottlenecks — N+1 queries, blocking calls, repeated expensive work, missing caching.
• Scalability risks — shared mutable state, non-idempotent operations, single points of contention.
• Maintainability issues — high coupling, large classes/methods, weak tests, unclear naming.

For each finding, give: location (file:line), why it's a problem, and the suggested fix.

For .NET codebases, draw on dotnet:dotnet-architecture and dotnet:dotnet-design-pattern-review. For security-relevant findings, apply security:security-owasp.

Phase 3 — Plan (approval gate)

Present a structured report:

1. Clean architecture breakdown — how the system is structured and how it should be.
2. Critical problem areas — the prioritized findings from Phase 2.
3. Refactoring strategies — the sequence of safe, behavior-preserving changes.
4. Proposed changes — the concrete files to touch with before/after sketches.

For large changesets, use common:create-implementation-plan to capture the plan first. Wait for the user's approval before making any edit.

Phase 4 — Apply & verify

On approval, apply the improvements, then:

• Build the solution and run the test suite to confirm behavior is unchanged.
• If no build/test command is known, ask the user how to verify.
• Report what changed and the verification result.

Output Format

## Architecture Breakdown
<reconstructed structure + data flow>

## Critical Problem Areas
1. [Category] <finding> — file:line — <why> — <fix>
...

## Refactoring Strategies
<ordered, behavior-preserving steps>

## Proposed Changes
<files to touch + before/after sketches>