---
name: application-robustness-auditor
description: Audit web, mobile, API-backed, or server-rendered application repositories from the standpoint of product purpose, workflows, functionality, domain invariants, architecture boundaries, and robustness-oriented design patterns. Use when the user asks to review what an app does, make it more robust, identify better design patterns, create a product/domain capability map, plan architecture refactors, assess risks around critical workflows, or design an agent/MCP that performs this kind of app audit across repositories.
---

# Application Robustness Auditor

## Core Workflow

Start by reading the repository's own context before forming recommendations:

1. Find product notes: `README*`, `AGENTS.md`, docs, entrypoint/routing surfaces, schema or persistence files, package manifests, CI configuration, and test directories.
2. Map what the app is for: target users, product promise, primary workflows, and non-goals.
3. Inventory capabilities: routes/screens, domain models, services, jobs, integrations, imports/exports, admin flows, and tests.
4. Name invariants: ownership, permissions, state transitions, calculation rules, idempotency rules, and compatibility guarantees.
5. Review boundaries: controllers/handlers, models/entities, services/actions, queries/read models, presenters/view models, client-side code, and background work.
6. Rank robustness risks by blast radius and domain sensitivity.
7. Recommend design patterns that fit the existing codebase instead of imposing a generic architecture.
8. Produce a phased roadmap of small, verifiable changes.

For a full checklist and pattern menu, read `references/audit-rubric.md`.

## Technology-Neutral Discovery

Do not assume Rails-style folders or any single framework's conventions. First identify the stack, then translate the workflow into that stack's native surfaces:

- Entrypoints and interaction surfaces: route files, controllers, Razor Pages, endpoint maps, URLconf, routers, handlers, serverless functions, jobs, CLIs, scheduled tasks, webhooks, mobile app lifecycles, deep links, widgets, and extensions.
- Persistence and schema: ORM models/entities, DbContext or session configuration, migrations, SQL schema files, serializers, repositories, query builders, external contract files, local caches, token stores, and object storage.
- Composition and policy: dependency injection/service registration, middleware, filters/interceptors, authentication setup, authorization policies/scopes, validators, background worker configuration, app manifests, entitlements, and release/build variants.
- UI and interaction: templates/views/components, htmx/controllers/client scripts, SwiftUI/Compose views, view models, frontend state, generated assets, and browser-only or device-only calculations.
- Tests and verification: unit, integration, browser/E2E, mobile UI tests, architecture tests, fixtures/factories, CI jobs, security scans, generated-asset checks, and release/build verification.

Use the application's own names for layers in the final artifact. For example, say "MVC controller plus service", "Django view plus service", "Phoenix context", "Laravel action", "Express router plus module", "SwiftUI view model plus repository", or "Compose screen plus repository" when that is what the codebase uses.

## Operating Rules

- Treat this as an audit and planning workflow unless the user explicitly asks for code changes.
- Preserve the app's current purpose and local conventions; do not recommend rewrites just to match a pattern.
- Separate observations from recommendations.
- Tie recommendations to concrete files, workflows, or risks.
- Mark financial, authentication, authorization, privacy, medical, legal, and data recovery workflows as high-risk by default.
- Prefer incremental refactors with characterization tests before changing critical behavior.
- For UI robustness, evaluate whether state, validation, and calculations live on the correct side of the client/server boundary.
- For mobile or offline-capable clients, inspect auth-scoped cache boundaries, sign-out cleanup, secret storage, deep links, widgets/extensions, generated API contracts, cancellation, and background sync ownership.
- For admin, compliance, or evidence-heavy workflows, inspect audit taxonomy, retention/minimization, neutral public failure messages for bearer links, and database/object-storage lifecycle consistency.
- Call out cross-client contract drift when web, mobile, widget, API, or generated operation definitions duplicate the same workflow.
- When creating reusable agent or MCP recommendations, start from the audit workflow's stable inputs and outputs.
- When a framework distributes behavior across configuration, dependency injection, middleware, attributes/annotations, conventions, or generated files, inspect those surfaces before judging boundaries.

## Output Shape

Default to a concise artifact with these sections:

- Product purpose
- Core workflows and capabilities
- Domain model map
- Critical invariants
- Architecture boundary assessment
- Robustness risk register
- Recommended design patterns
- Phased roadmap
- Suggested test coverage

If the user asks to persist the work, write a markdown file in the repo's existing docs/planning location. If there is no obvious location, use `docs/`.

## Agent Or MCP Guidance

When asked to turn this workflow into reusable automation:

- Recommend an agent/skill first when the task is mostly judgment, reading, synthesis, and roadmap creation.
- Recommend an MCP server when multiple clients need reusable prompts, resources, and deterministic scanner tools.
- For MCP, model repository summaries as resources, audit steps as prompts, and repeatable extraction as tools.
- Keep mutation tools opt-in; the first version should mostly read, summarize, and write audit artifacts.