# Mirror Audit Version: 1.0.0 Status: ACTIVE ## Purpose Audit an existing idea, plan, design, implementation, or assumption before committing to it. The purpose is not to invent a different answer immediately. The purpose is to ask: ```text What might be wrong, missing, risky, or unproven about the approach we already have? ``` This skill implements the principle: ```text ATTEMPT FIRST ↓ AUDIT THE ATTEMPT ↓ REFINE ``` rather than: ```text ASK AI ↓ ACCEPT FIRST ANSWER ``` --- # 1. Trigger Conditions Use this skill when: * designing architecture * planning a migration * proposing a new subsystem * making a security-sensitive change * designing automation * changing deployment * performing a significant refactor * modifying a database schema * integrating an external service * making a consequential technical decision * evaluating a user-provided plan * evaluating an agent-generated plan * an initial solution feels plausible but has not been challenged Do not automatically use this skill for: * obvious typo fixes * trivial formatting * simple factual lookups * low-risk mechanical changes --- # 2. Required Input A Mirror Audit requires an existing attempt. The attempt may be: ```text USER PROPOSAL AGENT PROPOSAL IMPLEMENTATION PLAN ARCHITECTURE CODE CHANGE SCRIPT WORKFLOW DECISION ASSUMPTION SET ``` Do not perform a Mirror Audit against a blank slate. If no approach exists yet: ```text CREATE INITIAL APPROACH ↓ THEN AUDIT IT ``` --- # 3. Core Principle Do not ask: ```text "What would you do?" ``` first. Ask: ```text "Here is the current approach. What assumptions are hidden inside it? Where could it fail? What evidence is missing? What would make this unsafe or unreliable?" ``` This preserves the original reasoning and makes weaknesses visible. --- # 4. Audit Dimensions Evaluate the approach across the following dimensions. Not every task requires every dimension. Use only those relevant to the task. --- # 5. Objective Alignment Ask: ```text Does this approach actually solve the requested problem? Is it solving a larger problem than necessary? Is it optimizing something the user did not ask for? ``` Check for scope drift. Example: User asks: ```text Add CSV import. ``` Proposed solution: ```text Replace the data layer with a new ORM, introduce a queue, and redesign the application architecture. ``` Mirror finding: ```text The proposed solution exceeds the scope required to solve the actual problem. ``` --- # 6. Hidden Assumptions Identify assumptions the approach depends on. Examples: ```text the database is always available the file is always UTF-8 users always have administrator rights there is only one application server the API always returns JSON network latency is negligible the destination directory always exists the table schema never changes ``` For each important assumption ask: ```text Is this verified? Can it be discovered? What happens if it is false? ``` --- # 7. Missing Dependencies Look for dependencies that were not considered. Examples: ```text runtime version database driver external API service account filesystem permissions network access DNS certificates IIS configuration scheduled task permissions COM registration package version ``` Ask: ```text What must already exist for this approach to work? ``` --- # 8. Failure Modes Ask: ```text How can this fail? ``` Consider: ```text input failure dependency failure partial execution timeout network failure permission failure invalid data unexpected response disk failure concurrent execution process interruption service restart ``` Do not just consider the happy path. --- # 9. Partial Failure Partial failure is especially important. Example: ```text IMPORT 20,000 RECORDS 12,000 SUCCEED DATABASE CONNECTION FAILS ``` Ask: ```text What state is the system in now? Can execution safely resume? Will retry create duplicates? Is rollback possible? ``` --- # 10. Idempotency For automation and deployment tasks, ask: ```text What happens if this runs twice? ``` A safe process should ideally make repeated execution predictable. Check for: ```text duplicate records duplicate configuration duplicate users duplicate scheduled tasks double billing repeated API calls duplicate file processing ``` --- # 11. Data Integrity For data-related work, examine: ```text schema compatibility type conversion null handling duplicate handling encoding transactions referential integrity row counts partial writes rounding date/time handling ``` Ask: ```text How do we know the data after the operation is correct? ``` --- # 12. Security Evaluate: ```text authentication authorization least privilege credential handling secret exposure input validation command injection SQL injection path traversal network exposure logging of sensitive information ``` Do not assume existing trust boundaries are safe merely because they already exist. --- # 13. Compatibility Check compatibility with: ```text existing code existing APIs database schema runtime versions operating systems external consumers file formats deployment systems older clients ``` Ask: ```text What existing behavior could this accidentally break? ``` --- # 14. Maintainability Evaluate whether the solution creates unnecessary maintenance burden. Look for: ```text duplicated logic hidden behavior magic values unnecessary abstractions unnecessary dependencies hardcoded environment assumptions complex configuration poor observability ``` Ask: ```text Could another developer understand and safely modify this six months from now? ``` --- # 15. Complexity Ask: ```text Is there a simpler approach that meets the same requirements? ``` Complexity is justified when it buys something concrete: ```text reliability security performance scalability maintainability required flexibility ``` Complexity is not justified merely because the architecture is fashionable. --- # 16. Performance Check whether the approach makes unsupported performance assumptions. Consider: ```text data volume memory CPU network database round trips file size concurrency locking batch size startup cost ``` Do not optimize prematurely. Do identify obvious scalability failures. --- # 17. Operational Burden Ask: ```text What must someone operate after this is deployed? ``` Consider: ```text monitoring backup log review credential renewal certificate renewal scheduled maintenance manual cleanup service restart incident recovery ``` A technically elegant design may still be operationally poor. --- # 18. Observability Ask: ```text If this fails in production, how will anyone know? ``` Consider: ```text logging status output metrics exit codes error files audit records health checks alerts ``` Silent failure is a major risk in automation. --- # 19. Rollback For consequential changes ask: ```text Can we undo this? ``` Possible rollback mechanisms: ```text version control database backup transaction configuration backup previous deployment feature flag file backup restore script ``` If rollback is impossible, explicitly acknowledge the risk. --- # 20. Recovery Rollback and recovery are different. Rollback asks: ```text Can we return to the old state? ``` Recovery asks: ```text Can we continue safely from a failed state? ``` Both may matter. --- # 21. Edge Cases Search for realistic edge cases. Examples: ```text empty input one record very large input duplicate input missing field unexpected null invalid date special characters network interruption concurrent user expired credential locked file partial file ``` Do not invent endless theoretical edge cases. Focus on likely or high-impact cases. --- # 22. User Workflow For user-facing features, ask: ```text What happens from the user's point of view? ``` Consider: ```text confusing states poor error messages double submissions lost input unexpected navigation unclear success slow feedback ``` Technical correctness alone does not guarantee a usable workflow. --- # 23. External Integration Risks For external services, consider: ```text rate limits authentication expiration API version changes timeouts retry behavior duplicate requests webhook ordering eventual consistency service outage ``` Ask: ```text What happens when the external system behaves badly? ``` --- # 24. Concurrency When multiple processes or users may act simultaneously, check: ```text race conditions duplicate processing locking transaction isolation file access shared state last-write-wins behavior ``` Do not assume single-user execution unless verified. --- # 25. Deployment Risk For deployment changes, inspect: ```text deployment order service availability configuration compatibility database compatibility rollback compatibility startup requirements file locks permissions ``` Ask: ```text Can old and new components temporarily coexist? ``` This matters for staged deployments. --- # 26. Assumption Table For significant work, an audit may use: ```text ASSUMPTION | VERIFIED? | FAILURE CONSEQUENCE | ACTION ``` Example: ```text SQL Server reachable YES deployment cannot initialize otherwise no action Import files always contain headers NO first record could be treated as field names validate before import Process runs only once NO duplicate records possible add idempotency check ``` Use a table only when it improves clarity. --- # 27. Finding Severity Classify findings. ## BLOCKER The approach should not proceed until resolved. Examples: ```text likely data loss security vulnerability missing critical dependency irreversible operation with no required approval ``` --- ## IMPORTANT Should be mitigated before completion. Example: ```text no import row-count verification ``` --- ## MODERATE Worth addressing if cost is reasonable. Example: ```text limited logging makes future diagnosis harder ``` --- ## ACCEPTABLE TRADEOFF A known weakness that is justified by requirements or scope. Example: ```text single-server design is acceptable because deployment is permanently single-server ``` --- ## SPECULATIVE Possible but insufficient evidence or impact. Do not treat speculative concerns as blockers. --- # 28. Interactive Audit Mode When working interactively with the user, do not dump twenty criticisms at once. Prefer: ```text TOP 2–4 IMPORTANT CONCERNS ``` For each: ```text CONCERN WHY IT MATTERS QUESTION OR EVIDENCE NEEDED ``` Then allow refinement. --- # 29. Autonomous Audit Mode When the agent can inspect the project itself: ```text IDENTIFY CONCERN ↓ SEARCH FOR EVIDENCE ↓ RESOLVE IF POSSIBLE ↓ UPDATE APPROACH ``` Ask the user only when the critical issue cannot be resolved from available evidence. --- # 30. Audit Example — Database Import Initial approach: ```text Use DoCmd.TransferText to import CSV into Access. ``` Mirror Audit: ```text 1. How is schema mapping controlled? 2. What happens with malformed records? 3. How is import success measured? 4. Could retry create duplicate records? 5. What happens if the database is locked? 6. Is the CSV delimiter/encoding guaranteed? ``` Revised approach might add: ```text schema.ini staging table row-count validation error logging duplicate prevention ``` The Mirror Audit did not replace the original idea. It strengthened it. --- # 31. Audit Example — Deployment Script Initial approach: ```text Copy new files into the application directory. ``` Audit identifies: ```text files may be locked application may process requests during deployment configuration may differ copy could partially fail rollback is undefined ``` Revised process: ```text preflight backup stop/drain application deploy restart health check rollback on failure ``` --- # 32. Audit Example — API Endpoint Initial approach: ```text Create POST /api/orders. ``` Audit asks: ```text authentication? authorization? duplicate submission? input validation? transaction behavior? error response format? idempotency? logging? ``` The audit surfaces requirements before production defects do. --- # 33. Do Not Over-Audit Mirror auditing becomes harmful when every tiny decision produces: ```text long risk documents dozens of hypothetical failures architecture discussions unnecessary user questions ``` Scale the audit to: ```text RISK COMPLEXITY REVERSIBILITY ``` --- # 34. Audit Depth ## LOW-RISK Check: ```text obvious assumptions regression verification ``` --- ## MEDIUM-RISK Check: ```text assumptions edge cases dependencies failure handling maintainability verification ``` --- ## HIGH-RISK Check: ```text all relevant audit dimensions rollback recovery security data integrity operational impact red-team readiness ``` --- # 35. Output Contract A Mirror Audit should produce: ```text CURRENT APPROACH KEY ASSUMPTIONS IMPORTANT FINDINGS EVIDENCE OR QUESTIONS MITIGATIONS AUDIT RESULT ``` Possible results: ```text APPROVED APPROVED WITH MITIGATIONS REVISION REQUIRED BLOCKED PENDING INFORMATION ``` --- # 36. Verification The skill is successful when: ```text the approach survives meaningful challenge OR the approach changes because a real weakness was discovered ``` A Mirror Audit that merely produces criticism without affecting understanding is low value. --- # 37. Relationship to Red Team Mirror Audit occurs primarily: ```text BEFORE IMPLEMENTATION ``` Red Team occurs primarily: ```text AFTER IMPLEMENTATION / BEFORE ACCEPTANCE ``` Typical lifecycle: ```text INITIAL APPROACH ↓ MIRROR AUDIT ↓ IMPLEMENT ↓ VERIFY ↓ RED TEAM ``` They serve different purposes. --- # 38. Relationship to Diagnostic Intake Diagnostic Intake asks: ```text What information are we missing? ``` Mirror Audit asks: ```text What is wrong or unproven about our current thinking? ``` A Mirror Audit may discover missing information and invoke Diagnostic Intake. --- # 39. Relationship to Skill Extraction If repeated audits reveal the same domain-specific checklist, consider extracting it into a specialized skill. Example: Repeated database migration audits identify: ```text backup schema compatibility locking transaction behavior rollback row-count validation ``` This may justify: ```text .ai/skills/database-migration/SKILL.md ``` --- # 40. Self-Improvement Improve this skill when: * audits repeatedly miss the same failure * audits generate too many low-value objections * a better risk classification emerges * certain domains require specialized checks * the distinction between audit and red-team becomes unclear Prefer creating a specialized domain skill instead of endlessly expanding this general audit. --- # 41. Anti-Patterns Avoid: ```text ALWAYS DISAGREE ``` Mirror auditing is not contrarianism. Avoid: ```text REPLACE THE USER'S IDEA IMMEDIATELY ``` First inspect it. Avoid: ```text LIST EVERY POSSIBLE FAILURE ``` Prioritize realistic risk. Avoid: ```text TREAT SPECULATION AS FACT ``` Identify uncertainty. Avoid: ```text OVERENGINEER THE SOLUTION ``` Risk reduction should remain proportional to the task. --- # 42. Changelog ## 1.0.0 Initial active version. Introduced: * attempt-before-audit principle * assumption analysis * dependency analysis * failure-mode analysis * data-integrity review * security review * rollback/recovery checks * operational review * risk-based audit depth * finding severity * interactive and autonomous modes * distinction between Mirror Audit and Red Team