Game Development Studio

View saved version →

---
name: game-asset-production
description: Create, inspect, normalize, validate, and package game-development assets with local tools plus optional Tripo and Leonardo jobs. Use for 3D, texture, reference-image, sound-effect, Blender, GLB, PBR, or USDZ asset-production work; not for admitting packages into a game project.
---

# Game Asset Production

Drive the local `game-dev` CLI and finish with a verified canonical package whenever the result is meant for reuse or vendoring.

Read [references/commands.md](references/commands.md) for command shapes and lifecycle handoffs.

## Workflow

1. Run capability discovery and the relevant doctor checks. Inspect existing source bytes before requesting paid generation.
2. Define the asset specification, intended engine use, dimensions, topology and texture budgets, license, and stable name. Preserve the exact prompt and negative prompt.
3. For a paid provider, prepare a JSON request first. The user must already control the provider account and have configured its credential outside the conversation; never request, accept, reveal, or configure that credential. Do not submit until the user authorizes that invocation and sets a spend ceiling. Keep credentials out of arguments, files, logs, screenshots, and receipts.
4. Follow the durable job to a terminal state. Record the provider job identity and receipt; local cancellation does not prove provider-side cancellation.
5. Download to a new destination, inspect the bytes, and validate against the explicit game policy. Never trust an extension, provider status, or Blender receipt without checking the produced file.
6. Normalize through Blender only when inspection identifies a repair or export need. Never modify the source in place. Because normalization and preview generation write files, leave their exact source and destination command unexecuted until the user authorizes that invocation. Re-inspect and re-validate the output.
7. Build a canonical package with provenance, license, hashes, validation results, and optional preview. Package construction is also a write and requires exact invocation authorization even though the CLI command has no `--confirm` option. Verify the package before reporting it ready.

When the host exposes ImageGen, it is an optional host-native capability for a bespoke 2D concept or texture source. Use it only when the user requests generated imagery or it is genuinely the selected art workflow; never assume it is installed or available. Preserve that image's prompt and provenance before any Tripo or offline PBR derivation.

## Stop conditions

Stop and report the blocker when the local CLI reports a credential missing, provider availability, Blender, a license decision, a required source file, exact write authorization, or explicit spend approval is missing. Do not ask for the credential, purchase credits, accept a new license, weaken validation, or silently substitute a provider.

## Evidence boundary

Separate provider acceptance, downloaded bytes, static GLB inspection, Blender normalization, policy validation, package integrity, GPU import, and human visual review. Claim only the stages with receipts or direct checks. Generated or normalized does not mean game-ready until the requested policy passes.

Referenced files: 4

View saved version →

---
name: game-asset-vendoring
description: Search, verify, migrate, and safely admit canonical asset packages into local game projects. Use for asset catalogs, license gates, package integrity, project vendoring, lock receipts, and local preview launch; not for generating paid-provider assets.
---

# Game Asset Vendoring

Treat the canonical package as the supply-chain boundary. Use `game-dev` locally; do not copy loose provider downloads directly into a game project.

Read [references/commands.md](references/commands.md) for the supported catalog, migration, launch, and admission commands.

## Workflow

1. Locate the package through the catalog or an explicit path. Verify its closed hash roster and receipt before assessing suitability.
2. Review the recorded license, provenance, category, version, source digest, validation policy, and validation result. Unknown licenses and failed validation remain blockers unless the user explicitly accepts the named exception.
3. Dry-run `vendor admit` against the exact project and destination. Show the resulting path, blockers, and exception flags without writing.
4. Obtain explicit confirmation for that admission. Do not broaden it into permission to install an adapter, edit engine metadata, import through a GUI, or run the game.
5. After admission, verify the copied package and retain the project lock receipt. Report that vendoring proves copied-byte integrity, not engine import, GPU rendering, runtime behavior, or artistic approval.

Use migration only for a legacy Game Development Studio output workspace. Preview launch is also plan-first; executing Finder, Quick Look, or Blender is a separate external action.

## Safety boundaries

Never overwrite a different package, follow a destination symlink outside the project, suppress a license blocker silently, or claim an engine-native asset layout without project-specific integration evidence. Adapter templates are outside this skill unless the user separately requests game-harness setup.

Referenced files: 4

View saved version →

---
name: game-development-studio
description: Route local game-asset production, package vendoring, offscreen render diagnosis, and bounded performance work through the game-dev CLI. Use only when a game-development request explicitly spans two or more of these workflows, needs a cross-workflow handoff, or asks for Game Development Studio orchestration; do not activate for unrelated development or general creative work.
---

# Game Development Studio

Use the local `game-dev` CLI as the durable, inspectable interface shared by
developers and coding agents.

## Route the request

- Use `$game-asset-production` for provider jobs, mesh inspection or normalization, PBR preparation, and canonical asset packages.
- Use `$game-asset-vendoring` for catalog search, license and hash checks, migration, and explicit admission into a game project.
- Use `$game-visual-debugging` for game adapters, windowless captures, structured telemetry, raster statistics, semantic attachment diffs, and heatmaps.
- Use `$game-performance-optimization` for metric summaries, run comparisons, and bounded optimization goals.

Read [references/routes.md](references/routes.md) when a request crosses workflows or needs an exact handoff.

## Shared operating contract

1. Confirm the CLI with `game-dev --version`, then inspect `game-dev capabilities --json` and `game-dev doctor --json` when environment readiness matters. Provider execution requires `game-dev` 1.0.2 or newer.
2. Prefer `--json` for one result and `--jsonl` for provider, Blender, capture, or other long-running work. Consume only the documented `game_dev.*` envelopes.
3. Never ask for, accept, reveal, or configure a provider credential in the conversation. It must already be configured by the account holder in a user-controlled local mechanism. Keep credentials out of arguments, request files, logs, screenshots, and receipts. Use `game-dev credentials status --json` to check only configured or missing without reading values.
4. Plan before mutation. Treat every command that can create, replace, delete, download, or modify a file—or launch a process—as an unexecuted plan until the user authorizes that exact invocation with its resolved inputs and destinations. This includes normalization, USDZ preview generation, package construction, adapter installation, project vendoring, launch execution, catalog rebuilding, and optimization-state updates. A command without a `--confirm` flag still requires this conversation-level authorization.
5. Keep authorizations independent: paid-provider spend, project execution, GPU capture, and hardware-performance measurement are separate decisions. Never persist or replay their flags as standing permission.
6. Verify every produced package or run bundle before using it downstream. Preserve receipt paths, manifest digests, run IDs, provider job IDs, prompts, licenses, and source provenance.

If `game-dev` is unavailable, report the missing local CLI and the blocked workflow. Do not install software, change credentials, solicit a key, or substitute an unrequested remote service.

## Evidence boundary

Report only what the returned receipt proves. Static inspection is not Blender, GPU, pixel, performance, signing, or human-review evidence. A decoded raster or adapter-reported GPU flag is useful diagnostic evidence, but it is not a human visual judgement or independent proof of hardware completion.

Referenced files: 4

View saved version →

---
name: game-performance-optimization
description: Summarize sealed game-run telemetry, compare baseline and candidate metrics, and execute bounded code-optimization goals with explicit path and iteration limits. Use for measurable performance work after a reproducible adapter scenario exists; not for visual diagnosis without a metric.
---

# Game Performance Optimization

Use `game-dev` run bundles as the measurement boundary. Begin only after a reproducible scenario emits the requested metric with a stable unit.

Read [references/optimization-loop.md](references/optimization-loop.md) for goal requests, commands, and comparison rules.

## Workflow

1. Verify the baseline run, summarize its metrics, and choose one named metric, statistic, unit, direction, and target. Do not optimize a proxy without explaining why it represents the user's outcome.
2. Confirm scene, seed, workload, build mode, renderer path, hardware, power state, and instrumentation are comparable. Hardware timings require the separately authorized evidence path; arithmetic over unadmitted values is not hardware-performance proof.
3. Create a dry-run goal with a narrow source-path allowlist and a fixed maximum iteration count. Exclude repository metadata, dependencies, build output, run bundles, and broad project roots.
4. After explicit confirmation, make one bounded candidate change, run relevant non-performance tests, capture one candidate, verify it, and evaluate it once.
5. Compare the target metric and inspect correctness signals, raster evidence, errors, and secondary regressions. A numeric improvement does not establish which change caused it.
6. Stop when the target is met, the iteration budget is exhausted, the measurement becomes incomparable, correctness regresses, or progress requires broader authority.

Do not reuse a candidate run as another iteration, silently widen allowed paths, change the target mid-goal, or turn a bounded goal into an open-ended autonomous loop.

## Evidence boundary

The summarizer proves deterministic arithmetic over sealed telemetry and profile fields. It does not prove timer quality, GPU synchronization, hardware comparability, statistical significance, or causal attribution. Report the adapter's measurement claims and the harness's admitted evidence separately.

Referenced files: 4

View saved version →

---
name: game-visual-debugging
description: Diagnose game-rendering problems with declarative local adapters, windowless captures, structured telemetry, semantic render attachments, sealed run bundles, and deterministic raster comparisons. Use for visual bugs or renderer regressions where screenshots alone are insufficient.
---

# Game Visual Debugging

Use `game-dev` to turn a game-owned capture command into a sealed, comparable evidence bundle. The adapter remains declarative; the game owns its build, renderer, GPU synchronization, and capture implementation.

Read [references/capture-workflow.md](references/capture-workflow.md) for commands, useful attachment types, and interpretation rules.

## Workflow

1. Inspect the project's `.game-dev/adapter.json` and list scenarios. Do not install a packaged adapter unless the user asks for that exact project write.
2. Plan the smallest scenario that can reproduce the defect. Validate contracts and preflight on CPU before requesting a GPU scenario when the adapter provides those stages.
3. Show all required authorizations. Project execution requires `--confirm`; GPU and hardware-performance capabilities require separate flags. Do not treat prior runs as standing permission.
4. Execute once, verify the closed run roster, and preserve stdout, stderr, capture manifest, telemetry, profiles, native evidence, and hashes.
5. Analyze color plus any available depth, normal, object-ID, material-ID, motion, and overdraw attachments. Use semantic object regions to localize changes that a full-frame score would hide.
6. Compare a sealed baseline and candidate from the same adapter scenario. Correlate raster deltas with telemetry events and profile measurements, then inspect the implicated code or resources.
7. State hypotheses and discriminating next captures. Do not label an artistic defect as diagnosed merely because a metric changed.

Prefer bounded diagnostic shots over large galleries when narrowing a bug. Once the defect is localized, use the smallest deterministic regression capture the game can retain.

## Evidence boundary

The harness proves process status, schema validation, decoded raster statistics, and sealed hashes. GPU completion and hardware timings remain adapter-reported unless joined to native evidence. Heatmaps and semantic deltas are machine measurements, not human visual review, artistic intent, or causal proof.

Referenced files: 4