Feature Audit

Run a deep readiness audit for one feature or product surface in any repository. Produce a comprehensive prioritized findings report with evidence and fix direction. Default posture for audit-only requests: stay read-only and do not edit files, reformat code, stage changes, create commits, or run destructive commands. If the user explicitly asks to find and fix bugs or remediate readiness issues in the same request, run a brief evidence-first audit pass, then switch to the normal implementation workflow for the confirmed target issues.

Core Rules

• Stay read-only for audit-only requests. If the user explicitly asks for fixes too, audit briefly first, identify the target issues with evidence, then proceed in the same turn using the normal implementation flow.
• Be repository-agnostic. Do not assume framework, language, test runner, database, route style, deployment platform, or file layout.
• Prefer repo evidence over memory. Discover conventions from files, scripts, configs, tests, docs, routes, and existing patterns.
• Use fast search first when available (rg, fd, code search); fall back to native file/search tools if needed.
• Keep scope feature-focused. Report global architecture issues only when they affect this feature's user journey, launch safety, maintainability, or operations.
• Aim for exhaustive coverage inside the chosen scope. Do not stop after finding the first few issues or a representative sample; continue tracing adjacent code paths, states, and tests until the feature surface has been checked as completely as practical for the turn.
• List every distinct, actionable finding you can substantiate within the scope, including lower-severity P3 findings when they represent real readiness, UX, maintainability, resilience, or test risk. Do not impose an arbitrary top-N cap unless the user explicitly asks for one.
• Use the specialist skills when the user's primary goal is narrower: security-audit for AppSec, test-gap-audit for coverage gaps, docs-sync-audit for documentation drift, repo-organization-audit for structure/reuse, feature-brainstorm for improvement ideas, and pr-branch-summary for PR communication.
• Separate confirmed bugs from inferred risks. Label product decisions, missing context, or assumptions clearly.
• Avoid duplicate findings. When one root cause creates several symptoms, report the root cause once and list the affected symptoms or surfaces in that finding.
• Treat UI/UX flow errors as audit findings when they can confuse users, block completion, hide recovery paths, cause wrong actions, or make important states hard to understand.
• Avoid noisy style opinions. Findings should be actionable risks, not generic cleanup wishes.