THE AGENT SKILLS DIRECTORY
Reusable skills for AI agents. Install any of them into a Cohub world's agent with one command.
npx -y @neta-art/neta-search-cli@latest skills find "<what you need>"
Wrote a skill? Publish it here →
Basic Cohub abilities. Most agents already have these mounted; listed here for reference.
Paste this into your agent's chat — it fetches the skill and follows it.
Use the skill: game-maker. Run `npx -y @neta-art/neta-search-cli@latest skills use neta-search/game-maker --via site` and follow what it prints. Read its complete output, redirecting it to a temporary file first if necessary, and resolve relative paths from the skill directory it prints.npx -y @neta-art/neta-search-cli@latest skills use neta-search/game-makerTurn an idea into a real playable browser game, with proper art, levels, and controls, ready to share.
# Game Maker
## Operating Principles
Use this skill as the package entry point for games, gameplay prototypes, playful interactions, production game assets, maps, animations, and gameplay QA.
- **Own the production path.** Plan, build, validate, repair, and deliver gameplay work through this workflow, its required documents, selected subskills, failure policy, output contract, and mandatory protocol.
- **Keep protocol mandatory.** Every gameplay task must maintain `gameplay.work.json`, `protocol/subskill-execution.json`, and the required protocol evidence. Run the protocol checker at `startup`, `prebuild`, `preqa`, and `final`; complete its next actions before advancing.
- **Use subskills as execution methods.** Applicable subskills are required production methods. Load their required reading and follow their workflow and output format.
- **Build the real playable target.** Default to a complete, asset-backed, browser-playable result with clear controls, feedback, progression, restart/continue flow, and production-appropriate assets when the task calls for a game.
- **Match the existing project.** Preserve raw assets, source data, architecture, framework, routing, state boundaries, and existing behavior unless the user requests replacement or the current structure blocks the goal.
- **Do not hide blockers.** Report missing tools, failed validation, broken assets, incomplete protocol evidence, and known-broken outputs plainly instead of claiming delivery. Report them as plain consequences for the creator, not as protocol stage names.
- **Keep asset discipline.** Reuse existing assets only when they fit the current game's identity, style, runtime format, gameplay role, and protocol requirements. Use clear standardized names for generated, processed, sliced, exported, or runtime assets.
## Required reading
After reading this `SKILL.md` completely, read and apply the documents needed for the current task:
- `docs/ROUTING.md` — always read before choosing subskills.
- `docs/GAME_MAKER_PROTOCOL.md` — read for every gameplay task and apply the mandatory project contract, inventories, asset fit gate, visual QA evidence, and checker stage gates.
- `docs/WORKFLOW.md` — read for creation or modification tasks.
- `docs/ACCEPTANCE.md` — read before final delivery.
- `docs/MOBILE_SHARE_PLAYABILITY.md` — read when creating, modifying, or publishing any playable browser game unless the user explicitly requests desktop-only.
- `docs/PRODUCTION_ASSET_POLICY.md` — read when creating or modifying playable games with visual assets, or when any new game art is needed.
- `docs/OUTPUT_CONTRACT.md` — read before writing the final reply; it separates the user-facing reply from the internal record.
- `docs/FAILURE_POLICY.md` — read when tools, references, permissions, assets, dependencies, installs, or QA are unavailable.
Then load and apply specialist sibling skills when their domain matches the task. For AVG / visual novel / galgame / dating sim / narrative investigation / LLM-driven story demos, route to `create-avg` as the specialist workflow instead of treating the request as a generic browser game.
## Default build target
Unless the user, host environment, or project requires otherwise, default to:
- static HTML + CSS + JavaScript for small self-contained games; or
- React single-page project when component structure, state complexity, or future expansion justify it.
The final result should be browser-playable when the task involves a game or interactive page.
**Asset- or data-only asks are not game builds.** When the creator asks only for assets or data (hotspot JSON, collision grids, sprites, a QA overlay image…) or says they do not want a whole game, make exactly the files named — no game, no extra tool. Put them in one work folder (`works/games/<slug>`, protocol records alongside) and publish that folder once as a web Work so the creator has one openable thing: its `index.html` is a plain delivery sheet that only shows the requested files (the base image with the requested overlays and any behaviour the creator specified, e.g. a hover style, plus links to each file) — no layer toggles, stats panels, path demos, editors, or other features they did not ask for.
For new playable games, the default target is not merely "minimum viable". Build the most complete feasible version in one pass: gameplay loop, clear controls, meaningful feedback, progression, win/lose/restart or continue flow, production-appropriate assets, audio/animation/polish when feasible, published preview, and validation evidence.
## First actions
1. Classify the task type.
2. Identify available project files, references, assets, tools, and constraints.
3. If several coherent, direction-changing choices are still open after that scan — gameplay, scope, visual direction, how references should be combined, world integration — load and follow `questionnaire` once for this task, **before** the deep reference reading below: how much of that reading is warranted depends on the answers. A pointed ask missing one detail is a chat question; if the creator already gave clear direction or delegated the defaults, proceed without one. A list of options you were about to write out in Markdown is that round — run it as one. **Exception:** when this task routes to `create-avg` (AVG, galgame, visual novel, narrative investigation), do not open a questionnaire — that skill runs its own plan conversation and asks there.
4. If a single reference game or reference work exists, read the complete target work package and understand its gameplay principles before implementation.
5. If multiple reference games or reference works exist, analyze each reference independently, extract important traits, and present a concise synthesis proposal. If step 3 already settled how to combine them, proceed on that answer; otherwise ask that one question in chat before implementation.
6. Initialize or update the project-local protocol with `node <skill-dir>/tools/init-game-maker-protocol.mjs --work <workDir> --task-type <taskType>` before implementation (`<skill-dir>` = the folder this SKILL.md sits in — the directory `skills use` printed; never `/workspace/.agents/skills/game-maker`). For reference-game work, include `--reference-target <targetProjectDir>`.
7. Record selected subskills, required reading, and stage evidence in `protocol/subskill-execution.json` before advancing from planning to implementation.
8. If a visual reference exists, obtain enough visual information before rebuilding or matching it.
9. If modifying existing code, inspect relevant definitions and call sites before large changes.
10. If the host workspace supports logs or change records, review recent logs before modifying and write a new log after modifying.
11. Choose the smallest sufficient subskill or workflow path.
## Routing summary
| User intent | Preferred route |
| --- | --- |
| Several direction-changing choices still open before building | `questionnaire` for one-screen convergence |
| Create or modify a playable web game | `game-maker` core workflow |
| AVG, galgame, visual novel, dating sim, narrative investigation, LLM-driven story demo | `create-avg` |
| Visual QA for game page or assets | `game-visual-qa` |
| Browser testing, screenshots, clicking, interaction QA | `agent-browser` |
| Explicitly requested gameplay UI/interface reference selection | `gameplay-ui-reference` |
| 4×4 props, icons, shop items, furniture, object set | `referenced-4x4-asset-sheet` |
| Spritesheet, character animation, sprite repair, frame export | `production-spritesheet-builder` |
| Remove background, transparent PNG/WebP, no-crop cutout | `background-removal` |
| Clickable map, hotspot extraction, map annotation | `map-hotspot-annotator` |
| Collision, tile map, navigation data, walkable grids, pathfinding QA | `production-tile-collision-map` |
- Do not force every image task into a 4×4 sheet. Use 4×4 for independent asset sets; use spritesheet workflows for animation and runtime frame contracts; use map workflows for spatial content.
- Do not use local Pillow/Canvas/SVG/CSS procedural drawing as a replacement for Neta image generation when creating final game art.
## Product frontend rules
For browser-playable output:
- Use the viewport well; do not trap the game inside an unnecessary large rounded container.
- Do not default to rounded corners.
- Avoid browser scrollbars as part of the core experience.
- Do not show internal labels such as `MVP`, `mock`, or unrelated project names in user-facing UI.
- Avoid displaying identical information in multiple components.
- Keep components simple and avoid meaningless nesting.
- Check title length, font size, and container fit.
- Do not put implementation explanations or mechanical QA notes into the user-facing interface.
- Ensure controls are discoverable and usable.
- Ensure the experience can be restarted, completed, continued, or meaningfully interacted with unless the user requested a pure visual prototype.
## Asset rules
- Read `docs/PRODUCTION_ASSET_POLICY.md` before creating or replacing game visual assets.
- Use Neta `generate image` for new visual source art by default.
- Use specialist asset skills for production asset formats: `referenced-4x4-asset-sheet`, `production-spritesheet-builder`, `background-removal`, `production-tile-collision-map`, and `map-hotspot-annotator` as applicable.
- Keep raw inputs and generated sources whenever feasible.
- Keep each project's assets isolated.
- Check existing workspace assets for quality, subject, style, scale, transparency, runtime format, naming, identity, declared gameplay role, and gameplay-purpose fit before reuse.
- Reuse existing workspace assets when they fully support the current game's target experience, visual direction, gameplay logic, asset requirements, and runtime requirements.
- Every runtime asset must pass the protocol asset identity and fit gate before strict production delivery. The asset evidence must prove what each asset is, what current-game requirement it satisfies, what gameplay role it serves, where it is used, why it matches the current game, and which visual QA evidence confirms its fit.
- Workspace-reused and previous-project-reused assets must include source information, reuse justification, visual evidence, and an `approved-for-current-game` fit review status before final delivery.
- Give every generated, processed, sliced, exported, or runtime game asset a clear, standardized filename that states what the asset is, its key visual/gameplay traits, and its intended usage context.
- Compress or optimize runtime assets when appropriate.
- Do not use oversized originals directly when production-sized assets are needed.
- If image generation is unavailable, do not fabricate fake abstract placeholders unless the user explicitly accepts that fallback.
- If generation is blocked by credits or quota and the world already holds images of the game's core subjects (character covers, illustrations, scenes), do not stop before building: build and publish the playable game from that existing world art (fit-reviewed and processed locally as needed), then hand it over with one plain sentence on the art limitation plus the credits button, offering the full-art pass once credits are back. Stop and ask only when the world has no usable art for the core subjects. See `docs/FAILURE_POLICY.md`.
- Do not use emoji, inline SVG, CSS-only shapes, Canvas/Pillow procedural drawings, colored boxes, icon-font glyphs, or text labels as final substitutes for core runtime game assets.
- Local Pillow/Canvas/SVG/ImageMagick/CSS may be used for processing, slicing, masks, QA overlays, contact sheets, debug grids, and layout, but not as the default path for creating final game art.
- For transparent assets, prefer safe background removal and verify alpha output.
- For grid-based assets and spritesheets, verify dimensions before slicing or publishing.
## Validation handoff
Game Maker owns protocol validation. Visual, page, asset, browser, publish-readiness, and specialist QA rules live in the applicable QA or specialist skill.
When a gameplay task requires QA, load `game-visual-qa` or the matching specialist skill, follow that skill's required workflow, and record the resulting evidence in the project protocol.
## Final delivery
Two layers, two audiences — read `docs/OUTPUT_CONTRACT.md` before writing the reply.
Write the reply (and any user-facing summary) in the language of the creator's opening message, even though this skill is written in English; keep titles and names exactly as the creator gave them.
The reply to the creator carries:
- what was produced or changed;
- **for playable browser games: the published Work itself, handed over on its own line through the `interaction-components` skill** as a `work` target whose `workId` is `preview.workId` from `works/games/<slug>/meta.json` after publish — never only a prose/Markdown link, and never a `world-file` pointing at `index.html`; for assets/data: the published delivery-sheet Work card (same `work` target), then one `world-file` card per requested file;
- the target is exactly `{ "type": "work", "workId": "<preview.workId>" }` — do not switch it to a `studio-route` because the fallback carries a neta.art address. A `studio-route` needs a real `worldId` a tool printed this session; never fill `worldId` with the workId, a session id, or any other guessed value — without a confirmed `worldId`, keep the `work` target;
- limitations that actually affect using the result — including, when any gate failed or is blocked, one plain sentence saying so.
The protocol evidence — gate statuses, delivery level, remaining gaps — lives in `protocol/validation-final.json` under `gates`, written by the checker. Never paste it, the checker output, or protocol stage vocabulary into the reply.
**For playable browser games, publish as a Cohub Work before final delivery.** Use `neta work init/publish web works/games/<slug>` to produce a shareable Work URL. A localhost port or local-static path is not an acceptable deliverable for a playable game — the user cannot open `http://localhost:xxxx`. If the `neta work` CLI is unavailable after a safe install/recovery attempt, mark the result as `blocked` rather than delivering a localhost URL.
Close following the **next-steps** skill (REQUIRED).