Skill: stanestane/game-design-pitch-deck-audit (version 1.0.0)

--- name: game-design-pitch-deck-audit description: Audit a video game pitch deck, publisher deck, funding deck, or investor-facing game presentation for clarity, structure, persuasiveness, visual readability, business-case completeness, and publisher-fit. Use when reviewing a pitch deck before sending to publishers, polishing a deck for meetings, checking whether the deck answers the essential questions about who, what, why, when, budget, and opportunity, or evaluating whether a deck sells both the game and the collaboration case rather than just dumping information. --- # Game Design Pitch Deck Audit Audit a game pitch deck as both a persuasion tool and a business-case artifact. Use this skill to evaluate whether a game pitch deck is clear, compelling, visually readable, and properly structured for publisher or funding conversations. Focus on whether the deck makes a strong case for the team, the game, the opportunity, the ask, and the path to completion. ## Core principle A good pitch deck does not merely describe a game. It builds confidence in the team, sells the dream of the project, proves the work, frames the opportunity, and makes a realistic ask. ## What to produce Generate: 1. **Deck overview** - what the deck is trying to do and for whom 2. **Structure audit** - whether the core sections are present and in a persuasive order 3. **Content audit** - strengths, gaps, and weak claims 4. **Visual/readability audit** - whether the deck is easy to follow without live narration 5. **Publisher-fit audit** - whether the deck answers the practical questions a publisher or funder will ask 6. **Recommendations** - what to cut, strengthen, reorder, or add ## Audit lenses Audit the deck through these lenses: - **Who** - who is making the game and why they are credible - **Why / opportunity** - why this project exists and why now - **What** - what the game is, what makes it stand out, and what the final vision is - **Proof** - what already exists that proves the team can deliver - **Business case** - comparables, target audience, monetization, market logic, and opportunity - **Ask** - budget, timeline, platforms, scope, and what support is being requested - **Readability** - whether the deck works when sent ahead of a meeting without narration ## Process ### 1. Define the deck context Clarify: - who the audience is: publisher, investor, platform, partner, grant body - whether this deck is meant to be sent async, presented live, or both - what stage the project is in: concept, prototype, vertical slice, production - whether the deck is accompanied by a build, trailer, GDD, or other materials ### 2. Audit the high-level structure Check whether the deck answers the essential questions: - What are you making? - Why are you making it? - Who is making it? - Where do you want to go? - What do you need to get there? - When will you get there? Also check whether the deck roughly covers: - team / studio credibility - artistic why - business why / opportunity - dream of the game - proof of the game - work / systems / core loop - market or comparables - timeline and budget - summary and contact info ### 3. Audit the team and credibility section Ask: - does the deck establish why this team should be trusted? - does it show relevant shipped work, experience, or platform familiarity? - is it concise, or does it waste time on irrelevant biography? - does it explain who will actually make the game if funded? ### 4. Audit the game pitch itself Check for three distinct functions: - **Dream** - does the deck sell the final vision of the game? - **Proof** - does it show prototype, vertical slice, or other non-speculative evidence? - **Work** - does it explain how the game operates, what the core loop is, and why the game is compelling? Ask: - is the hook clear quickly? - are the unique selling points obvious? - does the deck lean into strengths strongly enough? - does it show what is familiar and then what is unique? - does it explain why the game matters, not just what it contains? ### 5. Audit the business case Ask: - does the deck explain the opportunity and target audience? - are comparables believable and useful rather than vanity references? - is monetization or business model clearly stated if relevant? - is the market framing grounded, or just wishful genre enthusiasm? - does the deck sell the collaboration case, not just the product fantasy? ### 6. Audit the ask Check whether the deck makes a realistic ask around: - budget - timeline - platforms - release window - build status - support needed Ask: - is the budget plausible and safely scoped? - are the timeline ratios believable? - is the ask too low in a way that signals inexperience? - does the deck separate development needs from broader publishing or marketing assumptions when relevant? ### 7. Audit deck usability and readability Ask: - does the deck work without live commentary? - is the text readable and concise? - are the slides overcrowded? - does imagery carry the message effectively? - are GIFs, videos, mockups, or key art used meaningfully? - is the style aligned with the tone of the game? - does the deck avoid pointless bullet sludge? ### 8. Audit submission readiness If the deck is intended for publishers, check whether the package likely includes or references: - a playable build - control notes if needed - skippable cutscenes or checkpoints if relevant to the build - budget in practical terms - timeline to release - supplementary materials that help a stranger understand the project quickly ### 9. Diagnose common failure patterns Common pitch-deck failure patterns: - **Identity fog** - unclear what the game actually is - **Dream without proof** - strong fantasy, weak evidence - **Proof without dream** - lots of prototype facts, no compelling vision - **Bio bloat** - too much team info with too little relevance - **Market handwaving** - vague business claims with weak comparables - **Budget naivety** - undercooked ask or unrealistic timeline - **Narration dependency** - deck only works if someone explains everything live - **Template autopilot** - all the right sections exist, but the deck says nothing memorable - **Visual sludge** - unreadable, cramped, or aesthetically disconnected from the game ### 10. Convert findings into recommendations For each issue, specify: - **Problem** - **Why it hurts the pitch** - **Fix direction** - **Priority** - critical / important / polish ## Response structure ### Deck Overview - ... ### Structure Audit - Present: ... - Missing or weak: ... ### Content Audit - Team credibility: ... - Game hook: ... - Proof: ... - Business case: ... - Ask: ... ### Visual / Readability Audit - ... ### Publisher-Fit Audit - ... ### Failure Patterns - ... ### Recommendations 1. ... 2. ... 3. ... ## Fast mode - What is the game? - Why this team? - Why this opportunity? - What proof already exists? - What is the ask? - Would this deck still make sense if read without you in the room? ## References Read these when useful: - `references/pitch-deck-notes.md` for distilled deck structure and slide expectations from the templates - `references/raw-fury-notes.md` for the Raw Fury-specific pitch expectations ## Working principle A good pitch deck should make a stranger understand the game, trust the team, believe the opportunity, and feel the ask is grounded.

path: references/pitch-deck-notes.md
content: # Pitch Deck Notes

This reference distills the two PowerPoint templates found in Downloads.

## Core structural patterns

### Rami Ismail / Levelling the Playing Field template
Strongest recurring structure:
- Who
- Saw which opportunity
- To make what
- How can you benefit
- What do we need

Additional framing from the deck:
- establish team trust and relevant experience early
- explain the artistic why and business why separately
- sell the dream of the game, then prove it, then explain the work
- include believable comparables rather than giant vanity comps
- end with the ask: timeline, budget, and contact details
- deck should work even when sent ahead of a live meeting

Notable guidance from the template:
- keep to roughly 10-14 slides if possible, around 15 minutes spoken
- pretty matters; style the deck to match the game
- use mockups or target visuals to sell the final dream, not weak prototype scraps
- focus on what and why; explain how only when transformational
- numbers are boring unless remarkable
- publisher is buying into the business case and collaboration, not just the game fantasy

### GYLD template
Strongest recurring structure:
- Cover / title / logo
- Elevator pitch
- USP overview
- Gameplay overview / core loop
- Monetization / business model
- Art style or moodboard
- Roadmap and budget
- Team / studio
- Additional materials / build / links
- Thank you / contact

Notable guidance from the template:
- show core pillars and USPs clearly
- gameplay overview should visualize the loop
- use moving images where useful
- keep text readable and not cramped
- limit colour palette and preserve contrast
- include build links and extra material if available
- explain development status, target release, similar titles, modes, engine, platforms, and budget

## Shared takeaways

The two templates agree on the essentials:
- make the hook clear quickly
- show what makes the game stand out
- establish team credibility
- explain the path to completion
- make the budget and timeline legible
- keep the deck readable without narration
- use visuals that do real persuasive work, not decorative clutter

## Slide-level checks worth auditing

- cover/title slide clarity
- team slide relevance
- elevator pitch sharpness
- USP slide memorability
- core loop explanation
- prototype / vertical slice evidence
- market / comparable logic
- roadmap realism
- budget plausibility
- summary / contact readiness

path: references/raw-fury-notes.md
content: # Raw Fury Pitch Notes

This reference distills the document "How to Pitch to Raw Fury".

## Raw Fury wants these basics

### 1. A playable PC build
The build should communicate the essence of the game in a way outsiders can understand.

Helpful build features:
- skippable intro or cutscenes
- checkpoints if the build is longer than around 10 minutes
- English subtitles if spoken language is not English
- control scheme notes if needed

The main principle:
- send the build you are most proud of
- assume they may only play it once

### 2. A development budget
Raw Fury wants development cost for one PC build in USD.

Important framing:
- focus on development costs only
- no need to estimate marketing, PR, ports, events, etc.
- simplest framing: monthly burn rate multiplied by months left in development
- more detail is fine if it clarifies the process

### 3. A deck
Raw Fury's six essential questions:
- What are you doing?
- Why are you doing it?
- Who are you?
- Where do you want to go?
- What do you need to get there?
- When will you be there?

If those six are answered, the high-level deck is already useful.

### 4. Extra supporting material
Helpful additions:
- GIFs
- video playthroughs
- GDD
- concept art
- story documents
- anything that helps an outsider understand where the project is headed

## Audit implications

When auditing a publisher-facing deck, especially for Raw Fury-style expectations, check whether:
- the deck answers the six essential questions clearly
- the build is referenced or included
- the budget focuses on development costs in a practical way
- the materials help a stranger understand the project fast
- the deck avoids overcomplicating the pitch before the basics are covered

## Practical reading of publisher-fit

A good deck is not merely beautiful.
It should make a scouting person quickly understand:
- what the game is
- what makes it exciting
- why this team can make it
- what stage it is at
- what money and time are needed
- whether there is enough substance to keep the conversation going

Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)