When the user is at the "I want to make a game like this" stage, turn it into
what to build + how to build it in MSW
a guided session produces a
GDD/roadmap
, then the skill
guides the phased build
— detailed Phase plans, progress tracking, and plan revisions —
until each milestone's build is ready to enter full implementation
. Someone who doesn't know game design can just follow the questions; for those who do, it documents decisions fast.
Core principles (why it works this way)
Catalog grounding
MSW is 2D · mLua (a Lua-extension scripting language) · cross-platform, so the space of "what you can build" is bounded. Map a vague idea onto the real genres/map-types/mechanics in
references/genre-catalog.md
to get a
feasible
plan. Planning from generic game knowledge alone leads to designs MSW can't realize.
Right-size the build
the catalog gives a
build-effort hint
(Low / Medium / High) per genre — a signal, not a verdict (baseline 1–5 maps · 10–20 units/items · basic-to-intermediate mLua;
tower defense sits at the top of comfortably-solo
). Use it to set expectations, not to refuse a genre. Size the first build by
build-effort + scope (maps/content), never by a calendar/development-time estimate
— the skill can't know the user's skill level or available hours, so it doesn't promise 'this takes N days/weeks.'
When the user's ambition is large
(a High-effort genre, or many systems/maps, or "I want everything"), don't plan it all at once —
scope the
first build
down to a small playable core (MVP)
and push the rest to later Phases. This applies to any genre.
Single pass (no ping-pong) + one direction check
limit user touchpoints to
STEP 1 (batched questions)
and
STEP 3 (direction check)
— don't keep asking back in between. But
never skip STEP 3 (direction check) before writing the GDD
don't just flash the grounding result and jump straight to the GDD. Once the direction is confirmed, produce the deliverable immediately.
Standardized deliverable
drop the result into the fixed GDD structure (
references/gdd-template.md
) as markdown, so the implementation skills can pick it up and carry it to an MVP.
Carry the project forward
after each deliverable,
propose the next step first
(e.g., "Shall I write the Phase 1 detailed plan next?"). Proceed if the user wants it, stop if they say stop — it's a suggestion, not a push. (This differs from endless mid-document ping-pong — it connects the flow
between
deliverables.)
Decision gates = selectable choices, not free text
at each user decision gate —
STEP 3 direction check
, the
Phase handoff
(implement now vs write the next-Phase plan), and the
soft Phase gate
— present the options as a
structured selectable choice
via the agent's multiple-choice UI when available (e.g., Claude Code's
AskUserQuestion
), so the user clicks an option instead of typing a free-text reply. Mark the recommended option but don't force it; if the agent has no such UI, fall back to a clearly enumerated prose choice.
On startup — check for an existing GDD (resume / new / blocked)
A build spans multiple sessions and
milestones — each milestone is one GDD
. Where things live (all project-root, outside RootDesk, to survive
refresh_workspace
):
Active
GDD + Phase plan →
Docs/
.
Completed
GDD →
Archive/
(on milestone completion).
Archive/As-built.md
→ the world's running implementation record: a curated current-state map kept by the skill, an
AI / handoff reference, not a user-facing planning doc
(see STEP 6 +
Brownfield
below).
Show more
Installs
769
Repository
msw-git/msw-ai-…official
GitHub Stars
30
First Seen
11 days ago
Security Audits
Gen Agent Trust Hub
Pass
Socket
Pass
Snyk
Pass