laravel-audit

Laravel Audit

Perform a deep, structured, evidence-based audit of the current Laravel application. Your goal is trustworthy findings backed by concrete evidence, not a long list of style nitpicks.

When to use this skill

Use this skill when asked to audit, review, assess, or evaluate an existing Laravel application for security, performance, architecture, database, testing, or Laravel conventions issues.

For a bounded data-structure / ownership / organizing-model pass (inventory every subsystem, fan out read-only workers, validate and rank P0–P3), use the laravel-audit-dsa skill instead.

Core principles

• Evidence-first. Every meaningful finding must cite concrete, verifiable project context: a file path, line/range, symbol, route, migration, query, configuration key, or dependency.
• Deterministic facts over guesses. Prefer programmatically gathered facts (Artisan/MCP context tools) over reading raw text and inferring.
• No invented behavior. Never claim a package or framework behaves a certain way without verifying it. When uncertain, say the evidence is incomplete.
• Confirmed vs. hypothesis. Label findings by confidence: confirmed only when evidence fully supports it; otherwise high, medium, or low.
• Trustworthiness over volume. A few high-quality findings beat dozens of speculative ones.
• Read-only. Never modify application code during the audit.
• No severity inflation. Style preferences are never high severity. "Package is old" is not a finding by itself.

Audit workflow

Phase A: Discover

Gather deterministic project facts first. When Artisan is available, start with php artisan auditor:status, php artisan auditor:context --list, and php artisan auditor:rules --applicable. Then run the Laravel Auditor context tools (MCP) or inspect:

• project_info: Laravel version, PHP version, database engine, ecosystem packages, architecture signals.
• routes: registered routes and their handlers.
• models: models, tables, fillable/guarded, casts, relationships.
• database_schema: tables, columns, types, indexes, and foreign keys (read-only).
• dependencies: composer packages and versions.
• configuration: config keys and safe values.
• policies_authorization: gates, policies, middleware.
• jobs_events_schedules: jobs, events/listeners, schedules.
• tests: test framework and coverage signals.
• migrations: migration files.
• subsystems: ownership-bounded inventory for a DSA-style coordinator audit.