games-development-ai/AGENTS.md

AGENTS.md — 造梦AI Project · Agent Entry Point

This project is built with AI-driven development. Whether you are an AI agent or a human engineer, start every task here. This file is the single source of truth. It answers both "what this project is" (positioning / goals / directory) and "how to work in it" (what to read first, where to look, what rules to obey, how to feed learnings back). CLAUDE.md simply imports this file via @AGENTS.md; there is no separate project doc to keep in sync.

---

1. Project Positioning

造梦AI = an AI-driven, mass-market platform for game creation and monetization.

Core thesis:

• Zero-skill users can build a launchable, monetizable lightweight mini-game from a single sentence;
• Players discover and instantly play games in a short-video-style "game feed";
• The platform monetizes through three lines: ad revenue share / subscription membership / B-side custom work.

Differentiation moat = a "full closed loop" of generation + traffic + monetization. Most competitors stop at a "generation tool"; 造梦AI links "can build it → people play it → it earns money" into one chain. The real moat is not the generation engine (large models will catch up) but four layers: data, network effects, assets, and compliance.

---

2. Project Goals (MVP Phase)

MVP goal: deliver a full-chain closed loop that seed users can trial — create → generate → preview → publish → review → game feed → play → interact → ads → revenue → telemetry → recommendation optimization.

Key quantitative targets:

Metric	Target	Source
AI generation success rate	≥ 80% (based on 3–5 templates)	MVP execution spec
Game-feed first-screen load	P75 < 3s	MVP execution spec
Service availability	≥ 99.5%	Availability target
MVP infrastructure cost	< ¥5,000/month (investor edition ≈ ¥4,300/month, ~¥50k/year)	Investor edition
P0 product-feature coverage	55/55 P0 product features verifiable (Doc A product scope)	Three-Doc Suite Doc A/C

Two roadmaps coexist — do not mix them:

• Investor edition (HJ-ARCH-002): 5-person core team + ¥4,300/month infra + 11-week MVP, emphasizing capital efficiency and window-of-opportunity validation.
• MVP execution spec (HJ-MVP-SPEC-001): 10 people × 3 weeks (15 working days), emphasizing contract-first + five-station parallelism. Acceptance = the 55 P0 product features in Doc A; workload ≈ 137 technical items.
• Generation success rate: use the execution spec's ≥80% (the investor edition gives no direct number). Cite metrics against the corresponding document.

---

3. Project Directory

3.1 Three independent Git repos (business code repos; not yet contained in this repo)

Repo	Role	Tech stack
game-cloud	Backend (Yudao Cloud fork + 13 game business modules)	Java 17 + Spring Cloud Alibaba + MySQL + RocketMQ + Redis + Nacos + Dify + OpenGame
game-admin	Admin console frontend (operations / admins)	Vue3 + Element Plus (yudao-ui-admin-vue3 fork)
game-studio	Product frontend (creators + players)	Vue3 + Vant + in-house lightweight Canvas Runtime (<15KB, Tier1) + WanxiangGameSDK; 3D / standalone App are longer-term tiers (see .agents tech-decisions §1.1)

Note (naming distinction): Wave3 adds a studio business module inside the backend game-cloud (creation-flow orchestration, error-code segment 112 / Flyway V8). This is distinct from the product frontend repo game-studio in the table above — the former is a backend orchestration module, the latter is a Vue3 frontend repo. Do not confuse them.

3.2 Current repo (docs repo) directory structure

games-development-ai/
├── CLAUDE.md                  # Imports @AGENTS.md (redirects to the single entry below)
├── AGENTS.md                  # THIS FILE: project overview + how to work here (single source of truth)
├── docs/
│   ├── architecture/          # 6 architecture docs (investor / tech-decision / dev-team editions + Three-Doc Suite: product requirements · technical architecture & modules · requirement-module mapping)
│   ├── agent-specs/           # Execution-level specs (e.g. Prompt governance execution edition)
│   ├── superpowers/specs/     # Execution-level specs such as the MVP execution spec
│   └── memorys/               # Task history snapshots (date-archived, long-term retention)
├── docs-design/               # Product / visual design materials
└── .agents/                   # Agent capability hub (knowledge/rules/skills/workflows)

---

4. Required Reading Order Before Any Task

The 5 documents below form a complete picture of the project. On first onboarding or for architecture-level tasks, read them in order; for day-to-day development, prefer the distilled versions under .agents/knowledge/ and trace back to the original long docs only when you need detail.

Order	Document	Role
1	docs/architecture/系统概要设计-投资人版.md	Business positioning, capital efficiency, moat & window of opportunity
2	Three-Doc Suite: docs/architecture/产品需求清单.md (Doc A · product WHAT) / docs/architecture/技术架构与模块.md (Doc B · technical HOW · 13 modules) / docs/architecture/需求模块映射.md (Doc C · RTM)	Product requirements / technical modules / M:N mapping (replaces the old "business capability overview")
3	docs/architecture/系统概要设计-技术决策版.md	Full technical-decision picture (architecture baseline)
4	docs/architecture/系统概要设计-开发团队版.md	Day-to-day dev handbook（⚠️ target-state design: env/commands diverge from reality — follow .agents/rules + docs/mvp/MVP进度总账.md instead; see the in-doc status banner, 2026-06-10 audit）
5	docs/superpowers/specs/mvp-execution-spec-design.md	MVP execution spec: 10 people × 3 weeks, contract-first (acceptance = 55 P0 product features / workload ≈ 137 technical items, already synced in the body)

Tip: the original docs are long; reading them in full slows tasks down. The distilled versions live in .agents/knowledge/ and are the default day-to-day entry point.

---

5. .agents/ Directory Navigation

.agents/ is the project's "Agent capability hub", split into four categories. Maintenance rules are in .agents/README.md.

knowledge/ — distilled facts & blueprints, answers "what it is"

File	One-liner
.agents/knowledge/product-and-architecture.md	Product positioning, the 13 modules & their dependencies, three-repo/three-frontend architecture (distilled)
.agents/knowledge/tech-decisions.md	Tech stack & key selection rationale (Yudao/Dify/OpenGame/in-house Canvas+Cocos-MCP/Prompt governance, etc.)
.agents/knowledge/mvp-scope-and-milestones.md	The MVP's 55 P0 product-feature scope, milestones & acceptance metrics
.agents/knowledge/glossary.md	Glossary (game feed / GameConfig / Manifest / quality score, etc.)

rules/ — hard constraints, answers "how it must be"

File	One-liner
.agents/rules/engineering-conventions.md	Naming / layering / API paths / error codes / commits / PR conventions
.agents/rules/security-and-reliability.md	Security baseline, idempotency, timeout & retry, compliance & reliability constraints

skills/ — reusable playbooks, answers "how to do a class of thing"

File	One-liner
.agents/skills/add-business-module.md	Standard steps to add a game-module business module
.agents/skills/ai-generation-pipeline.md	AI generation pipeline (Dify + OpenGame + aigc shell) dev handbook
.agents/skills/runtime-and-multichannel.md	Runtime packaging, sandbox, SDK & multi-channel export handbook
.agents/skills/contract-first-development.md	Contract-first: aligning API/DB/SDK/event contracts & decoupling parallel work

workflows/ — meta-processes, answers "how to take on a task"

File	One-liner
.agents/workflows/ai-development-protocol.md	Full protocol: take task → analyze → review → execute → verify → distill
.agents/workflows/mvp-execution-orchestration.md	MVP 10-Agent × 3-week execution orchestration + 8 compounding-efficiency strategies

---

6. Working Protocol (Hard Constraints)

These are condensed clauses; the full process is in .agents/workflows/ai-development-protocol.md.

1. Read before acting: for any task with real complexity, first read .agents/knowledge/ and the relevant docs/, align on facts, then start.
2. Review first for complex / high-risk work: tasks that cross modules, change user-visible behavior, or touch external services / payments / data must go review edition → two review rounds → then execute; do not write code directly.
3. Evidence rule: distinguish "verified fact / inference / assumption". Without verification evidence, never claim "done / fixed / passing / no issues". Anything runnable (tests, build, lint, smoke) must be run.
4. Minimal change: only touch code directly related to the current requirement, reuse existing patterns, and do not casually refactor unrelated naming / directories / formatting.
5. Chinese comments: all code must carry complete Simplified Chinese comments; external interactions, core implementation, and error paths must have traceable logs.
6. Contract-first: for interface / data-structure changes, update the contract first (contracts/ and the -api packages), then implement, and notify stakeholders.
7. No orphan designs: any new feature, data structure, API, domain model, or workflow must come with its user-facing entry point, usage path, failure modes, and acceptance criteria — no API without an entry point, no isolated capability without a product flow, no stitched-together solution that merely adapts one spec to another.

---

7. Knowledge Accumulation Mechanism (Also a Hard Constraint)

The purpose of .agents/ is to let the team compound capability over long-term development, continuously raising the capability, accuracy, and stability of AI-driven development. Therefore:

• After every valuable task, you must write reusable output back into the matching .agents/ directory:
  • New facts / blueprint knowledge → knowledge/
  • New hard constraints / pitfall red-lines → rules/
  • New reusable operating playbooks → skills/
  • Process-level improvements → workflows/
• Check for duplicates before adding: prefer updating an existing file over creating a new one; fix or delete stale content immediately.
• When changing .agents/, also update the index and cross-links in .agents/README.md to keep navigation consistent.
• Keep all content in Simplified Chinese, single-topic, concise, and quickly searchable.

A task with no distillation is a "one-off consumption"; with distillation, the next similar task can build on existing results faster and more accurately.

---

8. Efficiency Principles (Compounding)

AI-driven development should get "faster as it goes" — distill every output into a reusable asset so efficiency compounds as work progresses. The 8 core strategies (see .agents/workflows/mvp-execution-orchestration.md):

1. Golden template first: perfect one module first, then clone its skeleton for the rest.
2. Contract-first: lock contracts (API/DB/SDK/event) before any parallel work.
3. Reuse over rebuild: before writing code, search skills/, knowledge/ and existing code to avoid reinventing wheels.
4. Verification gates up front: TDD + gates + pre-completion verification to catch errors early and prevent rework (rework is the #1 efficiency killer).
5. Parallel boundary = module boundary: zero shared state between agents, worktree isolation, interaction only through contracts.
6. .agents compounding distillation: write learnings back on every delivery (see §7).
7. Cache expensive steps: skip the LLM on a matching Prompt hash; cache builds / artifacts.
8. Reproducible orchestration: freeze fan-out + verify into Workflow scripts.

---

9. gstack Toolset (Global Skills)

gstack is a set of global slash-skills (browse / review / QA / deploy / docs, etc.), installed per developer machine under ~/.claude/skills/gstack. Once installed, everything is triggered through the single /gstack entry point from any project — sub-skills are not registered individually; the agent reads ~/.claude/skills/gstack/<name>/SKILL.md on demand and follows it.

Install (each member runs once):

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
  && cd ~/.claude/skills/gstack && ./setup