菜单
Pick the correct swipi game archetype (platformer, top_down, grid_logic, tower_defense, ui_heavy) from a user prompt using physics-first logic. Invoke from the swipi-workflow skill during Phase 1, or any time you need to decide which template module a game belongs to.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Reference for generating game assets (sprites, backgrounds, tilemaps, audio) and wiring them into asset-pack.json. Invoked by the swipi-workflow skill during Phase 3, or any time the user asks Claude to add, replace, or debug game assets.
Pre-build consistency checklist and verify→diagnose→repair loop for swipi games. Invoke during Phase 6 of the swipi-workflow, or any time a build/test/dev command fails, or whenever the user reports that a generated game does not run.
Universal 6-section Game Design Document schema used by every swipi archetype. Invoke during Phase 2 of the swipi-workflow before writing GAME_DESIGN.md, or any time the user asks for the structure of a swipi GDD.
Design rules, template API, and implementation guide for grid_logic-archetype games (discrete grid + turn-based or step-based motion — Sokoban, Fire Emblem, Match-3, Pikachu-grid puzzles). Invoke during Phase 2 for GDD drafting and Phase 5 as the reading-list index.
Design rules, template API, and implementation guide for platformer-archetype games (side view + gravity — Mario, Street Fighter, Metal Slug, Castlevania). Invoke during Phase 2 to inform GDD drafting, and again during Phase 5 as a reading-list index.
Design rules, template API, and implementation guide for top_down-archetype games (top-down + free continuous motion — Zelda, Isaac, Vampire Survivors, twin-stick shooters). Invoke during Phase 2 for GDD drafting and Phase 5 as the reading-list index.
| name | swipi-classify-game |
| description | Pick the correct swipi game archetype (platformer, top_down, grid_logic, tower_defense, ui_heavy) from a user prompt using physics-first logic. Invoke from the swipi-workflow skill during Phase 1, or any time you need to decide which template module a game belongs to. |
Do not classify by genre name. Classify by the physics the game requires.
| Archetype | Physics profile | Key question | Examples (don't match the name — match the physics) |
|---|---|---|---|
platformer | Side view + gravity | Does the character fall if unsupported? | Mario, Terraria, Street Fighter, Castlevania |
top_down | Top-down + free continuous motion | Can the character move UP without jumping? | Zelda, Isaac, Vampire Survivors, twin-stick shooters |
grid_logic | Grid + discrete turns/snaps | Does position snap to a grid? | Sokoban, Fire Emblem, Match-3, Pikachu-grid puzzles |
tower_defense | Fixed paths + waves | Do enemies follow predetermined routes? | Kingdom Rush, Bloons TD, any "defend the base" game |
ui_heavy | No physics — primarily UI | Is gameplay driven by UI widgets, not spatial movement? | Card games, visual novels, quiz battles, trivia |
platformer. Stop.grid_logic. Stop.tower_defense. Stop.top_down. Stop.ui_heavy.Return a single JSON block with:
{
"archetype": "platformer",
"reasoning": "One sentence explaining which physics signal was decisive.",
"physicsProfile": {
"hasGravity": true,
"perspective": "side",
"movementType": "continuous"
}
}
ui_heavy, not grid_logic, even if cards appear on a grid-like board — gameplay is driven by UI/state, not spatial collisions.platformer, not ui_heavy — characters fall under gravity when knocked up.tower_defense, not grid_logic — fixed paths dominate over discrete grid logic.top_down, not platformer — the character moves up without jumping.