opencode-skills-collection 4.0.4 → 4.0.6

package/bundled-skills/game-development/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: game-development
-description: "Game development orchestrator. Routes to platform-specific skills based on project needs."
+description: >-
+  Game development orchestrator. Routes by platform, dimension, and engine fit
+  (web 2D/3D, hybrid DOM+canvas, narrative tools). Use when starting or
+  structuring a game project, choosing frameworks, or picking among Phaser,
+  PixiJS, Kaplay, Canvas/WebGL, Three.js, Babylon.js, Godot, Unity, or Ink/Twine.
 risk: unknown
 source: community
 date_added: "2026-02-27"
@@ -8,13 +12,13 @@ date_added: "2026-02-27"
 
 # Game Development
 
-> **Orchestrator skill** that provides core principles and routes to specialized sub-skills.
+> **Orchestrator skill** — principles plus routing to specialized sub-skills.
 
 ---
 
 ## When to Use This Skill
 
-You are working on a game development project. This skill teaches the PRINCIPLES of game development and directs you to the right sub-skill based on context.
+You are working on a game development project. This skill teaches PRINCIPLES and directs you to the right sub-skill based on context.
 
 ---
 
@@ -24,7 +28,7 @@ You are working on a game development project. This skill teaches the PRINCIPLES
 
 | If the game targets... | Use Sub-Skill |
 |------------------------|---------------|
-| Web browsers (HTML5, WebGL) | `game-development/web-games` |
+| Web browsers (HTML5, WebGL, WebGPU) | `game-development/web-games` |
 | Mobile (iOS, Android) | `game-development/mobile-games` |
 | PC (Steam, Desktop) | `game-development/pc-games` |
 | VR/AR headsets | `game-development/vr-ar` |
@@ -36,10 +40,11 @@ You are working on a game development project. This skill teaches the PRINCIPLES
 | 2D (sprites, tilemaps) | `game-development/2d-games` |
 | 3D (meshes, shaders) | `game-development/3d-games` |
 
-### Specialty Areas
+### Architecture / tooling
 
 | If you need... | Use Sub-Skill |
 |----------------|---------------|
+| Engine / framework choice, shell vs guest, fit tiers | `game-development/engine-selection` |
 | GDD, balancing, player psychology | `game-development/game-design` |
 | Multiplayer, networking | `game-development/multiplayer` |
 | Visual style, asset pipeline, animation | `game-development/game-art` |
@@ -51,8 +56,6 @@ You are working on a game development project. This skill teaches the PRINCIPLES
 
 ### 1. The Game Loop
 
-Every game, regardless of platform, follows this pattern:
-
 ```
 INPUT  → Read player actions
 UPDATE → Process game logic (fixed timestep)
@@ -64,7 +67,7 @@ RENDER → Draw the frame (interpolated)
 - Rendering: As fast as possible
 - Interpolate between states for smooth visuals
 
----
+**Hybrid / UI-heavy games:** the outer app may be DOM/event-driven; use a classic game loop only in canvas/WebGL viewports (or wherever simulation ticks).
 
 ### 2. Pattern Selection Matrix
 
@@ -76,11 +79,10 @@ RENDER → Draw the frame (interpolated)
 | **ECS** | Thousands of similar entities | RTS units, particles |
 | **Command** | Undo, replay, networking | Input recording |
 | **Behavior Tree** | Complex AI decisions | Enemy AI |
+| **Content-as-data** | Designers ship levels/events without code | JSON/YAML packs |
 
 **Decision Rule:** Start with State Machine. Add ECS only when performance demands.
 
----
-
 ### 3. Input Abstraction
 
 Abstract input into ACTIONS, not raw keys:
@@ -90,10 +92,6 @@ Abstract input into ACTIONS, not raw keys:
 "move"  → WASD, Left stick, Virtual joystick
 ```
 
-**Why:** Enables multi-platform, rebindable controls.
-
----
-
 ### 4. Performance Budget (60 FPS = 16.67ms)
 
 | System | Budget |
@@ -105,14 +103,7 @@ Abstract input into ACTIONS, not raw keys:
 | Rendering | 5ms |
 | Buffer | 1.67ms |
 
-**Optimization Priority:**
-1. Algorithm (O(n²) → O(n log n))
-2. Batching (reduce draw calls)
-3. Pooling (avoid GC spikes)
-4. LOD (detail by distance)
-5. Culling (skip invisible)
-
----
+**Optimization Priority:** Algorithm → Batching → Pooling → LOD → Culling.
 
 ### 5. AI Selection by Complexity
 
@@ -123,8 +114,6 @@ Abstract input into ACTIONS, not raw keys:
 | **GOAP** | High | Emergent, planning-based |
 | **Utility AI** | High | Scoring-based decisions |
 
----
-
 ### 6. Collision Strategy
 
 | Type | Best For |
@@ -145,30 +134,33 @@ Abstract input into ACTIONS, not raw keys:
 | Cache nothing | Cache references |
 | Optimize without profiling | Profile first |
 | Mix input with logic | Abstract input layer |
+| Pick an engine by hype | Match engine to genre + team + delivery target |
 
 ---
 
 ## Routing Examples
 
-### Example 1: "I want to make a browser-based 2D platformer"
-→ Start with `game-development/web-games` for framework selection
-→ Then `game-development/2d-games` for sprite/tilemap patterns
-→ Reference `game-development/game-design` for level design
+### “Browser 2D platformer”
+→ `game-development/engine-selection` → `game-development/web-games` → `game-development/2d-games` → `game-development/game-design`
 
-### Example 2: "Mobile puzzle game for iOS and Android"
-→ Start with `game-development/mobile-games` for touch input and stores
-→ Use `game-development/game-design` for puzzle balancing
+### “UI-heavy web game with small arcade challenges”
+→ `game-development/engine-selection` (shell vs guest) → `game-development/web-games` → `game-development/2d-games` for guests only
 
-### Example 3: "Multiplayer VR shooter"
-→ `game-development/vr-ar` for comfort and immersion
-→ `game-development/3d-games` for rendering
-→ `game-development/multiplayer` for networking
+### “Mobile puzzle”
+→ `game-development/mobile-games` → `game-development/game-design`
+
+### “Multiplayer VR shooter”
+→ `game-development/vr-ar` → `game-development/3d-games` → `game-development/multiplayer`
+
+### “Branching narrative with light stats”
+→ `game-development/engine-selection` (Ink/Twine) → host UI of your choice
 
 ---
 
 > **Remember:** Great games come from iteration, not perfection. Prototype fast, then polish.
 
 ## Limitations
+
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
 - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/bundled-skills/game-development/engine-selection/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: engine-selection
+description: >-
+  Selects game engines and frameworks by platform, genre, and architecture
+  (full canvas shell vs hybrid DOM shell + guest viewport). Covers Phaser,
+  PixiJS, Kaplay, Canvas/WebGL, Three.js, Babylon.js, Godot, Unity, Ink, Twine.
+  Use when choosing a stack or comparing runtimes before implementation.
+risk: safe
+source: self
+date_added: "2026-07-17"
+---
+
+# Engine selection
+
+> Pick tools that match **delivery target**, **interaction model**, and **team constraints**. Engines serve the game type — not the reverse.
+
+---
+
+## Fit questions (ask first)
+
+1. **Platform:** Web, mobile, PC, console, VR?
+2. **Primary loop:** Action/physics, turn-based, narrative branch, management/UI, hybrid?
+3. **Presentation:** Full-screen canvas, DOM/UI chrome, or both?
+4. **Toolchain:** No-build / ESM OK, or bundler + editor OK?
+5. **Authoring:** Code-only, or designers need Twine/Ink/Godot/Unity editors?
+
+---
+
+## Architecture patterns
+
+| Pattern | When | Notes |
+|---------|------|-------|
+| **Full engine shell** | Game *is* the canvas/scene | Phaser, Godot, Unity, Kaplay as app root |
+| **Renderer + custom logic** | You want draw power, own gameplay | PixiJS, Three.js + your systems |
+| **Hybrid shell + guest** | Dense UI/text + occasional skill-checks | DOM/app shell; mount canvas engines in modals/viewports only |
+| **Narrative runtime** | Branching prose is the product | Ink, Twine; host chrome separately |
+| **Content-as-data** | Levels/events authored as packs | JSON/YAML + thin loader; engine optional |
+
+---
+
+## Web — decision tree
+
+```
+What type of game?
+│
+├── Mostly DOM / panels / forms / text UI
+│   ├── + small arcade/spatial challenges
+│   │     └── Hybrid: custom shell + guest
+│   │         Raw Canvas/WebGL → Kaplay → Phaser → PixiJS
+│   └── + branching story
+│         └── Ink (inkjs) or Twine export → host in DOM
+│
+├── Full-screen 2D game
+│   ├── Full gameplay features (scenes, physics, input)
+│   │     └── Phaser 4  (or Kaplay if you want lighter/faster prototype)
+│   └── Mostly rendering / custom systems
+│         └── PixiJS 8  (or Raw Canvas/WebGL if tiny scope)
+│
+└── Full-screen 3D game
+    ├── Full engine / physics / XR
+    │     └── Babylon.js
+    └── Rendering-focused / lighter
+          └── Three.js
+```
+
+---
+
+## Quick comparison (web & common exports)
+
+| Tool | Type | Best for | Watch-outs |
+|------|------|----------|------------|
+| **Raw Canvas / WebGL** | 2D/low-level | Tiny games, learning, no framework tax | You own everything |
+| **Kaplay** (ex-Kaboom) | 2D toolkit | Fast prototypes, jam games | Less “full product” structure than Phaser |
+| **Phaser 4** | 2D engine | Complete 2D features | Heavier; often bundled |
+| **PixiJS 8** | 2D renderer | Performance, custom game code | Not a full gameplay framework alone |
+| **Three.js** | 3D renderer | Visuals, lightweight 3D | You add gameplay systems |
+| **Babylon.js** | 3D engine | Fuller 3D + XR | Heavier than Three for simple scenes |
+| **Ink + inkjs** | Narrative | Complex branching prose | Weak for real-time multi-entity sims |
+| **Twine / Twison / TweeJS** | Narrative | Educator-friendly branches | Export/host glue; not a physics engine |
+| **Godot 4** | Full engine | 2D/3D indie, open source | Web export iteration cost |
+| **Unity** | Full engine | Large teams, multi-platform | Heavy for simple web UI games |
+
+Editor-first web shells (**Construct**, **GDevelop**) fit visual prototyping; weaker when you need versioned code-first content pipelines.
+
+---
+
+## Non-web defaults (see also platform skills)
+
+| Target | Lean toward |
+|--------|-------------|
+| PC indie / open source | Godot 4 |
+| PC large team / multi-platform | Unity |
+| Mobile | See `game-development/mobile-games` (touch, stores, battery) |
+| VR/AR | See `game-development/vr-ar` (+ Babylon/Three on web) |
+
+---
+
+## Anti-patterns
+
+| Don't | Do |
+|-------|-----|
+| Choose Unity/Godot for a form-heavy browser tool | Prefer DOM/hybrid |
+| Force Ink to run real-time concurrent simulations | Use narrative tools for branches; custom/sim code for clocks & entities |
+| Use Phaser as “the whole app” when the surrounding UI is HTML | Prefer a hybrid guest viewport |
+| Optimize for WebGPU on day one | Ship WebGL; add WebGPU + fallback when needed |
+
+## When to Use
+
+Use when choosing or comparing game engines/frameworks before implementation, especially for hybrid DOM+canvas or narrative-first products.
+
+## Limitations
+
+- Does not replace platform skills (`game-development/web-games`, `game-development/pc-games`, …).
+- Final choice still depends on team skill and shipping constraints.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/bundled-skills/game-development/web-games/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: web-games
-description: "Web browser game development principles. Framework selection, WebGPU, optimization, PWA."
+description: >-
+  Web browser game development. Framework selection (Phaser, PixiJS, Kaplay,
+  Canvas/WebGL, Three.js, Babylon.js), hybrid DOM+canvas, WebGPU, optimization,
+  PWA, audio unlock. Use when building HTML5/WebGL/WebGPU games or choosing a
+  browser runtime.
 risk: unknown
 source: community
 date_added: "2026-02-27"
@@ -8,7 +12,7 @@ date_added: "2026-02-27"
 
 # Web Browser Game Development
 
-> Framework selection and browser-specific principles.
+> Framework selection and browser-specific principles. For stack choice details see `game-development/engine-selection`.
 
 ---
 
@@ -20,25 +24,43 @@ date_added: "2026-02-27"
 What type of game?
 │
 ├── 2D Game
-│   ├── Full game engine features? → Phaser
-│   └── Raw rendering power? → PixiJS
+│   ├── Full game engine features? → Phaser 4
+│   ├── Fast prototype / jam?      → Kaplay
+│   ├── Raw rendering power?       → PixiJS 8
+│   └── Tiny / no dependency?      → Raw Canvas / WebGL
 │
 ├── 3D Game
 │   ├── Full engine (physics, XR)? → Babylon.js
-│   └── Rendering focused? → Three.js
+│   └── Rendering focused?         → Three.js
 │
-└── Hybrid / Canvas
-    └── Custom → Raw Canvas/WebGL
+├── Hybrid (DOM UI + canvas moments)
+│   └── Custom shell + guest viewport
+│       (Canvas/Kaplay/Phaser/Pixi inside a region/modal)
+│
+└── Narrative-first
+    └── Ink (inkjs) or Twine export + DOM host
 ```
 
-### Comparison (2025)
+### Comparison
 
 | Framework | Type | Best For |
 |-----------|------|----------|
-| **Phaser 4** | 2D | Full game features |
-| **PixiJS 8** | 2D | Rendering, UI |
-| **Three.js** | 3D | Visualizations, lightweight |
-| **Babylon.js 7** | 3D | Full engine, XR |
+| **Raw Canvas / WebGL** | 2D / low-level | Small scope, full control |
+| **Kaplay** | 2D toolkit | Rapid prototypes |
+| **Phaser 4** | 2D engine | Full game features |
+| **PixiJS 8** | 2D renderer | Rendering, custom systems |
+| **Three.js** | 3D renderer | Visualizations, lightweight 3D |
+| **Babylon.js** | 3D engine | Full engine, XR |
+
+### Hybrid shell + guest
+
+Use when chrome is HTML (menus, inventories, text, dashboards) but bursts of play need a canvas:
+
+1. Mount guest in a container; pass context in.
+2. Run a **local** game loop in the guest.
+3. Return results (score, pass/fail); **destroy** guest (RAF, listeners, GL context as needed).
+
+Do not let the guest own global app routing unless the product *is* a full-screen game.
 
 ---
 
@@ -56,8 +78,8 @@ What type of game?
 
 ### Decision
 
-- **New projects**: Use WebGPU with WebGL fallback
-- **Legacy support**: Start with WebGL
+- **New GPU-heavy projects**: Use WebGPU with WebGL fallback
+- **Broad legacy / simple 2D**: Start with WebGL or Canvas 2D
 - **Feature detection**: Check `navigator.gpu`
 
 ---
@@ -69,7 +91,7 @@ What type of game?
 | Constraint | Strategy |
 |------------|----------|
 | No local file access | Asset bundling, CDN |
-| Tab throttling | Pause when hidden |
+| Tab throttling | Pause when hidden (`visibilitychange`) |
 | Mobile data limits | Compress assets |
 | Audio autoplay | Require user interaction |
 
@@ -85,16 +107,12 @@ What type of game?
 
 ## 4. Asset Strategy
 
-### Compression Formats
-
 | Type | Format |
 |------|--------|
-| Textures | KTX2 + Basis Universal |
+| Textures | KTX2 + Basis Universal (or WebP/PNG for simple 2D) |
 | Audio | WebM/Opus (fallback: MP3) |
 | 3D Models | glTF + Draco/Meshopt |
 
-### Loading Strategy
-
 | Phase | Load |
 |-------|------|
 | Startup | Core assets, <2MB |
@@ -105,35 +123,16 @@ What type of game?
 
 ## 5. PWA for Games
 
-### Benefits
-
-- Offline play
-- Install to home screen
-- Full screen mode
-- Push notifications
-
-### Requirements
-
-- Service worker for caching
-- Web app manifest
-- HTTPS
+**Benefits:** offline play, install, fullscreen, optional push.
+**Requirements:** service worker, web app manifest, HTTPS.
 
 ---
 
 ## 6. Audio Handling
 
-### Browser Requirements
-
-- Audio context requires user interaction
-- Create AudioContext on first click/tap
-- Resume context if suspended
-
-### Best Practices
-
-- Use Web Audio API
-- Pool audio sources
-- Preload common sounds
-- Compress with WebM/Opus
+- Create/resume `AudioContext` on first click/tap
+- Prefer Web Audio API; pool sources; preload common SFX
+- Compress with WebM/Opus when possible
 
 ---
 
@@ -146,15 +145,18 @@ What type of game?
 | Block on audio load | Lazy load audio |
 | Skip compression | Compress everything |
 | Assume fast connection | Handle slow networks |
+| Leave canvas engines running off-screen | Tear down guests |
 
 ---
 
 > **Remember:** Browser is the most accessible platform. Respect its constraints.
 
 ## When to Use
-This skill is applicable to execute the workflow or actions described in the overview.
+
+Use when building HTML5/WebGL/WebGPU games, choosing a browser runtime, or wiring hybrid DOM+canvas guests.
 
 ## Limitations
+
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
 - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/bundled-skills/git-advanced-workflows/SKILL.md

@@ -20,9 +20,8 @@ Master advanced Git techniques to maintain clean history, collaborate effectivel
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
-## Use this skill when
+## When to Use
 
 - Cleaning up commit history before merging
 - Applying specific commits across branches
@@ -405,15 +404,6 @@ git reflog
 git branch recovered-branch abc123
 ```
 
-## Resources
-
-- **references/git-rebase-guide.md**: Deep dive into interactive rebase
-- **references/git-conflict-resolution.md**: Advanced conflict resolution strategies
-- **references/git-history-rewriting.md**: Safely rewriting Git history
-- **assets/git-workflow-checklist.md**: Pre-PR cleanup checklist
-- **assets/git-aliases.md**: Useful Git aliases for advanced workflows
-- **scripts/git-clean-branches.sh**: Clean up merged and stale branches
-
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/git-pushing/SKILL.md

@@ -32,22 +32,22 @@ Do not use this skill for a maintainer merge batch, canonical synchronization, v
 
 ## Workflow
 
-Use the helper only after the safety gates pass. With no paths it stages all current changes, so use that form only when every dirty file belongs to the requested commit:
+Use the helper only after the safety gates pass. Resolve the installed directory that contains this `SKILL.md` and substitute its absolute path for `<skill-directory>` below; do not assume the current working directory is the catalog repository. With no paths the helper stages all current changes, so use that form only when every dirty file belongs to the requested commit:
 
 ```bash
-bash skills/git-pushing/scripts/smart_commit.sh
+bash "<skill-directory>/scripts/smart_commit.sh"
 ```
 
 With custom message:
 
 ```bash
-bash skills/git-pushing/scripts/smart_commit.sh "feat: add feature"
+bash "<skill-directory>/scripts/smart_commit.sh" "feat: add feature"
 ```
 
 To stage only named files, pass them after `--`:
 
 ```bash
-bash skills/git-pushing/scripts/smart_commit.sh "fix: scope change" -- path/to/file
+bash "<skill-directory>/scripts/smart_commit.sh" "fix: scope change" -- path/to/file
 ```
 
 The helper handles isolated staging, commit creation, and push; it does not replace validation, release tooling, or a rebase required by an advanced upstream branch.