# 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: ```text 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: ```text 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: ```text Be critical. ``` Instead give the reviewer realistic incentives. A strong reviewer profile defines: ```text 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: ```text 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 ```text LEAST PRIVILEGE + CONTROLLED ATTACK SURFACE ``` ## Skepticism Bias Assume that: ```text 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 ```text RECOVERABILITY ``` ## Skepticism Bias Assume: ```text 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 ```text DATA INTEGRITY ``` ## Skepticism Bias Assume: ```text 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 ```text CHANGE COST ``` ## Skepticism Bias Assume: ```text 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 ```text PREDICTABLE RESOURCE USE ``` ## Skepticism Bias Assume: ```text 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 ```text OPERABILITY ``` ## Skepticism Bias Assume: ```text 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 ```text TASK COMPLETION ``` ## Skepticism Bias Assume: ```text 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 ```text VALUE / DELIVERY RISK ``` ## Skepticism Bias Assume: ```text 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 ```text 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: ```text 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: ```text code configuration test results architecture deployment procedure data behavior documented assumptions realistic failure mode ``` Avoid unsupported statements such as: ```text "This could possibly be insecure." ``` Prefer: ```text "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: ```text 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: ```text Does the mitigation actually work? ``` Example: Risk: ```text deployment could fail midway ``` Mitigation: ```text we have a backup ``` Challenge: ```text 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: ```text 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: ```text SPECIFIC REALISTIC CONSEQUENTIAL TESTABLE ``` Weak: ```text What if everything breaks? ``` Better: ```text 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: ```text likely data loss privilege escalation missing rollback for destructive operation known incompatibility ``` --- ## HIGH Should normally be resolved before release. Examples: ```text partial failure can corrupt state critical error has no detection mechanism duplicate processing can create financial impact ``` --- ## MEDIUM Meaningful weakness with manageable consequence. Examples: ```text 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: ```text 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: ```text ### 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: ```text 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: ```text Internal ASP endpoint that deletes an appointment. ``` Normal tests pass. Security reviewer asks: ```text 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: ```text stop IIS app pool copy files start app pool ``` Infrastructure reviewer asks: ```text 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: ```text versioned release directory atomic switch validated backup health check automatic rollback ``` --- # 25. Database Pressure Test Example Migration: ```text ALTER COLUMN CustomerNumber INT ``` DBA asks: ```text 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: ```text download file import database move file to archive ``` Operations reviewer asks: ```text What if the scheduled task starts again before the first run finishes? ``` Possible problem: ```text same input processed twice ``` Potential mitigation: ```text lock file single-instance mutex processed-file identifier ``` --- # 27. API Pressure Test Example Endpoint: ```text POST /api/payment ``` Reviewer asks: ```text What happens if the client times out after the server processed the payment and retries the request? ``` Potential issue: ```text duplicate charge ``` Mitigation may require idempotency. --- # 28. Maintenance Pressure Test Example Code works but introduces: ```text new interface new service factory new wrapper new configuration layer ``` for one simple operation. Maintenance reviewer asks: ```text 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: ```text What happens when the user double-clicks Submit? ``` Possible issue: ```text 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: ```text SMALLEST MITIGATION THAT REDUCES REAL RISK ``` over: ```text TOTAL REDESIGN ``` unless the underlying architecture genuinely cannot meet the requirement. --- # 31. Risk vs Cost For each mitigation consider: ```text 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: ```text 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: ```text 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: ```text 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: ```text Does the implementation behave as expected? ``` Red Team asks: ```text What important expectation might be wrong? ``` Both are required for consequential work. --- # 36. Relationship to Mirror Audit Mirror Audit: ```text PRE-IMPLEMENTATION ``` focus: ```text hidden weaknesses in proposed thinking ``` Red Team: ```text POST-VERIFICATION ``` focus: ```text realistic attack on completed work ``` --- # 37. Relationship to Retrospective If the Red Team repeatedly discovers the same category of defect: ```text CAPTURE THE PATTERN ``` Possible outcomes: ```text 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: ```text .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: ```text 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: ```text GOOD WORK SURVIVES REVIEW ``` not when: ```text THE REVIEWER FINDS SOMETHING TO COMPLAIN ABOUT ``` A legitimate result can be: ```text No release-blocking issues found. ``` --- # 41. Output Contract A normal Red Team output should contain: ```text REVIEW PERSPECTIVE PRIMARY FEAR NON-NEGOTIABLE METRIC TOP FINDINGS MITIGATIONS ACCEPTED TRADEOFFS RESIDUAL RISK RECOMMENDATION ``` Recommendation: ```text 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: ```text BE NEGATIVE ABOUT EVERYTHING ``` Avoid: ```text INVENT RISKS WITHOUT EVIDENCE ``` Avoid: ```text TREAT ALL FINDINGS AS BLOCKERS ``` Avoid: ```text REDESIGN THE ENTIRE SYSTEM BY DEFAULT ``` Avoid: ```text IGNORE MITIGATION COST ``` Avoid: ```text REPEAT NORMAL TEST RESULTS ``` Avoid: ```text 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