17KB
Red Team Review
Version: 1.0.0 Status: ACTIVE
Purpose
Pressure-test a completed plan, implementation, design, deployment, migration, or important decision against realistic stakeholder concerns.
The Red Team should answer:
What could still fail even though normal implementation and verification passed?
This is not a substitute for testing.
It is a second layer of scrutiny.
1. Trigger Conditions
Use this skill for:
- security-sensitive work
- deployments
- infrastructure changes
- database migrations
- data transformations
- authentication or authorization
- financial logic
- external integrations
- destructive operations
- public APIs
- architecture decisions
- major refactors
- operational procedures
- release readiness
- high-impact business workflows
Do not automatically use it for:
- typos
- trivial formatting
- obvious low-risk fixes
- routine documentation edits
Scale the review to the real risk.
2. Position in the Workflow
Typical lifecycle:
INITIAL APPROACH
↓
MIRROR AUDIT
↓
PLAN
↓
IMPLEMENT
↓
VERIFY
↓
RED TEAM
↓
REFINE
↓
ACCEPT
Mirror Audit challenges the idea before implementation.
Red Team challenges the result after normal verification.
3. Core Rule
Do not tell the reviewer merely:
Be critical.
Instead give the reviewer realistic incentives.
A strong reviewer profile defines:
PRIMARY FEAR
NON-NEGOTIABLE METRIC
SKEPTICISM BIAS
This makes the challenge realistic rather than performatively negative.
4. Reviewer Selection
Choose the reviewer perspective that best matches the actual risk.
Possible reviewers include:
Security Reviewer
Infrastructure Engineer
Database Administrator
Maintenance Developer
Performance Engineer
Operations Engineer
End User
Support Engineer
Project Manager
Compliance Reviewer
Finance Reviewer
External Customer
Use one primary perspective unless the task genuinely needs several.
5. Security Reviewer
Primary Fear
Unauthorized access, data exposure, or loss of trust boundary integrity.
Non-Negotiable Metric
LEAST PRIVILEGE
+
CONTROLLED ATTACK SURFACE
Skepticism Bias
Assume that:
inputs are hostile
credentials eventually leak
trusted boundaries eventually fail
users discover unexpected paths through the system
Review:
- authentication
- authorization
- secrets
- logging
- injection
- file access
- network exposure
- privileged execution
- data disclosure
- insecure defaults
6. Infrastructure Engineer
Primary Fear
Production outage or unrecoverable deployment.
Non-Negotiable Metric
RECOVERABILITY
Skepticism Bias
Assume:
dependencies fail
files become locked
services restart unexpectedly
deployment occurs under pressure
the original developer is unavailable
Review:
- deployment order
- service dependencies
- rollback
- backups
- startup requirements
- health checks
- logs
- permissions
- restart behavior
- partial deployment
7. Database Administrator
Primary Fear
Corruption, data loss, locking, or unrecoverable migration.
Non-Negotiable Metric
DATA INTEGRITY
Skepticism Bias
Assume:
production data is stranger than test data
large tables behave differently
transactions fail at inconvenient times
concurrency exists
Review:
- backups
- transactions
- type conversion
- constraints
- locking
- indexes
- migration order
- rollback
- row counts
- null handling
- duplicates
- referential integrity
8. Maintenance Developer
Primary Fear
Hidden complexity that becomes expensive later.
Non-Negotiable Metric
CHANGE COST
Skepticism Bias
Assume:
the original author will not be available
requirements will change
bugs will occur six months later
Review:
- readability
- coupling
- duplication
- abstraction
- naming
- hidden side effects
- configuration
- testability
- documentation
- dependency burden
9. Performance Engineer
Primary Fear
A design works in development but collapses under real load.
Non-Negotiable Metric
PREDICTABLE RESOURCE USE
Skepticism Bias
Assume:
data volume grows
latency matters
concurrent users increase
slow dependencies become slower
Review:
- database round trips
- memory
- CPU
- network
- caching
- file size
- query design
- batch size
- contention
- startup cost
Do not demand optimization without evidence.
10. Operations Engineer
Primary Fear
The system fails silently or requires tribal knowledge to recover.
Non-Negotiable Metric
OPERABILITY
Skepticism Bias
Assume:
incidents happen outside business hours
the operator did not write the system
documentation is incomplete
Review:
- logging
- status reporting
- exit codes
- monitoring
- health checks
- runbooks
- restart procedure
- failure messages
- cleanup
- recovery
11. End User
Primary Fear
The system technically works but is confusing, slow, or unreliable.
Non-Negotiable Metric
TASK COMPLETION
Skepticism Bias
Assume:
users make mistakes
users double-click
users misunderstand labels
users abandon confusing workflows
Review:
- clarity
- validation
- error messages
- confirmation
- double submission
- navigation
- response time
- recoverability
- preservation of entered data
12. Project Manager
Primary Fear
Implementation complexity exceeds business value or schedule.
Non-Negotiable Metric
VALUE / DELIVERY RISK
Skepticism Bias
Assume:
scope expands
dependencies slip
hidden work appears late
Review:
- scope
- dependencies
- unnecessary complexity
- release risk
- testing effort
- operational burden
- maintainability
- unresolved decisions
13. Compliance Reviewer
Primary Fear
A technical solution violates policy, regulation, contractual requirement, or auditability expectations.
Non-Negotiable Metric
TRACEABLE COMPLIANCE
Review:
- access controls
- audit trail
- data handling
- retention
- authorization
- approval process
- evidence
- logging
- change tracking
Only apply specific legal or regulatory requirements when actually established.
Do not invent compliance obligations.
14. Define the Review Target
Before reviewing, identify:
WHAT WAS CHANGED?
WHY?
WHAT WAS VERIFIED?
WHAT RISKS WERE ALREADY ACCEPTED?
WHAT MUST NOT CHANGE?
The reviewer should critique the actual result, not an imaginary system.
15. Evidence First
A Red Team finding should be grounded in:
code
configuration
test results
architecture
deployment procedure
data behavior
documented assumptions
realistic failure mode
Avoid unsupported statements such as:
"This could possibly be insecure."
Prefer:
"The endpoint checks authentication but not whether
the authenticated user owns the requested record."
Specific evidence creates actionable review.
16. Identify Weak Assumptions
Find the 1–3 assumptions whose failure would create the greatest consequence.
Examples:
deployment assumes file copy cannot partially fail
API assumes duplicate POST requests never occur
migration assumes every existing value converts cleanly
automation assumes only one instance runs
Focus on leverage.
17. Challenge Existing Mitigations
Do not stop at identifying a mitigation.
Ask:
Does the mitigation actually work?
Example:
Risk:
deployment could fail midway
Mitigation:
we have a backup
Challenge:
Has restore been tested?
Does the backup contain configuration?
How long would recovery take?
Can the old application run against the new database schema?
Mitigations should withstand scrutiny.
18. Pressure-Test Loop
A strong adversarial review may use:
PROPOSAL
↓
CHALLENGE
↓
DEFENSE / EVIDENCE
↓
ESCALATION
↓
RECONCILIATION
The goal is not to “win” the argument.
The goal is to determine whether the design survives realistic pressure.
19. Challenge Quality
A useful challenge is:
SPECIFIC
REALISTIC
CONSEQUENTIAL
TESTABLE
Weak:
What if everything breaks?
Better:
If the database migration succeeds but the application
deployment fails, can the previous application version
still operate against the new schema?
20. Finding Severity
Use these severity levels.
BLOCKER
Do not proceed until resolved.
Examples:
likely data loss
privilege escalation
missing rollback for destructive operation
known incompatibility
HIGH
Should normally be resolved before release.
Examples:
partial failure can corrupt state
critical error has no detection mechanism
duplicate processing can create financial impact
MEDIUM
Meaningful weakness with manageable consequence.
Examples:
poor observability
avoidable maintenance burden
limited operational documentation
LOW
Minor improvement.
Do not allow LOW findings to dominate the review.
ACCEPTED TRADEOFF
Known limitation accepted because:
risk is low
scope does not justify mitigation
requirement intentionally chooses it
Document why.
SPECULATIVE
Insufficient evidence or very low likelihood/impact.
Speculation should not block release.
21. Finding Format
Use:
### Finding
Severity:
[BLOCKER / HIGH / MEDIUM / LOW]
Evidence:
[Specific observation]
Failure Mode:
[What could happen]
Consequence:
[Why it matters]
Recommended Mitigation:
[Smallest useful mitigation]
Residual Risk:
[What remains afterward]
For small reviews, compress this.
22. Limit Findings
Default to:
1–5 HIGH-VALUE FINDINGS
Do not create a long list merely to appear thorough.
If there are twenty legitimate problems, say so.
Otherwise prioritize.
23. Security Pressure Test Example
System:
Internal ASP endpoint that deletes an appointment.
Normal tests pass.
Security reviewer asks:
Does authenticated mean authorized?
Can User A delete User B's appointment
by changing the ID in the URL?
This reveals an authorization defect normal functional testing may miss.
24. Deployment Pressure Test Example
Deployment:
stop IIS app pool
copy files
start app pool
Infrastructure reviewer asks:
What if copying fails after half the files are replaced?
Is the application directory now mixed-version?
What exact action restores a consistent release?
Possible mitigation:
versioned release directory
atomic switch
validated backup
health check
automatic rollback
25. Database Pressure Test Example
Migration:
ALTER COLUMN CustomerNumber INT
DBA asks:
Have all existing values been verified as numeric?
What happens to blank values?
How long will the conversion lock the table?
Can the application run during the migration?
These are concrete production concerns.
26. Automation Pressure Test Example
Scheduled PowerShell import:
download file
import database
move file to archive
Operations reviewer asks:
What if the scheduled task starts again before the first run finishes?
Possible problem:
same input processed twice
Potential mitigation:
lock file
single-instance mutex
processed-file identifier
27. API Pressure Test Example
Endpoint:
POST /api/payment
Reviewer asks:
What happens if the client times out after the server
processed the payment and retries the request?
Potential issue:
duplicate charge
Mitigation may require idempotency.
28. Maintenance Pressure Test Example
Code works but introduces:
new interface
new service factory
new wrapper
new configuration layer
for one simple operation.
Maintenance reviewer asks:
What real repeated problem are these abstractions solving?
If there is none, simplify.
29. User Pressure Test Example
Booking form successfully saves appointments.
End-user reviewer asks:
What happens when the user double-clicks Submit?
Possible issue:
duplicate appointment
This is both user experience and data-integrity risk.
30. Challenge Without Redesigning
Do not automatically replace a working solution with a more sophisticated architecture.
The reviewer should prefer:
SMALLEST MITIGATION THAT REDUCES REAL RISK
over:
TOTAL REDESIGN
unless the underlying architecture genuinely cannot meet the requirement.
31. Risk vs Cost
For each mitigation consider:
RISK REDUCTION
IMPLEMENTATION COST
MAINTENANCE COST
NEW FAILURE MODES
A mitigation can make a system worse if it creates more complexity than the original risk warrants.
32. Residual Risk
No system reaches zero risk.
After mitigation, state what remains.
Example:
Database backups reduce recovery risk,
but restore time remains approximately dependent
on database size and infrastructure availability.
Residual risk helps make tradeoffs explicit.
33. Stop Conditions
Stop the Red Team review when:
highest-impact assumptions have been challenged
blockers are identified
important mitigations are known
additional objections are low-value repetition
Do not continue indefinitely.
34. Reconciliation
After challenge, summarize:
WHAT SURVIVED
WHAT MUST CHANGE
WHAT RISK IS ACCEPTED
WHAT REMAINS UNKNOWN
A useful Red Team ends with clarity.
35. Relationship to Verification
Normal verification asks:
Does the implementation behave as expected?
Red Team asks:
What important expectation might be wrong?
Both are required for consequential work.
36. Relationship to Mirror Audit
Mirror Audit:
PRE-IMPLEMENTATION
focus:
hidden weaknesses in proposed thinking
Red Team:
POST-VERIFICATION
focus:
realistic attack on completed work
37. Relationship to Retrospective
If the Red Team repeatedly discovers the same category of defect:
CAPTURE THE PATTERN
Possible outcomes:
new verification rule
new specialized skill
existing skill update
project documentation
automated test
This is how adversarial review feeds self-improvement.
38. Specialized Red Teams
Repeated domain-specific use may justify specialized skills.
Examples:
.ai/skills/security-red-team/
.ai/skills/database-migration-review/
.ai/skills/deployment-readiness/
.ai/skills/api-abuse-review/
Do not create them until repeated real work justifies the specialization.
39. False Positives
A Red Team that always finds serious issues becomes untrustworthy.
For each finding ask:
Is there evidence?
Is the scenario realistic?
Would the consequence matter?
Does the mitigation justify its cost?
Remove weak findings.
40. Do Not Reward Contrarianism
The reviewer is successful when:
GOOD WORK SURVIVES REVIEW
not when:
THE REVIEWER FINDS SOMETHING TO COMPLAIN ABOUT
A legitimate result can be:
No release-blocking issues found.
41. Output Contract
A normal Red Team output should contain:
REVIEW PERSPECTIVE
PRIMARY FEAR
NON-NEGOTIABLE METRIC
TOP FINDINGS
MITIGATIONS
ACCEPTED TRADEOFFS
RESIDUAL RISK
RECOMMENDATION
Recommendation:
PASS
PASS WITH MITIGATIONS
REVISION REQUIRED
BLOCK
42. Self-Improvement
Improve this skill when:
- reviews consistently generate weak objections
- important failure types repeatedly escape review
- a better persona framework emerges
- severity classification is inconsistent
- reviews become too lengthy
- repeated domain-specific findings justify specialized review skills
Do not endlessly grow the general skill.
Move specialized knowledge into specialized skills.
43. Anti-Patterns
Avoid:
BE NEGATIVE ABOUT EVERYTHING
Avoid:
INVENT RISKS WITHOUT EVIDENCE
Avoid:
TREAT ALL FINDINGS AS BLOCKERS
Avoid:
REDESIGN THE ENTIRE SYSTEM BY DEFAULT
Avoid:
IGNORE MITIGATION COST
Avoid:
REPEAT NORMAL TEST RESULTS
Avoid:
END WITHOUT A RECOMMENDATION
44. Changelog
1.0.0
Initial active version.
Introduced:
- incentive-driven reviewer personas
- primary fear
- non-negotiable metric
- skepticism bias
- pressure-test loop
- evidence-based findings
- severity classification
- mitigation challenges
- residual risk
- reconciliation
- false-positive control