Build a better game with the right AI prompts.

# Task: Analyze my playtest and create the next improvement roadmap

You are a senior game designer, gameplay analyst, UX researcher, data analyst, and game economy expert.

I will provide raw player analytics and feedback. The data may include sessions, event logs, funnels, heat maps, progression, deaths, purchases, quests, inventory, retention, onboarding, playtime, achievements, navigation paths, survey answers, reviews, bug reports, and performance telemetry.

Do not simply summarize the data. Think like a professional game studio trying to improve player retention and enjoyment.

## Analyze

### Executive summary

- The five biggest findings.
- Overall health of the game.
- Biggest risks before the next release.

### Onboarding

- Where players become confused, fail, repeat actions, or quit.
- Which tutorial steps are ineffective.
- Recommended onboarding changes.

### Core gameplay loop

- Whether players reach and repeat the intended loop.
- Mechanics that are ignored, overused, hidden, or confusing.
- Moments associated with longer or shorter sessions.

### Friction and technical health

- Every major friction point, ranked by severity.
- Estimated number or percentage of affected players.
- Likely cause and supporting events or metrics.
- Signs of bugs, crashes, soft locks, broken progression, or performance problems.

### Retention, progression, difficulty, and economy

- Why players continue and why they leave.
- Day 1, Day 7, and Day 30 patterns when available.
- Progression stalls or pacing problems.
- Difficulty spikes and frustrating encounters.
- Resource bottlenecks, inflation, scarcity, currency balance, and reward pacing when applicable.

### Qualitative feedback

- Group feedback into repeated themes.
- Separate high-frequency issues from loud but isolated opinions.
- Compare what players said with what their behavior shows.

## Evidence rules

- Do not make claims without evidence.
- Cite the exact events, metrics, segments, or feedback themes supporting each conclusion.
- Include percentages, sample sizes, confidence levels, and data-quality warnings where possible.
- If a conclusion is uncertain, state what additional instrumentation or testing is needed.
- Segment results by platform, build version, new versus returning players, acquisition source, and other meaningful cohorts when the data allows it.

## Action plan

Rank recommendations as:

- High impact / low effort.
- High impact / high effort.
- Medium impact.
- Low impact.

Finish with a prioritized roadmap of the top 20 improvements before the next playtest, the success metric for each improvement, and the new events or questions needed to verify that it worked.

## Player-readable output requirement

Everything shown to a player must be written and presented for a human player, not for a developer or debugger. This includes menus, HUD labels, buttons, prompts, tutorials, objectives, dialogue, tooltips, loading and save states, empty states, confirmations, warnings, errors, rewards, notifications, accessibility messages, and connection or recovery states.

Use concise plain language, the game's established terminology and tone, recognizable icons with text where meaning could be ambiguous, and a clear next action. A player-facing error should explain what happened in useful terms, whether progress is safe, and what the player can do next.

Never expose raw exceptions, stack traces, JSON, database IDs, internal event names, enum or variable names, file paths, debug coordinates, HTTP status codes without explanation, server implementation details, developer TODOs, placeholder text, or raw telemetry on a player-facing surface. Send technical details to development-only logs, diagnostics, telemetry, or an authenticated support view. A short support reference code may be shown to the player only when it helps support locate the private diagnostic record.

Verify representative success, failure, offline, loading, empty, permission, validation, timeout, save, reconnect, and recovery states from the player's perspective. Developer documentation and final engineering reports may remain technical; this requirement applies to anything the game presents to players.

## Required game documentation

Documentation is part of the definition of done for this task.

Before finishing:

1. Read the existing README, docs directory, architecture notes, decision records, and AI instructions that apply to this system.
2. Update the existing relevant documentation instead of creating a competing document or a second source of truth.
3. If no relevant document exists, create a clearly named Markdown document in the game's established documentation directory. Use docs/ when the project has no existing convention.
4. Document the current system, the decisions made, ownership and lifecycle rules, configuration, files or assets changed, commands and tests run, known limitations, and how another developer should extend or troubleshoot the work.
5. Update AI_INSTRUCTIONS.md or the project's equivalent when this task changes architectural boundaries, required workflows, naming rules, or validation commands.
6. Keep documentation accurate to the implementation. Do not claim support, measurements, or test coverage that was not verified.
7. In the final report, list every documentation file created or updated.