SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsgame-studio-harness

game-studio-harness

Design & creation

View repository

Updated 10-15 17:25

About this skill

Game Studio Harness

Producer-orchestrated 5-agent team for full game production cycles, following the bmad-gds method (intake brief → one operating mode → coordination artifact → specialist routing → milestone thread) with numeric quality gates. The harness is a standing structure: cycles repeat until the game ships and keep repeating for live operation.

Read references/quality-gates.md, references/stage-cycle.md, and references/artifact-contract.md before creating a run. Gate thresholds in references/quality-gates.md override any paraphrase in this guide.

When to use this skill

  • Start a new game production cycle from an idea, GDD, prototype, or existing build
  • Resume an in-flight cycle (read _workspace/current/production/task-manifest.md first)
  • Run a stage-gate review (G1–G8 verdicts) on the current build
  • Reprioritize when playtest feedback, defects, and milestone pressure collide
  • When running the game production/balance/monetization/QA cycle as a single team

Route narrower packets to their own skills instead: raw build/log failure → game-build-log-triage; profiler capture → game-performance-profiler; feedback-only triage → game-demo-feedback-triage; store-page/launch ops → steam-store-launch-ops; pre-production ideation → bmad-idea.

Team

Role Template Owns
game-production-director templates/agents/game-production-director.md Intake, task manifest, gate verdicts, arbitration, retrospective
game-designer templates/agents/game-designer.md Balance sheet, combo matrix, core loop, novelty scorecard, worldview, presentation spec, trend surveys
game-pm templates/agents/game-pm.md Revenue map, reward bands (comeback ≤30%, free/paid parity 10–20 sessions, win-rate delta ≤5%p), negotiation record, revenue forecast
game-programmer templates/agents/game-programmer.md Architecture contract, perf budget (p95 ≤16.7ms, input ≤100ms), movement-path optimization, tech verification, telemetry, defect responses
game-qa templates/agents/game-qa.md Archetype rotation (≥5 types), exploit register, benchmark survey, gate measurements, defect/regression registers

Communication topology: director assigns and gates; QA broadcasts every exploit/discovery to ALL agents with a feedback request; designer↔PM negotiate reward/revenue couplings in a signed record; programmer answers every defect within the cycle (fixed or deferred + reasoning).

Instructions

Step 0: Preparation

Why: every artifact must be traceable, and the workspace has exactly one live folder.

  1. Create _workspace/current/{intake,design,pm,engineering,qa,ops,ui,production,messages,retrospectives}/ at the target repo root. Do not create a dated run directory — run-id ({YYYYMMDD}-{cycle-label}) is a value carried inside the documents and becomes a directory name only at archive time (_workspace/archive/{run-id}/).
  2. If resuming, read _workspace/current/production/task-manifest.md and the last retrospective; enter at the recorded stage instead of Stage 1.
  3. At cycle close, git mv superseded lane material into _workspace/archive/{run-id}/. Never delete a _workspace/ artifact.

Step 0.5: Write the repository rule file

Why: the harness only governs the session that runs it. Everything the studio learns — lane ownership, the engine boundary, which generator owns which asset class, the git-safety protocol — evaporates the moment this session ends unless it is written where every future session must read it.

  1. Copy templates/repo-rules.md to the target repo's agent instruction file (CLAUDE.md for Claude Code; mirror to AGENTS.md for Codex/Gemini/OpenCode as a pointer, not a second copy — two contracts drift, and a drifted contract is worse than none).
  2. Resolve every {PLACEHOLDER} against the real repository. A surviving placeholder is a defect. Delete sections that do not apply: a rule nobody follows teaches future sessions that rules are optional.
  3. State the reason beside any rule whose violation is tempting or whose cost is invisible. Never rename X gets ignored; renaming X orphans every existing player's save data gets obeyed.
  4. Re-derive it at each cycle close, not just at run creation. The rule file is a cycle artifact — when current/ gains a lane, when a generator is replaced, or when a hard-won invariant is discovered, it is stale until updated.

Step 1: Materialize the team

Why: agents must be file-based so sessions can reuse them.

  • Claude Code with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1: copy templates/agents/*.md into the target repo's .claude/agents/ (skip files that already exist and match), then use TeamCreate + SendMessage + TaskCreate/TaskUpdate.
  • Any other runtime (Codex, Gemini, OpenCode) or teams flag off: run the same roles as sequential sub-agents in the phase order of references/stage-cycle.md; peer messages become numbered files in _workspace/current/messages/{seq}-{from}.md.

Step 2: Intake (director)

Normalize the request into intake/production-brief.md (bmad-gds schema: game_type, team_shape, engine, current_stage, next_public_beat, source_packet, main_constraint, main_question). Choose ONE operating mode for the cycle and state the next public beat explicitly.

Step 3: Run the 3-stage operating cycle

Follow references/stage-cycle.md exactly. Summary:

  • Stage 1 — Concept, presentation, animation, resources, core build: designer (concept + worldview + numeric skeleton + trend survey via the survey skill + core-loop candidate + presentation spec) ∥ PM (revenue-point draft) ∥ QA (benchmark survey + test plan + archetype set). Then designer↔PM negotiation round 1, then programmer builds core loop + presentation/animation + resource manifest + telemetry draft. Gate: G7 draft, G1 draft, G6-ops draft.
  • Stage 2 — Balance, core-loop stability, novelty development: QA exploit hunt across archetypes → designer retune → PM reward-band adjustment → negotiation round 2 → programmer applies data-only changes → QA re-verification. Gate: G2, G3, G5, G7 final, G8.
  • Stage 3 — Ops stability and play impact (direction/scenario/effects): programmer perf+memory+movement optimization and ops hardening ∥ designer+programmer presentation/scenario/effect impact pass ∥ QA full regression + immersion scoring ∥ PM revenue-consistency forecast. Gate: G4, G6 final, G1 final.

Gate verdicts are PASS / FIX (≤2 revision loops) / REDO (previous stage). An open S1 defect or missing evidence blocks any PASS.

Step 4: Cycle close (director)

  1. Write retrospectives/cycle-{n}-retrospective.md: per-gate measured values, unresolved risks, and the next-cycle entry decision (Stage 1 concept shift vs Stage 2 retune).
  2. Re-derive the repository rule file (Step 0.5) if this cycle changed a lane, replaced a generator, or discovered an invariant worth enforcing.
  3. git mv the superseded lane material into _workspace/archive/{run-id}/. current/ keeps only what the next cycle carries forward; nothing leaves _workspace/.

The cycle loops — the studio is a standing structure, not a one-shot pipeline.

Step 5: Error handling

Scenario Response
Agent timeout Retry once → mark task failed, continue partial, flag in gate review
Data conflict Log conflicts.md; prefer newer measurement; director arbitrates numerically
Missing output Gate cannot PASS; warn in review
Messaging failure File-based fallback via messages/

Examples

Example 1: New cycle from an idea

Input: "Start the game production cycle with a dark fantasy RTS idea" Expected: run-id created, production brief written, team materialized, Stage 1 tasks assigned; designer trend survey and QA benchmark survey run via the survey skill; cycle ends with retrospective + G1–G8 gate table.

Example 2: Stage-gate review on existing build

Input: "Run a stage gate review on the current build" Expected: QA measures G1–G8 on the build, director issues per-gate PASS/FIX/REDO verdicts with evidence paths, FIX items become manifest tasks.

Example 3: Balance emergency

Input: "QA found an infinite-combo exploit, re-enter the cycle" Expected: enter at Stage 2 Phase 2a with the exploit register pre-seeded; designer retune, PM reward-coupling check, programmer data-only change, QA re-verifies the band before the gate closes.

Best practices

  1. One operating mode per cycle — mixing concept work and launch ops in one pass weakens both.
  2. Numbers gate everything: no adjective ever passes a gate (references/quality-gates.md).
  3. Surveys before invention: designer trend survey and QA benchmark survey are Stage 1 prerequisites, not optional garnish.
  4. Preserve _workspace/ artifacts — they are the studio's memory across cycles. Archive, never delete.
  5. The rule file is the studio's only durable output. A harness run that ships a build but leaves no contract has taught the next session nothing.
  6. Keep the milestone thread: every task names the next public beat it serves.
  7. QA broadcast discipline: every exploit/discovery goes to all agents with an explicit feedback request — QA sense is the studio's shared sense.

References