ワンクリックでManusで任意のスキルを実行

fork

スター54

フォーク12

更新日2026年6月4日 14:25

Fork another vibedgames project's source to build on it, and ship your own source so others can fork you. Use when the user wants to remix, fork, clone, or build on top of an existing deployed game, or asks how source-on-deploy works. Triggers: 'fork <slug>', 'remix this game', 'build on <slug>', 'start from an existing project', 'clone a deployed game', 'make source forkable'.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

kyh

kyh/vibedgames

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Forking vibedgames projects

Every vg deploy ships the project source alongside the built bundle, and that source is forkable by default — any logged-in user can pull it down, re-slug it, and build on it. This is the remix loop.

Fork an existing project

vg fork <source-slug> [new-slug]

<source-slug> — the project to fork (e.g. bomberman).
[new-slug] — directory + slug for your copy. Defaults to <source-slug>-fork.
Downloads the source archive, extracts it into ./<new-slug>/, and rewrites vibedgames.json + package.json to the new slug (clean slate — no link back to the original).
--json emits { slug, dir, forkedFrom } for agent parsing.
--force overwrites an existing target directory.

Then build on it and redeploy under your own slug:

vg fork bomberman my-bomberman
cd my-bomberman
npm install
npm run dev          # iterate
npm run build
vg deploy ./dist     # ships to my-bomberman.vibedgames.com (with source, forkable)

vg fork requires login (vg login, or VG_TOKEN for headless/agent use). If a project shipped without source (vg deploy --no-source), fork fails with a clear NOT_FOUND — there's nothing to fork.

Ship source so others can fork you

Source upload is on by default — vg deploy packs and uploads it every time. Nothing extra to do. To opt out (proprietary / private code):

vg deploy ./dist --no-source

What's in the source archive

The archive is the project root (the directory containing vibedgames.json), gzipped, respecting .gitignore and a hard exclude list:

always excluded: node_modules, .git, dist/build/.next/.turbo/.cache, logs
secrets always excluded: .env*, *.key, *.pem, id_*, .npmrc, .git-credentials
plus anything your .gitignore (or a .vibedgamesignore) lists

vg deploy prints the file count + size of the source it's about to ship.

Source is a publish. It's forkable by anyone, so never hardcode secrets, API keys, or tokens in committed source — read them from env at runtime and document the required vars in the README. The exclude list is a safety net, not a substitute for not committing secrets.

Gotchas

Globally-unique slugs. Your fork can't reuse the source's slug; vg fork re-slugs for you. Pick a fresh, available slug.
Workspace/catalog deps. A forked project keeps its package.json as-is. If you fork one of the bundled monorepo example games, its deps may use workspace:^ / catalog: (monorepo-only) — replace those with concrete npm versions (e.g. @vibedgames/multiplayer: ^<latest>) before npm install. Normal standalone projects fork and install cleanly.
Source size cap is 25 MB (archived). Keep large generated assets in .gitignore if they blow past it; regenerate them via vg generate.

Deploy

See the deploy skill for the full deploy flow. The short version:

vg deploy ./dist --slug <slug>   # source uploaded by default → live + forkable

このリポジトリの他の Skills

同じリポジトリ

generate

kyh/vibedgames

Use the `vg generate` CLI to search, inspect, run, and manage 1200+ generative model endpoints. Trigger when the user asks to "generate an image", "make a video", "search models", "run a model", "fetch schema", "check pricing", "upload an asset", "queue async job", "track request", or any direct interaction with the model endpoint catalog. This is the foundational skill. Every other media skill in this repo executes its work through `vg generate` commands. Use `--json` whenever the output will be parsed by an agent.

2026-07-1954

threejs

kyh/vibedgames

Build 3D browser apps AND games with Three.js (r150+, ES modules): scene setup, geometries, materials, lighting, animation, GLTF models, physics (Rapier/cannon-es/arcade), character controllers, follow/third-person cameras, fixed-timestep loops, post-processing, and performance/debugging. Use for 'create a three.js scene/app/showcase', any 3D web content, and turning a scene into a game — 'add physics to my three.js game', 'third-person/character controller', 'follow camera', 'jump and gravity', 'collide with / pick up objects', 'structure my 3d game'. Trigger: threejs, three.js, 3D scene, WebGL scene, GLTF/GLB, OrbitControls, Rapier, cannon-es, 3D game, third-person controller. For 2D games use `phaser`; for engine-agnostic feel/balance/level craft use the game-craft skills.

2026-07-1554

animated-spritesheets

kyh/vibedgames

Turn a character anchor into an engine-loadable animated spritesheet by generating ONE labeled pose-board image (a grid of the same character in the frames of an action) and slicing it. Works for any action — idle, run, jump, attack, hurt, crouch, death, roll. Generates a per-frame-labeled pose board on a flat chroma matte, recovers/slices the frames, keys + despills, snaps to crisp native pixels, normalizes with headroom, and packs spritesheet.png + a manifest. Triggers: 'sprite animation', 'animated spritesheet', 'attack animation', 'walk/run cycle', 'animate this character', 'game sprite animation', 'sprite pose sheet'.

2026-07-1154

ask-me

kyh/vibedgames

Interview the user relentlessly about the game they want to make until the idea is build-ready, resolving each branch of the design tree one question at a time. Use when the user has a fuzzy or one-line game idea and wants to flesh it out before building: 'grill me about my game', 'help me figure out what game to make', 'stress-test my game idea', 'interview me about the game', 'I want to make a game but I'm not sure what'. Not for when the user already knows what they want built — go straight to game-playbook.

2026-07-1154

capacitor-ios

kyh/vibedgames

Build and ship Three.js apps on Capacitor iOS with Vite and Swift Package Manager: GLTF loading, assets_index animation UI, OrbitControls mouse/touch mappings, and iOS sync/run troubleshooting.

2026-07-1154

phaser

kyh/vibedgames

Build 2D browser games with Phaser 4: scene lifecycle, sprites, Arcade/Matter physics, tilemaps, WebGL rendering, filters, lighting, shaders, DynamicTexture/RenderTexture, SpriteGPULayer, TilemapGPULayer, and Phaser 3 to 4 migration. Trigger: phaser, phaser 4, phaser v4, create phaser game, add phaser scene, phaser sprite, phaser physics, phaser tilemap, phaser arcade, phaser webgl renderer, phaser filters, phaser SpriteGPULayer, phaser TilemapGPULayer, migrate phaser 3 to 4.

2026-07-1154

name	fork
description	Fork another vibedgames project's source to build on it, and ship your own source so others can fork you. Use when the user wants to remix, fork, clone, or build on top of an existing deployed game, or asks how source-on-deploy works. Triggers: 'fork <slug>', 'remix this game', 'build on <slug>', 'start from an existing project', 'clone a deployed game', 'make source forkable'.

Forking vibedgames projects

Fork an existing project

vg fork <source-slug> [new-slug]

<source-slug> — the project to fork (e.g. bomberman).
[new-slug] — directory + slug for your copy. Defaults to <source-slug>-fork.
Downloads the source archive, extracts it into ./<new-slug>/, and rewrites vibedgames.json + package.json to the new slug (clean slate — no link back to the original).
--json emits { slug, dir, forkedFrom } for agent parsing.
--force overwrites an existing target directory.

Then build on it and redeploy under your own slug:

vg fork bomberman my-bomberman
cd my-bomberman
npm install
npm run dev          # iterate
npm run build
vg deploy ./dist     # ships to my-bomberman.vibedgames.com (with source, forkable)

Ship source so others can fork you

Source upload is on by default — vg deploy packs and uploads it every time. Nothing extra to do. To opt out (proprietary / private code):

vg deploy ./dist --no-source

What's in the source archive

The archive is the project root (the directory containing vibedgames.json), gzipped, respecting .gitignore and a hard exclude list:

always excluded: node_modules, .git, dist/build/.next/.turbo/.cache, logs
secrets always excluded: .env*, *.key, *.pem, id_*, .npmrc, .git-credentials
plus anything your .gitignore (or a .vibedgamesignore) lists

vg deploy prints the file count + size of the source it's about to ship.

Source is a publish. It's forkable by anyone, so never hardcode secrets, API keys, or tokens in committed source — read them from env at runtime and document the required vars in the README. The exclude list is a safety net, not a substitute for not committing secrets.

Gotchas

Globally-unique slugs. Your fork can't reuse the source's slug; vg fork re-slugs for you. Pick a fresh, available slug.
Workspace/catalog deps. A forked project keeps its package.json as-is. If you fork one of the bundled monorepo example games, its deps may use workspace:^ / catalog: (monorepo-only) — replace those with concrete npm versions (e.g. @vibedgames/multiplayer: ^<latest>) before npm install. Normal standalone projects fork and install cleanly.
Source size cap is 25 MB (archived). Keep large generated assets in .gitignore if they blow past it; regenerate them via vg generate.

Deploy

See the deploy skill for the full deploy flow. The short version:

vg deploy ./dist --slug <slug>   # source uploaded by default → live + forkable