Skip to main content
　

​
1. Include relevant meta information

The same prompt can yield different results depending on the engine, physics / rendering setup, and MCP configuration. Include the following whenever possible:
  • Engine and language used (e.g. Phaser 3 + TypeScript)
  • Physics / rendering setup (e.g. Arcade Physics / Matter / custom, etc.)
  • MCP / resources used (e.g. Maple MCP)
  • LLM model used
　

​
2. Separate shared context from the Actual Prompt

Split prompts into a common context (the always-assumed environment) and the actual prompt (this specific task) for cleaner sharing. Common context example 
- Phaser 3 + TypeScript-based 2D action game
- Physics: Arcade Physics
- MapleStory assets are searched via the Maple MCP
- Preserve the existing code structure and file names
- Must build without errors
Actual prompt example 
Implement horizontal movement and jumping for the player.
- Arrow keys to move, Space to jump
- Can only jump while on the ground
- Distinct idle / run / jump animation states
- Preserve the existing Scene structure
Completion criteria: no build errors, no terrain clipping, immediate input response
　

​
3. Define Constraints and Limitations Clearly

Prompts don’t always reproduce perfectly, so don’t hide the limits you know about — share them. Through others’ feedback the prompt can improve over time.
  • Tested environment and scope
  • Areas that are still unstable
  • Parts that may vary by model / version
  • Values that still need tuning
　

​
4. Specify completion criteria and success metrics

What “works well” means differs from person to person. State the completion criteria so others can verify the result by the same standard.
  • No build errors
  • A specific behavior reproduces M out of N times (e.g. 4 out of 5)
  • Maintains 60 FPS
  • A specific UI shows up at the correct position and size
　

​
5. Clarify the expected output format and role assignment

Note what role you assigned to the LLM and in what format you received the result.
  • Role examples: “senior Phaser game developer”, “code reviewer”, “QA engineer”
  • Format examples: code blocks only, step-by-step explanation, JSON, diff / patch, etc.
　

​
6. Provide any relevant files, code, or reference context

Write down what context you passed to the model along with the prompt. The same prompt can produce completely different results when the context is different.
  • Attached files / paths
  • Code scope referenced (only a specific Scene file / the entire src / a specific function, etc.)
  • MCP resource names and search keywords used
　

​
7. Share follow-up prompts and the iterative workflow

It’s rare for a single prompt to finish the job. Share the follow-up prompts used to refine the result.
  • What was wrong with the first result
  • Which follow-up prompt fixed what, and how
  • Example: “terrain clipping bug → fixed with ‘reduce the player collider height by 8px and retry’”
　

​
8. Include examples of outcomes

If possible, share the prompt’s execution result — text, screenshots, videos, etc. 　 Run through this checklist before sharing:
  • Remove sensitive info such as API keys, internal paths, account credentials
  • If MapleStory IP or external assets were used, note the license scope (e.g. internal demo only)
  • Make sure internal code / document links are not exposed externally
　

​
10. Share your prompts

Share your prompts and iterative workflows at forum.msu.io.