taptap-maker-builder (TapTap Maker Project Scaffolding)
What This Skill Does
- Get an Agent Up to Speed: Explain TapTap Maker, how to choose between two creation modes, the five elements of a first requirement, credits and themes, and how to read Benchmarks, all in one screen. When specific questions arise, read only the single matching reference.
- From Brief to Publication: Use confirmation-gated stages 0–6 to gradually build a design brief into a playable project. Each stage has deliverables, templates, and acceptance checklists; the agent only proceeds after user confirmation.
This skill is responsible only for how to proceed. It does not launch real projects for the user. All changes happen within the user's own Maker project and only after confirmation.
When to Use
- The user asks about TapTap Maker / Maker / UrhoX / Maker Lab / Leaderboard / Credits / UI Themes / how to connect local MCP.
- The user uploads or pastes a game design brief or requirements document and asks to "build this," "make it playable," or "do it according to this."
- The user wants to write Maker dialogue requirements, estimate credit consumption, check publishing materials, or troubleshoot previews or on-device issues.
Not applicable: Unity / Unreal or other engines; pure art outsourcing; general programming unrelated to Maker.
Three Hard Rules (Stop If Broken)
- Online documentation takes precedence: Products iterate quickly. Always start by reading https://maker.taptap.cn/llms.txt, then read the corresponding documentation as needed. This skill's knowledge has a compilation date; if it conflicts with online docs, follow the online docs. Never invent features, parameters, model names, prices, or limits not present in the docs.
- Confirmation gates are not skippable: At the end of each stage 0–5, deliver a "stage report" and wait for explicit user confirmation ("confirm," "continue," "OK") before proceeding. If the user hasn't confirmed, stop and ask.
- No unauthorized spending or file manipulation: Do not call credit-consuming generation tools, automatically switch models or channels, or move, delete, or overwrite user files unless explicitly requested by the user in the conversation. Any new systems beyond the scope of the design brief require prior consent.
60-Second Product Overview
| Dimension | Key Points |
|---|---|
| Product | TapTap Maker: An AI-powered game creation tool for enthusiasts. Uses natural language for design, code implementation, asset creation, preview iteration, and publication preparation. |
| Underlying Tech | UrhoX engine + Lua scripting; includes three built-in UI themes: Astroon, BrawlForge, PixelForge. |
| Slogan | Conversation is creation, completion is publication. |
| Two Creation Modes | Browser workspace (project, dialog, preview, publish on one page); Local development mode (Maker MCP connects to a local directory, supports Codex, Cursor, Claude Code). |
| Authoritative Entry Point | https://maker.taptap.cn/llms.txt (master index of all documentation, highest timeliness). |
Five Essential Elements for a First Requirement (must be answerable before writing requirements): Gameplay Objective / Presentation Form / Control Method / Core Loop / Scope for First Round.
Credits: Five types: Universal, Basic, Activity, Project, Paid. Default consumption order: Activity → Project → Basic. Whether Universal and Paid can be used depends on the current model, project scope, and server-side validation. Operations on the publish panel do not consume creation credits.
Benchmark: Real UrhoX headless execution with deterministic assertions. The main leaderboard metric is L2 pass rate. Each score includes a 95% confidence interval; each rank has a possible range. When ranges overlap, it means "the current sample size cannot distinguish between them."
References Navigation (Read Only One as Needed)
| Question or Scenario | Which Reference | What It Contains |
|---|---|---|
| What is the product? How to choose between two modes? How to install MCP? What does the directory look like? How to add collaborators? | ./references/01-product-overview.md | Positioning and capability boundaries, mode comparison, installation commands, directory structure, local runtime, collaboration rules. |
| How are credits deducted? What consumes credits? What to do if the result is unknown? How to save credits? | ./references/02-credits-and-cost.md | Five credit types, consumption order, cost control, uncertain ledger. |
| Which theme to choose? How to specify a theme? Asset specifications and limits? How to write AI image generation prompts? | ./references/03-ui-themes-and-assets.md | Applicable genres and visual rules for three themes, five asset type limits, DWP, asset directory conventions. |
| How to read the leaderboard? What is L2? How to interpret confidence intervals and rank ranges? | ./references/04-benchmark-guide.md | Three-level scoring, dimension meanings and common misinterpretations, statistical method, limitations. |
| How to parse a design brief? What to do if the five elements are missing? How to write the first requirement? | ./references/05-brief-parsing-and-first-prompt.md | Extraction table, limits and phrasing for follow-up questions, key points for the confirmation document, good/bad examples for first requirements. |
| How to iterate? How to write the four-part format? How to do preview acceptance (5 items), pre-publication checks (6 items), data checks (6 items)? | ./references/06-iteration-and-acceptance.md | Four-part format writing, official progression order, acceptance checklists, common failure modes. |
| What materials are needed for publication? How to use the QR code test version? How to open the sharing page? | ./references/07-publish-checklist.md | Material list and specifications, publication process, test version synchronization, post-publication actions. |
| How to handle credentials? Which actions are irreversible? Atomic writes? Asset copyright? Collaboration security? | ./references/08-safety-and-credentials.md | Timeliness, cost, credentials, irreversible actions, atomic writes, scope and copyright. |
Rule: Read only the reference related to the current question at a time. Answer after reading; do not fill in details from memory.
Stage Overview (0–6)
| Stage | Goal | Deliverable | Confirmation Gate | Tools / Templates |
|---|---|---|---|---|
| 0 Connection | Determine creation mode; for local mode, confirm MCP, project binding, and existing directory. | Connection confirmation + directory check results. | User confirms method and environment. | ./scripts/check_project_layout.py |
| 1 Parsing | Structurally extract the five elements; ask ≤4 follow-up questions at once for missing items. | Design brief understanding confirmation document. | User confirms all five items before requirements are written. | ./assets/brief-confirmation-template.md, ./scripts/check_brief.py |
| 2 First Requirement | Rewrite into the first requirement conforming to official standards; build only the minimal playable core loop. | First requirement text + theme and visual direction. | User confirms requirements and theme direction. | ./assets/first-prompt-template.md |
| 3 Iteration | Minimal playable → fix blocking issues → pacing, numbers, feel → assets, audio, tutorials, materials. | Four-part requirements per round + verification results. | User accepts result before moving to the next round. | ./assets/feedback-four-part-template.md, ./references/06-iteration-and-acceptance.md |
| 4 Preview & On-Device | 5-item acceptance check + on-device test QR code. | Acceptance record, issue list. | All 5 items pass before moving to publication. | ./references/06-iteration-and-acceptance.md, ./references/07-publish-checklist.md |
| 5 Publication | Verify materials one by one; publish after version consistency is confirmed. | Publishing material checklist. | User confirms materials and version are consistent. | ./scripts/check_publish_materials.py, ./assets/stage-report-template.md |
| 6 Ongoing | Cost and security guard; active in every stage. | Risk alerts and confirmation records. | High-risk actions confirmed each time. | ./references/02-credits-and-cost.md, ./references/08-safety-and-credentials.md |
Progression discipline: At the end of each stage, first provide a stage report → wait for explicit user confirmation → then enter the next stage.
Stage 0: Connection
Ask three things at once, not bit by bit:
- Use browser workspace or local MCP (local directory + Codex / Cursor / Claude Code)?
- Existing project or new one? Project name, game direction?
- Any existing assets or code directories to reuse?
| Scenario | Recommendation |
|---|---|
| First time, want to see results fastest. | Browser workspace |
| Already have local code or assets, want to use Codex / Cursor / Claude Code workflow. | Local MCP |
| Want to use Git, collaborate with others, do local checks. | Local MCP |
| Just want to quickly try on phone. | Browser workspace + share QR code |
Local mode commands (run in target directory; init will pull the project to the current directory; first confirm the directory is empty or user agrees to merge):
npx -y @taptap/maker install --ide codex,cursor,claude # Writes MCP config for three tools
npx -y @taptap/maker init # Login + select/create project + bind directory + pull
- After initialization, typical directory includes: assets/ (with image, sprites, audio, video) and scripts/; actual structure varies by project.
- Before starting, run
python ./scripts/check_project_layout.py <project root>and read the existing directory and its documentation to avoid overwriting resources in use. - Updating components: "Update the current project's Maker MCP and AI DevKit, then tell me the actual version used"; for production use
pd/stable, for experimentation usernd/latest. - Store credentials only in trusted local environments; do not write into project files or Git.
Confirmation gate 0 wording: "I plan to connect using X method, the project directory is Y, the existing structure is Z, and I will not overwrite A. Confirm to proceed to design brief parsing."
Stage 1: Design Brief Parsing
Process:
- Read the entire design brief, directly extract the five-element table; do not restate entire paragraphs.
- For each item, mark: Present (with source in brief) / Inferred (requires confirmation) / Missing.
- For missing and critical ambiguities, ask all at once, ≤4 questions, each with 2–3 candidate answers to reduce answering effort.
- Produce a "Design Brief Understanding Confirmation Document" that must include: "What I understand / What I am unsure of / What I recommend cutting from the first round."
- Only after user confirmation proceed to stage 2.
Hard rules:
- Critical settings (theme, protagonist, core win/loss condition, controls, target platform, visual direction) must not be guessed; ask if missing, or explicitly mark as "TBD" and give a default suggestion.
- Late-game systems in the brief (leveling, shops, multiplayer, leaderboards, multiple chapters) go into "future versions," not the first round.
- The confirmation document must explicitly state "What is not included in the first round."
Optionally check the five elements with a script (JSON structure is in the script header comments):
python ./scripts/check_brief.py brief.json
Stage 2: First Requirement Generation
Order for writing the first requirement: One-sentence positioning → Five elements → Controls & Win/Loss → Interface list → Out of scope.
- One requirement solves one result; build only the minimal playable core loop first.
- Clearly stating "What is NOT done in this round" converges scope better than listing a pile of features.
- Also confirm: UI theme (Astroon / BrawlForge / PixelForge), screen orientation (landscape / portrait), perspective (2D / 3D), art style.
- Template: ./assets/first-prompt-template.md; good/bad examples in ./references/05-brief-parsing-and-first-prompt.md.
Theme & direction confirmation wording: "I recommend theme A (reason: fits the genre), portrait 2D; if you prefer B, I will change it to B. Confirm and I will send the first requirement."
Stage 3: Iterative Building
Official progression order (do not skip):
- Minimal playable version (can start, can play, can end, can restart)
- Fix blocking flow issues (freezes, buttons unclickable, state not resetting)
- Tune pacing, numbers, feel
- Add assets, audio, tutorials, publishing materials
Each round's requirements use the four-part format: Goal / Current Status / Constraints / Acceptance (template ./assets/feedback-four-part-template.md).
- Focus on one result at a time; do not put "Add audio + change numbers + switch theme" into the same requirement.
- "Constraints" list things to preserve (existing controls, confirmed theme, modules not to refactor).
- "Acceptance" should be written as observable phenomena, not "make it more fun."
- Require the AI to build, check errors, and explain verification results; for complex changes, first ask for a brief plan.
- Keep the same goal in the same dialog; start a new dialog for a new direction.
When reporting a bug, provide all five things: device / page, steps to reproduce, actual behavior, expected behavior, reproducibility (attach screenshots or recordings if possible).
Stage 4: Preview and On-Device Testing
Five acceptance items (official checklist, record conclusions for each):
- Does it start normally?
- Does operation meet expectations (including touch areas, buttons clickable)?
- Are success/failure/restart cycles complete?
- Is the image clear on the target device (font size, contrast, safe zone)?
- Are there any blocking flow issues?
Devices and sharing:
- Desktop preview can switch between PC / phone / tablet and resolutions (including the iPhone 17 Dynamic Island mask, which blocks clicks in that area).
- On-device: Use the preview toolbar "Share" → link / QR code; before creating a sharing page, select a publishing vendor that has completed developer certification in the publish panel.
- On-device test QR code: "Scan to test on phone" → "Update test version" → scan; after changing code / orientation / configuration / assets, you must re-update, otherwise you will scan the old version.
- For orientation switches, the AI must simultaneously update the UI layout and the project orientation configuration; after the change, rebuild and verify buttons, text, and touch in preview/on-device.
If acceptance fails, go back to stage 3 and write a four-part requirement; do not skip to publication.
Stage 5: Publication Preparation
Material list (verify each item):
- Game icon
- At least 3 game screenshots
- Promotional image, horizontal cover, vertical cover
- For portrait games, additionally a square promotional image
- Game name
- Game description ≥10 characters
- "Developer's Note" ≥10 characters
- On-device test video required for the first official release
Process: Generate materials (consumes credits, requires explicit user consent) → Verify in publish panel → Update test version and scan to re-verify → Official release.
- If there are multiple publishing vendors, select the vendor first; the publish button becomes available only after the material generation phase is complete.
- Operations on the publish panel themselves do not consume creation credits.
- Pre-publication health checks: see ./references/06-iteration-and-acceptance.md (6 items before publication, 6 data checks).
- Verification command:
python ./scripts/check_publish_materials.py materials.json --root <project root>
Stage 6 (Ongoing): Cost and Security Guard
To be executed in every stage:
- Credits: Do not call credit-consuming generation tools unless explicitly requested by the user in the conversation; before high-consumption actions, explain "what it will cost, roughly how much, and whether there is a cheaper way"; do not automatically switch models or channels.
- Uncertain results, do not resubmit automatically: If you submit and do not get a clear result, mark it as uncertain and first check the status. If resubmission is truly necessary, get user confirmation and explain that charges may have already been incurred.
- Credentials: Do not echo, do not write in proxy, do not write into project files or Git; only grant authorization to trusted clients.
- Irreversible actions: Deleting or overwriting assets, replacing models, switching channels, clearing configuration, official release—stop first, explain the consequences and how to undo, and get an explicit "yes" before proceeding.
- Scope: Build only within the scope of the design brief; new systems or gameplay require prior consent; do not move or delete user files without authorization.
- Atomic writes (when scripts or tools write files): Use temporary files + rename; do not overwrite existing values with empty values; for corrupted files, save the corrupted data separately for analysis.
Details: ./references/08-safety-and-credentials.md and ./references/02-credits-and-cost.md.
Stage Report
Before entering the next stage, output four blocks using ./assets/stage-report-template.md: What was done in this stage / Deliverables / Verification results / Next steps and points needing your confirmation. The report must end with a single, answerable confirmation request.
Maintenance and Timeliness
- This skill's knowledge compilation date: 2026-11-03. Products iterate quickly. For any features, parameters, models, prices, or limits, always defer to the online documentation.
- Conflict resolution: Online documentation > this skill. If a discrepancy is found, follow the online documentation and explain the difference in the response.
- Refresh method: Start by reading https://maker.taptap.cn/llms.txt to find the corresponding page; when the original text is needed, fetch the plain text of the relevant .md URL.
- Prohibition on fabrication: For any features, parameters, model names, prices, or limits not present in the documentation, always answer "The documentation does not mention this; I will look it up or please refer to the page."
Example Prompts
- "I want to make a portrait 2D avoidance game. First, help me see how to proceed." → Stage 0 / 1.
- "This is my design brief (attachment). Help me build it." → Start from stage 0, confirm stage by stage.
- "How are Maker credits deducted? How many to generate one image?" → Read only references/02, answer directly, do not enter the workflow.
- "On the leaderboard, is the difference between a 60% and 63% L2 pass rate significant?" → Read only references/04, explain confidence intervals and rank ranges.
- "Make the start screen using the Astroon theme, don't touch the gameplay." → Stage 3, write a four-part requirement.