@genex-ai/cli-demo 0.75.0-dev.194 → 0.77.0-dev.197
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +0 -1
- package/dist/index.js +13180 -12800
- package/package.json +1 -1
- package/templates/skills/genex-ai-character/SKILL.md +4 -1
- package/templates/skills/genex-ai-hud/SKILL.md +191 -28
- package/templates/skills/genex-ai-hud/references/masked-fill.md +54 -0
- package/templates/skills/genex-ai-hud/references/stage1-prompt-template.md +28 -7
- package/templates/skills/genex-ai-hud/references/stage2-prompt-template.md +8 -4
- package/templates/skills/genex-ai-menu/SKILL.md +84 -18
- package/templates/skills/genex-threejs-character-controller/SKILL.md +4 -1
- package/templates/skills/genex-threejs-game-content/SKILL.md +3 -16
- package/templates/skills/genex-threejs-game-ui/SKILL.md +60 -35
- package/templates/skills/genex-threejs-game-ui/references/style-capsules.md +17 -0
- package/templates/skills/genex-threejs-multiplayer/SKILL.md +3 -0
- package/templates/skills/genex-threejs-skill-router/SKILL.md +4 -1
- package/templates/skills/genex-threejs-skill-router/references/routing-map.md +19 -17
- package/templates/skills/genex-threejs-visual-validation/SKILL.md +4 -1
- package/templates/skills/genex-explore/SKILL.md +0 -106
|
@@ -50,22 +50,12 @@ Rules that make the contract real:
|
|
|
50
50
|
a milestone on the way to the contract, never a quiet replacement for it.
|
|
51
51
|
If the full ask genuinely doesn't fit, shrinking any line is a structured
|
|
52
52
|
question to the user with real options — never a silent cut justified as
|
|
53
|
-
"standard practice".
|
|
53
|
+
"standard practice". (Use your environment's structured question tool when
|
|
54
|
+
it has one — Claude Code: `AskUserQuestion`; Codex: `request_user_input`;
|
|
55
|
+
if it has none, e.g. Cursor, a short numbered list in chat.)
|
|
54
56
|
- **Minute ten is the design test.** If the honest answer is "the same sixty
|
|
55
57
|
seconds, again", the contract needs another beat (a new area unlocks, a
|
|
56
58
|
quest chain escalates, a build comes online) before any polish work.
|
|
57
|
-
- **Close it with the reuse sweep.** Run `npx genex explore` once (no query)
|
|
58
|
-
and map the contract's systems against the curated catalog — proven ports
|
|
59
|
-
of terrain, grass, water, vehicles, combat feel, buildings, dungeons exist
|
|
60
|
-
there to clone or borrow with credits (`$genex-explore` has the steps). One
|
|
61
|
-
reuse line per matched system; an empty catalog is a one-line note.
|
|
62
|
-
- **The sweep binds at build time, not just plan time.** Every clone/borrow
|
|
63
|
-
line stays an open item until it is either landed or cancelled out loud:
|
|
64
|
-
when that system comes up for real work — in v0 or any upgrade round — load
|
|
65
|
-
`$genex-explore` and follow its borrow steps, or tell the user in one line
|
|
66
|
-
why you're now building it fresh after all. A planned borrow that silently
|
|
67
|
-
turns into hand-rolled primitives is a scope cut like any other. (A "build
|
|
68
|
-
fresh, because X" line was decided at plan time — no re-announcement.)
|
|
69
59
|
- **The `ground:` line is a decision, not a default.** Flat is fine when
|
|
70
60
|
DECIDED — but the concept frame the user approved is a promise: if it shows
|
|
71
61
|
rolling hills or a shoreline and the game ships a flat plane, that visible
|
|
@@ -205,8 +195,5 @@ owns the authority rules.
|
|
|
205
195
|
- The contract posted, then quietly abandoned when the first slice previewed
|
|
206
196
|
well — the slice is a milestone, not the destination.
|
|
207
197
|
- Contract lines silently shrunk without a structured question to the user.
|
|
208
|
-
- A reuse line from the sweep ("borrow the grass system from the catalog")
|
|
209
|
-
silently replaced by hand-rolled primitives — landed or cancelled out loud,
|
|
210
|
-
never quietly dropped.
|
|
211
198
|
- The approved concept frame shows rolling hills or water; the game ships one
|
|
212
199
|
flat plane and nobody said so.
|
|
@@ -67,31 +67,37 @@ AAA games of the genre, and state in one line which structural conventions
|
|
|
67
67
|
you're borrowing. The bar is what those games ship, not "good enough for a
|
|
68
68
|
demo". Conventions only — never logos, exact layouts, or trade dress. The
|
|
69
69
|
same 2–3 names carry into the router's visual-direction gate for the scene.
|
|
70
|
-
Then turn references + brief into ONE **concept
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
70
|
+
Then turn references + brief into ONE **concept mockup** — the game concept
|
|
71
|
+
and the HUD Stage-1 mockup are the SAME image, generated once (never a
|
|
72
|
+
separate UI-free concept first): a single image of a PLAYABLE MOMENT of this
|
|
73
|
+
game with its complete HUD composited over it, built with `$genex-ai-hud`'s
|
|
74
|
+
Stage-1 prompt template. The scene half of the prompt comes from the game
|
|
75
|
+
contract in TEXT, not from a prior image: what the player is DOING
|
|
76
|
+
mid-action (the verb), what threatens them right now (enemy silhouettes),
|
|
77
|
+
what they are chasing (the objective — a finish gate, a goal, a pickup),
|
|
78
|
+
and how the space reads (route, scale) — plus the brief's palette,
|
|
79
|
+
materials, and light. A beautiful empty vista with nothing to fight and
|
|
80
|
+
nowhere to go is a FAILED concept; so is one that invents mechanics the
|
|
81
|
+
game doesn't have (a lap counter in a game without laps). Generate it
|
|
82
|
+
`--size 2560x1440 --quality high --candidates 2 --no-wait`, enqueued FIRST
|
|
83
|
+
of all art; the picked candidate's URL goes into the style-brief comment.
|
|
81
84
|
|
|
82
85
|
**Share it the moment it lands — queue first, show immediately, never wait.**
|
|
83
|
-
When the
|
|
84
|
-
|
|
85
|
-
|
|
86
|
+
When the mockup lands, pick the stronger of the two candidates yourself,
|
|
87
|
+
enqueue the downstream UI jobs and the core asset set against it in the same
|
|
88
|
+
breath — the frame you just generated IS the working style until the user
|
|
89
|
+
says otherwise. Then pick it up with
|
|
86
90
|
`genex wait <id> --open` (or generate it with `--open`): it opens in the
|
|
87
|
-
user's browser AND prints the
|
|
88
|
-
your message
|
|
91
|
+
user's browser AND prints the links. Paste BOTH candidates' URLs as
|
|
92
|
+
clickable links in your message and say which one you picked and why — a URL
|
|
93
|
+
is invisible in a terminal, and "do you like it?" with
|
|
89
94
|
no picture in front of the user is the #1 way this checkpoint fails (they end
|
|
90
95
|
up digging logs for the file path). Ask ONE keep-or-change question — "this
|
|
91
|
-
is roughly how the game will look: keep it, or change
|
|
96
|
+
is roughly how the game and its HUD will look: keep it, or change
|
|
97
|
+
something?" — **as
|
|
92
98
|
plain chat text, never via the blocking structured-question tool: a suspended
|
|
93
99
|
turn is a gate, and this question must not gate anything.** Silence is
|
|
94
|
-
acceptance; only explicit notes reopen the style. An unanswered style
|
|
100
|
+
acceptance of YOUR pick; only explicit notes reopen the style. An unanswered style
|
|
95
101
|
question that parks the art pipeline is how a finished game ships bare walls
|
|
96
102
|
and a placeholder HUD — strictly worse than re-rolling a few assets later.
|
|
97
103
|
**Feedback triggers a LOOP whenever it arrives:** if the user comes back
|
|
@@ -103,19 +109,25 @@ distinct directions instead of re-rolling blind (plain chat, same rule).
|
|
|
103
109
|
Every shown frame becomes the working style exactly like the first did:
|
|
104
110
|
silence after a shown regeneration accepts THAT frame, and when
|
|
105
111
|
`--candidates` goes unanswered, pick the strongest yourself and say so. When
|
|
106
|
-
the style actually changes, re-
|
|
107
|
-
the
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
re-
|
|
111
|
-
(`$genex-ai-
|
|
112
|
-
|
|
113
|
-
|
|
112
|
+
the style actually changes, re-run Stage 1 — the concept mockup itself —
|
|
113
|
+
with the user's exact notes (strictly CHEAPER than it used to be: one image
|
|
114
|
+
carries scene + HUD, there is no separate concept to redo), then re-anchor
|
|
115
|
+
the style-carrying art made against the old mockup: the menu still is
|
|
116
|
+
re-edited (`--edit`) against the new mockup and its video re-run once from
|
|
117
|
+
the new still (`$genex-ai-menu` — a user-driven style change re-opens its
|
|
118
|
+
one-video rule), and the HUD deconstruct (Stage 2 onward, `$genex-ai-hud`)
|
|
119
|
+
restarts from the new mockup. Style-neutral assets (most textures, sfx,
|
|
120
|
+
models) usually survive — judge each in one line. The same "open it + paste the
|
|
114
121
|
link" rule covers every image the user weighs in on — the menu still, the
|
|
115
122
|
HUD mockup candidates.
|
|
116
123
|
|
|
117
124
|
**The concept anchors STYLE, not truth.** Palette, materials, light, and
|
|
118
|
-
register come from the frame; CONTENT comes from the game contract.
|
|
125
|
+
register come from the frame; CONTENT comes from the game contract. This
|
|
126
|
+
matters MORE now that the concept carries a HUD: every widget in the mockup
|
|
127
|
+
is a PROPOSAL, and a widget with no backing mechanic is cut before Stage 2 —
|
|
128
|
+
mechanics come from the agreed game, never from the picture. Extra widgets
|
|
129
|
+
the image invented are recorded in the plan message as "deferred from
|
|
130
|
+
mockup" — never silently wired, never silently dropped. When
|
|
119
131
|
the frame lands, diff it against the contract in one visible line — what
|
|
120
132
|
does this game have that the frame doesn't show (enemies? arenas? the
|
|
121
133
|
finish? the pickup)? Carry those requirements in words into every later
|
|
@@ -125,9 +137,11 @@ an invented mechanic, or the absence of a real one, from a picture.
|
|
|
125
137
|
**4. Ask only when genuinely ambiguous.** If the concept pins the mood (a
|
|
126
138
|
"gothic horror dungeon crawler" pins it), decide and state the plan in one
|
|
127
139
|
line. Only when the art direction is truly open, ask ONE structured question
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
140
|
+
with 2–3 concrete directions, each naming its palette + font pair — using
|
|
141
|
+
your environment's structured question tool when it has one (Claude Code:
|
|
142
|
+
`AskUserQuestion`; Codex: `request_user_input`); if it has none (e.g.
|
|
143
|
+
Cursor), a short numbered list in chat. Never ask about the screen
|
|
144
|
+
inventory — it derives from the game type.
|
|
131
145
|
|
|
132
146
|
**5. Style follows THIS game's concept.** The examples in every Genex skill
|
|
133
147
|
are examples, not defaults. Do not default to neon/cyberpunk/synthwave — or
|
|
@@ -143,8 +157,11 @@ UI plan
|
|
|
143
157
|
• Screens: <list with tiers — loader / menu / pause (Esc) / win/lose / …>
|
|
144
158
|
• Style: <4–5 named hues> · fonts <display> / <body>
|
|
145
159
|
• References: <2–3 AAA games — one line on what's borrowed>
|
|
146
|
-
•
|
|
147
|
-
•
|
|
160
|
+
• Menu: <archetype + button treatment, one-line reason from the brief>
|
|
161
|
+
• Concept (HUD mockup): <generation id — 2 candidates>
|
|
162
|
+
• Queued next: HUD sheet (Stage 2, from the picked mockup) · menu still →
|
|
163
|
+
video <or "no menu: reason"> · logotype <or "skipped: reason">
|
|
164
|
+
• Deferred from mockup: <widgets the image invented but the game lacks — or "none">
|
|
148
165
|
```
|
|
149
166
|
|
|
150
167
|
A message missing any line means the gate did not run — go back and run it.
|
|
@@ -156,9 +173,12 @@ A message missing any line means the gate did not run — go back and run it.
|
|
|
156
173
|
navigation, phase transitions, UI sounds, vignette. Zero generations — the
|
|
157
174
|
game is playable immediately.
|
|
158
175
|
- **Tier 2 — the production UI, generated, async — mandatory, not an upsell.**
|
|
159
|
-
The sprite HUD (`$genex-ai-hud`) for EVERY game,
|
|
176
|
+
The sprite HUD (`$genex-ai-hud`) for EVERY game, the cinematic menu
|
|
160
177
|
video (`$genex-ai-menu`) whenever the menu decision is yes (the default for
|
|
161
|
-
every game)
|
|
178
|
+
every game), and the generated **logotype** — one `--transparent` wordmark
|
|
179
|
+
in the brief's display register (`$genex-ai-menu`'s logotype step), default
|
|
180
|
+
YES for every game with a menu; skipping it needs a one-line stated reason.
|
|
181
|
+
Enqueue the chain at the plan gate with `--no-wait`,
|
|
162
182
|
keep building, pick results up with `npx genex wait <id>`, swap them in as
|
|
163
183
|
they land. **Tier 2 must never block a playable v0 — but the game is NOT
|
|
164
184
|
DONE until its Tier-2 assets have landed and been wired in** (the only
|
|
@@ -169,7 +189,7 @@ A message missing any line means the gate did not run — go back and run it.
|
|
|
169
189
|
Shipping the placeholder CSS HUD as the final HUD is a failure, not a
|
|
170
190
|
tier choice.
|
|
171
191
|
- **Tier 3 — offer, don't build.** Video layers over the HUD, 9-slice panel
|
|
172
|
-
sprites,
|
|
192
|
+
sprites, animated menu sprites. Offer in one line
|
|
173
193
|
after the player has seen Tier 1+2 working; build on request.
|
|
174
194
|
|
|
175
195
|
## Architecture: DOM overlay by default
|
|
@@ -470,6 +490,11 @@ architecture and consume the shared style brief.
|
|
|
470
490
|
|
|
471
491
|
- No UI plan: screens invented one at a time, menu and HUD styled in two
|
|
472
492
|
different worlds.
|
|
493
|
+
- A separate UI-free concept frame generated before the HUD mockup — the
|
|
494
|
+
concept IS the Stage-1 mockup, one generation; a second scene image for
|
|
495
|
+
"the concept" is a wasted spend and a style-drift risk.
|
|
496
|
+
- The concept/mockup fed to `genex video --frame` — it has a HUD baked in;
|
|
497
|
+
the UI-free menu still is the ONLY valid frame input (`$genex-ai-menu`).
|
|
473
498
|
- HUD sprites never enqueued at the gate — the placeholder CSS shipped as the
|
|
474
499
|
final HUD.
|
|
475
500
|
- No pause screen, or a pause that isn't bound to Escape.
|
|
@@ -25,6 +25,9 @@ artifacts, and text never collides or truncates.
|
|
|
25
25
|
- Serif or engraved display type; humanist body; muted earthy palette with ONE
|
|
26
26
|
saturated accent reserved for danger/low-health.
|
|
27
27
|
- Feedback is material: gold glints on pickup, red vignette pulse on damage.
|
|
28
|
+
- Menu lean: **boxed plate buttons** (or left rail when the vista carries a
|
|
29
|
+
strong subject); ornate engraved logotype; sprite-chrome buttons suit the
|
|
30
|
+
most crafted briefs.
|
|
28
31
|
|
|
29
32
|
## Clean sci-fi / space
|
|
30
33
|
|
|
@@ -35,6 +38,8 @@ artifacts, and text never collides or truncates.
|
|
|
35
38
|
- Panels read as glass: slight transparency, subtle inner glow, no drop
|
|
36
39
|
shadows heavier than a whisper.
|
|
37
40
|
- Motion is precise and quick (120–200 ms), no bounce.
|
|
41
|
+
- Menu lean: **centered stack** or **minimal fullbleed**; hairline plate
|
|
42
|
+
buttons or bare text with wide tracking; a thin geometric logotype.
|
|
38
43
|
|
|
39
44
|
## Racing / arcade sport
|
|
40
45
|
|
|
@@ -46,6 +51,8 @@ artifacts, and text never collides or truncates.
|
|
|
46
51
|
- Saturated team/brand hues are fine — but two, not six.
|
|
47
52
|
- Values tween FAST (speed) or pop (position change); a gear change may
|
|
48
53
|
flash — a full-screen flash may not.
|
|
54
|
+
- Menu lean: **bottom command bar** (a garage/grid row); oblique bare-text
|
|
55
|
+
or chip buttons; a fast angular logotype.
|
|
49
56
|
|
|
50
57
|
## Military / modern shooter
|
|
51
58
|
|
|
@@ -54,6 +61,8 @@ artifacts, and text never collides or truncates.
|
|
|
54
61
|
- Stencil or condensed grotesque display; desaturated palette — amber/red
|
|
55
62
|
exist ONLY as warnings, so they still mean something.
|
|
56
63
|
- Damage reads as a directional vignette, not a number cloud.
|
|
64
|
+
- Menu lean: **left rail** with stencil bare text, or a **bottom command
|
|
65
|
+
bar**; a stencil logotype, desaturated.
|
|
57
66
|
|
|
58
67
|
## Horror
|
|
59
68
|
|
|
@@ -63,6 +72,8 @@ artifacts, and text never collides or truncates.
|
|
|
63
72
|
grain in the cohesion layer.
|
|
64
73
|
- UI motion is slow (400 ms+) and quiet; a sudden UI move is itself a scare —
|
|
65
74
|
spend it deliberately.
|
|
75
|
+
- Menu lean: **diegetic corner** or **minimal fullbleed** — prompt the still
|
|
76
|
+
to leave a calm region for the buttons; worn-type logotype, dim.
|
|
66
77
|
|
|
67
78
|
## Retro / 8-bit
|
|
68
79
|
|
|
@@ -72,6 +83,8 @@ artifacts, and text never collides or truncates.
|
|
|
72
83
|
already know; lean on them.
|
|
73
84
|
- Motion is stepped (frame-quantized), not eased; an optional scanline overlay
|
|
74
85
|
in the cohesion layer sells it.
|
|
86
|
+
- Menu lean: **centered stack** (the arcade attract screen); pixel-font bare
|
|
87
|
+
text with a blinking selector; a chunky pixel logotype at integer scale.
|
|
75
88
|
|
|
76
89
|
## Cozy / casual
|
|
77
90
|
|
|
@@ -81,6 +94,8 @@ artifacts, and text never collides or truncates.
|
|
|
81
94
|
(scale 0.95 → 1.02 → 1) instead of fading.
|
|
82
95
|
- Nothing flashes red; even failure is gentle (desaturate + a soft "try
|
|
83
96
|
again").
|
|
97
|
+
- Menu lean: **centered stack** with plump CSS plate buttons; a rounded
|
|
98
|
+
friendly logotype.
|
|
84
99
|
|
|
85
100
|
## Painterly / stylized adventure
|
|
86
101
|
|
|
@@ -90,3 +105,5 @@ artifacts, and text never collides or truncates.
|
|
|
90
105
|
readability.
|
|
91
106
|
- Palette lifted from the scene's own key art — sample it, don't invent a
|
|
92
107
|
second palette.
|
|
108
|
+
- Menu lean: **left rail** or **diegetic corner** over the painted vista;
|
|
109
|
+
brushwork logotype; bare text with calligraphic display face.
|
|
@@ -67,6 +67,9 @@ Infer this yourself when the experience is clear. Do **not** make the player cho
|
|
|
67
67
|
preset, or config. Ask one plain-language question only when the design genuinely supports both
|
|
68
68
|
models and the answer changes the experience — for example: *"Should this be one ongoing arena
|
|
69
69
|
people drop into, or a fresh fair match that waits for everyone and then starts together?"*
|
|
70
|
+
(Use your environment's structured question tool when it has one — Claude Code:
|
|
71
|
+
`AskUserQuestion`; Codex: `request_user_input`; if it has none, e.g. Cursor, a short numbered
|
|
72
|
+
list in chat.)
|
|
70
73
|
|
|
71
74
|
| Player experience | Model | Why |
|
|
72
75
|
| --- | --- | --- |
|
|
@@ -114,7 +114,10 @@ chain, which locations, what progression), plus the minute-ten answer. Those
|
|
|
114
114
|
lines are hard floors exactly like the sprite HUD — the game is not done,
|
|
115
115
|
published, or handed off while a contract line is missing, and shrinking one
|
|
116
116
|
is a structured question to the user, never a silent cut ("vertical slice
|
|
117
|
-
first" is a build order, not a smaller destination)
|
|
117
|
+
first" is a build order, not a smaller destination) — use your environment's
|
|
118
|
+
structured question tool when it has one (Claude Code: `AskUserQuestion`;
|
|
119
|
+
Codex: `request_user_input`); if it has none (e.g. Cursor), a short numbered
|
|
120
|
+
list in chat. A request that says
|
|
118
121
|
**big/open world** also loads `$genex-threejs-open-world` and fixes the
|
|
119
122
|
world's scale as a number in the same plan — world size comes from streamed
|
|
120
123
|
terrain, never from fog hiding the edges of a small plane. This routing
|
|
@@ -29,19 +29,12 @@ Three.js release or branch, and do not blindly copy demo architecture.
|
|
|
29
29
|
additionally fixes the world's scale class as a number here via
|
|
30
30
|
`$genex-threejs-open-world` — kilometers of streamed terrain, never one
|
|
31
31
|
fogged plane. Scope belongs to the user: shipping fewer or smaller than
|
|
32
|
-
the ask requires their explicit OK through a structured question
|
|
32
|
+
the ask requires their explicit OK through a structured question (your
|
|
33
|
+
environment's structured question tool when it has one — Claude Code:
|
|
34
|
+
`AskUserQuestion`; Codex: `request_user_input`; if none, e.g. Cursor, a
|
|
35
|
+
short numbered list in chat) — a
|
|
33
36
|
"vertical slice first" is a build order, never a license to shrink the
|
|
34
|
-
destination silently.
|
|
35
|
-
`npx genex explore` once (no query) and map the plan's systems against the
|
|
36
|
-
curated catalog — proven ports of terrain, grass, water, vehicles, combat
|
|
37
|
-
feel, buildings, dungeons exist there to clone or borrow (credits carried,
|
|
38
|
-
`$genex-explore` has the integration steps). One reuse line per matched
|
|
39
|
-
system in the plan (clone as base / borrow parts / build fresh because X);
|
|
40
|
-
hand-building a system the catalog already proves is the waste this sweep
|
|
41
|
-
exists to prevent. An empty catalog is a one-line note, not a blocker.
|
|
42
|
-
Clone/borrow lines bind at build time too: each is landed or cancelled out
|
|
43
|
-
loud when its system gets built — never silently swapped for hand-rolled
|
|
44
|
-
primitives (build-fresh lines are already decided).
|
|
37
|
+
destination silently.
|
|
45
38
|
2. Wire player identity before any boot code: `$genex-threejs-embed-auth` is
|
|
46
39
|
mandatory for every game (`initEmbed(...)` + the `waitForPlayer()` gate) —
|
|
47
40
|
saves, leaderboards, and multiplayer auth all come from it.
|
|
@@ -49,9 +42,12 @@ Three.js release or branch, and do not blindly copy demo architecture.
|
|
|
49
42
|
one shared style brief, a tier per screen — stated visibly in chat, never
|
|
50
43
|
decided silently. Enqueue the Tier-2 UI generations now with `--no-wait`
|
|
51
44
|
(pick them up later with `npx genex wait <id>`) — they render server-side
|
|
52
|
-
while you build the game. FIRST of all art: the gate's **concept
|
|
45
|
+
while you build the game. FIRST of all art: the gate's **concept mockup** —
|
|
53
46
|
a playable-moment shot (verb + threat + objective in frame, per the
|
|
54
|
-
game-ui gate)
|
|
47
|
+
game-ui gate) WITH the full HUD composited over it: the `$genex-ai-hud`
|
|
48
|
+
Stage-1 image, one generation serving as concept, style checkpoint, and
|
|
49
|
+
HUD blueprint (never a separate UI-free concept first). Shown to the user
|
|
50
|
+
for a keep-or-change answer the moment
|
|
55
51
|
it lands — the answer is advisory, never a gate: the art pipeline starts
|
|
56
52
|
against the frame as-is, and the game-ui skill owns the re-anchor loop
|
|
57
53
|
when notes arrive; later `--edit`-able generations anchor to it for STYLE
|
|
@@ -224,11 +220,17 @@ subagents (e.g. Claude Code's Agent tool), split these off; in environments
|
|
|
224
220
|
without them (Cursor), the same order simply runs sequentially and the
|
|
225
221
|
`--no-wait` pattern still hides most generation latency.
|
|
226
222
|
|
|
227
|
-
- **HUD chain worker.** The moment the Stage-1 mockup
|
|
223
|
+
- **HUD chain worker.** The moment the Stage-1 mockup (the game concept)
|
|
224
|
+
lands, hand the whole
|
|
228
225
|
`$genex-ai-hud` chain to one subagent: pick the better candidate → Stage-2
|
|
229
226
|
sheet → clean → extract → masks → write the sprite wiring. Its prompt must
|
|
230
|
-
be self-contained — the style brief,
|
|
231
|
-
output dir, and exactly which files it owns.
|
|
227
|
+
be self-contained — the style brief, the mockup URL, the
|
|
228
|
+
output dir, and exactly which files it owns. **Handoff rule:** whoever
|
|
229
|
+
wires the HUD after the subagent finishes MUST read the produced
|
|
230
|
+
`*.annotated-progress.json` and `.bbox.json` files from disk — fillBox
|
|
231
|
+
numbers, `segments`, and sprite dims do not survive a prose summary, and
|
|
232
|
+
wiring from the summary is how validated masks end up on disk while the
|
|
233
|
+
shipped fill is a naive width%.
|
|
232
234
|
- **Asset shepherd.** One subagent runs `npx genex wait` on every queued ID
|
|
233
235
|
and wires each asset in as it lands (skybox, models, menu video, dressing),
|
|
234
236
|
swapping placeholders out and reporting each swap.
|
|
@@ -40,7 +40,10 @@ Meshy Image-to-3D first produces an unremeshed high-detail model. Show its
|
|
|
40
40
|
front, back, left, and right views and report its measured face count. Preserve
|
|
41
41
|
that model in R2. Before rigging, ask the user to approve a separate
|
|
42
42
|
10,000-face triangle remesh. The 10k remesh—not the high-detail source—is
|
|
43
|
-
rigged and animated.
|
|
43
|
+
rigged and animated. (For these approvals, use your environment's structured
|
|
44
|
+
question tool when it has one — Claude Code: `AskUserQuestion`; Codex:
|
|
45
|
+
`request_user_input`; if it has none, e.g. Cursor, a short numbered list in
|
|
46
|
+
chat.)
|
|
44
47
|
|
|
45
48
|
The selected high-detail model remains in a neutral A-pose before animation.
|
|
46
49
|
Record evidence that the user saw its four views and face count before
|
|
@@ -1,106 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: genex-explore
|
|
3
|
-
description: Search the curated Genex community gallery with `npx genex explore` — once at the planning stage (the plan sweep, browse the catalog against the game plan and state reuse decisions) and again before hand-writing any hard system. Use when planning a new game, or when it needs terrain, grass, water, vehicles, buildings, dungeons, flocking, or advanced shaders — proven open-source Three.js implementations to clone or borrow from, credits included.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Genex Explore — proven building blocks from the community gallery
|
|
7
|
-
|
|
8
|
-
Some systems are notoriously hard to get right from scratch: believable grass,
|
|
9
|
-
vehicle physics, procedural buildings and dungeons, fish/boid flocking, water,
|
|
10
|
-
advanced shader effects. The curated community gallery holds **faithful ports of
|
|
11
|
-
proven open-source Three.js projects** — playable, cloneable, and licensed for
|
|
12
|
-
reuse. Search it before hand-writing one of those systems.
|
|
13
|
-
|
|
14
|
-
## The plan sweep — once per game, right after the plan is written
|
|
15
|
-
|
|
16
|
-
The moment the game contract (and the content contract, when there is one) is
|
|
17
|
-
on the table, run the catalog against it ONCE:
|
|
18
|
-
|
|
19
|
-
```bash
|
|
20
|
-
npx genex explore
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
No query — the catalog is small and every entry is proven, so one browse
|
|
24
|
-
covers the whole plan at once. Then walk the plan's systems (terrain, grass,
|
|
25
|
-
water, vehicles, combat feel, buildings, dungeons…) and for each one that a
|
|
26
|
-
catalog entry serves, state a reuse decision in the plan, one line each:
|
|
27
|
-
**clone as the base** / **borrow parts** (see below) / **build fresh, because
|
|
28
|
-
X**. Not deciding is the failure — a session that hand-builds a grass field
|
|
29
|
-
while a proven grass system sits in the catalog wasted its minutes on a
|
|
30
|
-
solved problem. If the catalog comes back empty on this stand, say so in one
|
|
31
|
-
line and move on — the sweep costs one command either way.
|
|
32
|
-
|
|
33
|
-
The clone/borrow lines bind at BUILD time too: each stays an open item until
|
|
34
|
-
the borrow lands or you cancel it in one plain line to the user ("build
|
|
35
|
-
fresh, because X" lines are already decided — nothing to re-announce). A
|
|
36
|
-
"borrow the grass system" that quietly ships as hand-rolled cones never went
|
|
37
|
-
through anyone's decision — it's a scope cut. (`genex preview` reminds you
|
|
38
|
-
once if it sees a browsed catalog and zero visible borrows.)
|
|
39
|
-
|
|
40
|
-
## When to use again — before any hard system
|
|
41
|
-
|
|
42
|
-
Later in the build, before hand-writing a hard visual/physics system the plan
|
|
43
|
-
didn't foresee, run:
|
|
44
|
-
|
|
45
|
-
```bash
|
|
46
|
-
npx genex explore "<what you need>"
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
Examples: `npx genex explore "grass"`, `npx genex explore "vehicle physics"`,
|
|
50
|
-
`npx genex explore "procedural building"`. No sign-in needed — this works even
|
|
51
|
-
before `genex init`.
|
|
52
|
-
|
|
53
|
-
**Not sure what exists?** Run it with no arguments to browse the whole curated
|
|
54
|
-
catalog first — it's small and every entry is proven:
|
|
55
|
-
|
|
56
|
-
```bash
|
|
57
|
-
npx genex explore
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
Each result prints everything you need to act on it:
|
|
61
|
-
|
|
62
|
-
- `play:` — open it in the browser to judge whether it fits.
|
|
63
|
-
- `clone:` — the public repo with **editable source on `main`**.
|
|
64
|
-
- `upstream:` — the original source repo, with its author and license.
|
|
65
|
-
|
|
66
|
-
Add `--json` for machine-readable output.
|
|
67
|
-
|
|
68
|
-
## How to integrate a result
|
|
69
|
-
|
|
70
|
-
**As a NEW game (start from the whole project):**
|
|
71
|
-
|
|
72
|
-
1. `git clone <clone URL from the output> <name>` — pick a short one-word name.
|
|
73
|
-
2. `cd <name>`, then run init on the SAME CLI channel your current project
|
|
74
|
-
uses: `npx @genex-ai/cli-demo@dev init <name>` — or `@dev` when you're
|
|
75
|
-
on the dev stand (unsure? `dashboardOrigins` in your current project's
|
|
76
|
-
`.genex/project.json` says which). Never use `--force`. This creates your
|
|
77
|
-
own project; the original is untouched.
|
|
78
|
-
3. `npm install`, keep `base: './'` in `vite.config`, then build your changes
|
|
79
|
-
and ship with `npx genex preview`.
|
|
80
|
-
|
|
81
|
-
**To BORROW parts into the current project:**
|
|
82
|
-
|
|
83
|
-
1. Clone the result somewhere temporary, separate from your project
|
|
84
|
-
(e.g. `/tmp/genex-explore-src`).
|
|
85
|
-
2. Study how it implements the part you need, then bring **just that** over —
|
|
86
|
-
real code and assets, adapted to your file paths. Don't wholesale-overwrite
|
|
87
|
-
your game.
|
|
88
|
-
3. Reused assets must live under `public/assets/` to ship. New assets are
|
|
89
|
-
generated as usual with `$genex-ai-model`, `$genex-ai-skybox`,
|
|
90
|
-
`$genex-ai-sfx`, or `$genex-ai-texture`.
|
|
91
|
-
|
|
92
|
-
## Credits rule (non-negotiable)
|
|
93
|
-
|
|
94
|
-
Every curated result carries an upstream link, author, and license — that
|
|
95
|
-
credit is part of the deal that makes these projects reusable. Whatever you
|
|
96
|
-
build from one:
|
|
97
|
-
|
|
98
|
-
- keep the attribution block in the README (upstream source repo URL, author,
|
|
99
|
-
license) exactly as the port carries it;
|
|
100
|
-
- keep any in-game credits screens or notices in place;
|
|
101
|
-
- carry the credit into anything you publish or remix from it.
|
|
102
|
-
|
|
103
|
-
If nothing matches your query, run `npx genex explore` with no arguments to
|
|
104
|
-
see everything available, or try a broader term (terrain, grass, vehicle,
|
|
105
|
-
water, building, dungeon, fish, shader) — or build it with the regular
|
|
106
|
-
`genex-threejs-*` skills instead.
|