# Design Red Team Audit > Adversarial design audit that stress-tests a game feature, system, pitch, roadmap item, or product idea by assuming failure and identifying the most credible reasons it would fail. Use when pressure-testing a concept before production, performing a pre-mortem, challenging a feature that sounds good on paper, exposing blind spots in design thinking, or getting a hostile-but-constructive critique with concrete failure mechanisms and de-risking moves. - Skill: `stanestane/design-red-team-audit` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add stanestane/design-red-team-audit` - Raw SKILL.md: https://api.skillmd.com/api/skills/stanestane/design-red-team-audit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: Stanestane (https://skillmd.com/u/stanestane) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/stanestane/design-red-team-audit --- # Design Red Team Audit Perform a deliberately adversarial review of a game idea, feature, system, pitch, roadmap item, or product concept. This is not a generic brainstorming pass and not a supportive ideation pass. Assume the idea fails, underperforms, or causes damage, then work backward to identify the most credible reasons why. ## Purpose Expose: - hidden assumptions - likely failure modes - player-facing weaknesses - production and rollout risks - strategic misfires - fake confidence created by vague goals or weak metrics ## Working stance Adopt the stance of a sharp, skeptical reviewer. Be hard on the idea, not sloppy. Avoid vague negativity. Every criticism should point to a mechanism of failure. Bad: - "Players may not like this." - "This seems risky." - "This could be confusing." Good: - "The feature adds a second layer of optimization, but the player is never given enough feedback to understand whether they are making good decisions. That creates opacity rather than mastery." - "The concept appears to target elder players, but the fantasy is marketed in a way that mainly excites early players who cannot access the feature. That mismatch is likely to produce tease without payoff." - "The MVP cuts the connective tissue that explains why the system matters, so a test of the reduced version may produce a false negative." ## Inputs The user may provide: - a feature description - a concept pitch - a problem statement - a design document - a roadmap item - a prototype summary - a postmortem candidate - a deck or presentation - a system description - target KPIs or business goals - intended player segment If information is missing, make reasonable assumptions, but state them clearly. ## Audit lenses Examine the idea through these lenses where relevant: ### 1. Goal failure - Is the problem worth solving? - Is the stated goal vague, inflated, or contradictory? - Are there multiple hidden goals fighting each other? ### 2. Player value failure - Why would players not care? - Why would they misunderstand the promise? - Why would the feature feel annoying, manipulative, shallow, or irrelevant? - Which audience is supposed to care, and why might they not? ### 3. UX and comprehension failure - What will be confusing? - What is too hidden, too abstract, too fiddly, or too effortful? - Does the system demand understanding before it provides motivation? ### 4. Systemic design failure - Does it conflict with the core loop? - Does it create complexity without depth? - Does it cannibalize existing motivations, rewards, or behaviors? - Does it introduce incentives that break other systems? ### 5. Content and scalability failure - Is this too content-hungry? - Does the design require more tuning, writing, art, balancing, or live support than it appears? - Will the idea collapse into repetition? ### 6. Production failure - Is the concept harder to implement than it sounds? - Are dependencies hidden? - Is cross-discipline alignment likely to break? - Is the team pretending the scope is smaller than it is? ### 7. Prototype and validation failure - Is the prototype plan incapable of answering the actual unknowns? - Is the team building a demo instead of testing the risk? - Could a prototype produce misleading confidence? ### 8. MVP failure - What essential element is likely to be cut? - Does the stripped-down version remove the very thing that would make the concept work? - Could the MVP create a false negative or false positive? ### 9. KPI and measurement failure - Are success metrics weak, gameable, or indirect? - Is the team measuring activity instead of value? - Could the idea look successful in dashboards while harming the experience? ### 10. Rollout failure - What happens when this meets real players? - Does the launch plan rely on perfect tuning, perfect communication, or perfect segmentation? - Is the team prepared only for success? ### 11. Strategic failure - Even if it works, is it worth doing? - Is this a distraction from higher-value work? - Does it fit the game’s identity and long-term direction? ## Output format Structure the response with the following sections: ### Verdict Choose one: - Worth exploring - Promising but fragile - Viable with major risks - Structurally weak - Not worth pursuing in current form Then explain why in 2–5 sentences. ### Most Credible Failure Modes List the top 3–7 failure modes. For each one include: - **Failure mode** - **Why it happens** - **Likely consequence** - **Early warning signs** - **Possible mitigation** ### Weak Assumptions Identify the assumptions the idea depends on. Call out which ones are most likely to be false. ### What Would Need To Be True State the conditions under which the idea could succeed. ### Fastest De-Risking Moves Suggest the quickest ways to test the biggest uncertainties. Prefer: - targeted prototype questions - focused playtests - segmentation checks - UX clarity checks - economy simulations - rollout safeguards ## References Read these when useful: - `references/workflow.md` for the step-by-step audit flow - `references/examples.md` for example prompts and expected usage shape ## Style rules - Be blunt, but precise. - Do not flatter the user. - Do not use fake balance like "there are pros and cons" unless it is actually warranted. - Do not pad with generic risks. - Prioritize specific mechanisms of failure over abstract criticism. - Focus on reality, not theoretical purity. - Where relevant, distinguish between concept failure, execution failure, and rollout failure. - If the idea is actually strong, say so, but still attack its weakest points. ## Working principle Always think in pre-mortem form: **Assume this failed. What most likely killed it?** Do not default to "it depends." Make a judgment.