15KB
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:
What might be wrong, missing, risky, or unproven about the approach we already have?
This skill implements the principle:
ATTEMPT FIRST
↓
AUDIT THE ATTEMPT
↓
REFINE
rather than:
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:
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:
CREATE INITIAL APPROACH
↓
THEN AUDIT IT
3. Core Principle
Do not ask:
"What would you do?"
first.
Ask:
"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:
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:
Add CSV import.
Proposed solution:
Replace the data layer with a new ORM,
introduce a queue,
and redesign the application architecture.
Mirror finding:
The proposed solution exceeds the scope required to solve the actual problem.
6. Hidden Assumptions
Identify assumptions the approach depends on.
Examples:
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:
Is this verified?
Can it be discovered?
What happens if it is false?
7. Missing Dependencies
Look for dependencies that were not considered.
Examples:
runtime version
database driver
external API
service account
filesystem permissions
network access
DNS
certificates
IIS configuration
scheduled task permissions
COM registration
package version
Ask:
What must already exist for this approach to work?
8. Failure Modes
Ask:
How can this fail?
Consider:
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:
IMPORT 20,000 RECORDS
12,000 SUCCEED
DATABASE CONNECTION FAILS
Ask:
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:
What happens if this runs twice?
A safe process should ideally make repeated execution predictable.
Check for:
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:
schema compatibility
type conversion
null handling
duplicate handling
encoding
transactions
referential integrity
row counts
partial writes
rounding
date/time handling
Ask:
How do we know the data after the operation is correct?
12. Security
Evaluate:
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:
existing code
existing APIs
database schema
runtime versions
operating systems
external consumers
file formats
deployment systems
older clients
Ask:
What existing behavior could this accidentally break?
14. Maintainability
Evaluate whether the solution creates unnecessary maintenance burden.
Look for:
duplicated logic
hidden behavior
magic values
unnecessary abstractions
unnecessary dependencies
hardcoded environment assumptions
complex configuration
poor observability
Ask:
Could another developer understand and safely modify this six months from now?
15. Complexity
Ask:
Is there a simpler approach that meets the same requirements?
Complexity is justified when it buys something concrete:
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:
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:
What must someone operate after this is deployed?
Consider:
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:
If this fails in production, how will anyone know?
Consider:
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:
Can we undo this?
Possible rollback mechanisms:
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:
Can we return to the old state?
Recovery asks:
Can we continue safely from a failed state?
Both may matter.
21. Edge Cases
Search for realistic edge cases.
Examples:
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:
What happens from the user's point of view?
Consider:
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:
rate limits
authentication expiration
API version changes
timeouts
retry behavior
duplicate requests
webhook ordering
eventual consistency
service outage
Ask:
What happens when the external system behaves badly?
24. Concurrency
When multiple processes or users may act simultaneously, check:
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:
deployment order
service availability
configuration compatibility
database compatibility
rollback compatibility
startup requirements
file locks
permissions
Ask:
Can old and new components temporarily coexist?
This matters for staged deployments.
26. Assumption Table
For significant work, an audit may use:
ASSUMPTION | VERIFIED? | FAILURE CONSEQUENCE | ACTION
Example:
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:
likely data loss
security vulnerability
missing critical dependency
irreversible operation with no required approval
IMPORTANT
Should be mitigated before completion.
Example:
no import row-count verification
MODERATE
Worth addressing if cost is reasonable.
Example:
limited logging makes future diagnosis harder
ACCEPTABLE TRADEOFF
A known weakness that is justified by requirements or scope.
Example:
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:
TOP 2–4 IMPORTANT CONCERNS
For each:
CONCERN
WHY IT MATTERS
QUESTION OR EVIDENCE NEEDED
Then allow refinement.
29. Autonomous Audit Mode
When the agent can inspect the project itself:
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:
Use DoCmd.TransferText to import CSV into Access.
Mirror Audit:
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:
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:
Copy new files into the application directory.
Audit identifies:
files may be locked
application may process requests during deployment
configuration may differ
copy could partially fail
rollback is undefined
Revised process:
preflight
backup
stop/drain application
deploy
restart
health check
rollback on failure
32. Audit Example — API Endpoint
Initial approach:
Create POST /api/orders.
Audit asks:
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:
long risk documents
dozens of hypothetical failures
architecture discussions
unnecessary user questions
Scale the audit to:
RISK
COMPLEXITY
REVERSIBILITY
34. Audit Depth
LOW-RISK
Check:
obvious assumptions
regression
verification
MEDIUM-RISK
Check:
assumptions
edge cases
dependencies
failure handling
maintainability
verification
HIGH-RISK
Check:
all relevant audit dimensions
rollback
recovery
security
data integrity
operational impact
red-team readiness
35. Output Contract
A Mirror Audit should produce:
CURRENT APPROACH
KEY ASSUMPTIONS
IMPORTANT FINDINGS
EVIDENCE OR QUESTIONS
MITIGATIONS
AUDIT RESULT
Possible results:
APPROVED
APPROVED WITH MITIGATIONS
REVISION REQUIRED
BLOCKED PENDING INFORMATION
36. Verification
The skill is successful when:
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:
BEFORE IMPLEMENTATION
Red Team occurs primarily:
AFTER IMPLEMENTATION / BEFORE ACCEPTANCE
Typical lifecycle:
INITIAL APPROACH
↓
MIRROR AUDIT
↓
IMPLEMENT
↓
VERIFY
↓
RED TEAM
They serve different purposes.
38. Relationship to Diagnostic Intake
Diagnostic Intake asks:
What information are we missing?
Mirror Audit asks:
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:
backup
schema compatibility
locking
transaction behavior
rollback
row-count validation
This may justify:
.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:
ALWAYS DISAGREE
Mirror auditing is not contrarianism.
Avoid:
REPLACE THE USER'S IDEA IMMEDIATELY
First inspect it.
Avoid:
LIST EVERY POSSIBLE FAILURE
Prioritize realistic risk.
Avoid:
TREAT SPECULATION AS FACT
Identify uncertainty.
Avoid:
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