Build a better game with the right AI prompts.

# Task: Refine this game asset in Blender using our visual rubric

Use Blender through the available desktop integration or MCP.

## Inputs

- Asset to improve: [NAME AND LOCATION]
- Target asset type: [CHARACTER / CREATURE / PROP / ENVIRONMENT / ANIMATION]
- Established visual rubric: [PASTE OR LINK]
- Art implementation guide: [PASTE OR LINK]
- Reference images: [ATTACH OR LINK]
- Current target score: [FOR EXAMPLE, 9 OUT OF 10]

## Instructions

1. Inspect the current Blender scene, asset structure, modifiers, materials, rig, scale, and naming before editing.
2. Grade the current asset against every applicable rubric category and explain the biggest gaps.
3. Improve the asset toward the target score, prioritizing silhouette, concept clarity, form hierarchy, proportions, focal read, material separation, grounding, and believable articulation.
4. If the asset moves, audit its gameplay movement requirements before editing. Identify required locomotion, traversal, combat, interaction, facial, mechanical, vehicle, secondary, procedural, VFX, or physics-driven animation and the important gameplay-distance camera angles.
5. Build or refine the applicable rig, controls, deformation, contact points, loops, starts, stops, turns, transitions, anticipation, follow-through, weight, facial shapes, mechanical articulation, and secondary motion. Avoid foot sliding, frozen accessories, floating contact, abrupt blends, and motion that does not match gameplay speed or scale.
6. Keep authored animation separate from runtime systems that belong in the engine. Prepare clear requirements for blend trees or state machines, root motion or in-place use, IK, event markers, VFX, audio, camera, and physics synchronization without pretending Blender alone completes those systems.
7. Keep the asset consistent with the established game-wide visual language. Do not introduce detail that creates noise or breaks the style.
8. Work non-destructively where practical and preserve useful source geometry.
9. Review the asset from gameplay distance and important camera angles, not only from a close-up beauty view.
10. Re-grade the result against the same rubric and continue refining the weakest categories.
11. Keep the finished work in Blender for review. Do not integrate it into the game yet.

## Final report

Provide before-and-after rubric scores, the movement and animation requirements covered, rigs and clips created or changed, engine-side work still required, unresolved risks, performance considerations, and the exact next review step.

## 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.