I used AI to wire design, math, art, audio, frontend, and analytics into one working pipeline.

SKILLS — Core capabilities

1. 01AI collaboration & agent workflows (Claude Code Skills, MCP servers, pipeline design)
2. 02Cross-domain integration (design, math, art, audio, frontend, analytics)
3. 03Architecture principles & hard boundaries (machine-verifiable contracts, CI-enforced checks, permission and decision limits)
4. 04Game frontend & rendering (Cocos Creator, PixiJS 8, Spine, GLSL, texture and memory budgeting)
5. 05Web engineering (TypeScript, Svelte, Vue / React, Nuxt / Vite / Next.js, Electron)
6. 06Release & deployment (four environments, Jenkins pipelines, automated triage and deploy verification)
7. 07Data analysis & ops support (ClickHouse-family warehousing, re-runnable query and triage flows)

OUTCOMES

Six areas, each backed by tooling that actually runs. Happy to go deeper on any of them.

• 01 A semi-automated game production line

  Broke building a game into six stages—design, math, art, audio, frontend, post-launch analytics—built agent-callable tooling for each, and made every stage feed the next. The design rules document is the single source of truth and flows downstream into a verifiable math contract; art and audio both consume the same theme definition, so what you see and what you hear belong to the same game; the frontend builds against the same event structure. This used to be six roles working separately and syncing in meetings. With the spec in place, an art-free demo build is now generated from assertions in a few hours; a reskin takes about a day, bounded by image-generation volume. End to end, a reskin used to cost art and frontend around a week each—it now takes about two days combined.

• 02 Frontend SDK and hands-on rendering

  Contributed to a Svelte 5 + PixiJS 8 slot-game frontend SDK—a monorepo of 14 game apps and 29 shared packages—as its single largest contributor (roughly 60% of commits). The architecture is event-driven: the server returns a round as a sequence of events that the client replays to drive animation, which makes a round reproducible and independently testable. Reels, cascading, free spins, and bonus rounds are all shared modules. The low-level work continues alongside it: cut texture VRAM on a live title by 18% (atlas consolidation, halved mask and VFX resolutions, resolution suffixes—logical sizes and rendering code untouched), and wrote the Spine 3.8 → 4.2 converter that repaired three silent data-loss bugs in the runtime upgrade.

• 03 Art generation: turning "consistent style" into an executable spec

  16 generation skills covering theme proposals, a visual style guide, batch image generation, character poses, sprite sheets, autotile terrain, parallax backgrounds, and UI components. The key design decision: produce the style guide first, then inject it into every downstream prompt—a batch drifts as it grows, and that spec is the only thing that holds it together. The same theme definition also feeds audio generation, so what you see and what you hear come from one source. The reskin path is settled practice now—it does not need me watching it.

• 04 Math: turning a design document into a machine-verifiable contract

  A math pipeline covering 40+ titles. It expands the design rules into a mechanics matrix, interrogates every ambiguous cell until it is pinned down, and emits a machine-verifiable contract. Every batch of computed results then has to clear a set of hard checks—gaps in the matrix, whether a declared mechanic actually appears in the output, field and behaviour assertions—and nothing ships until it passes. Those checks are wired into CI and are independent of which model produced the output, or how many times it has been replaced—the boundary sits outside the model, so drift cannot move it. One line was drawn deliberately: the pipeline runs on its own, but the final call on a payout table stays with the game designer. It now operates without me—I go back in only when the spec itself has to change.

• 05 Putting live operations data within reach of an agent

  Built an analytics MCP server that exposes the data warehouse as 16 agent-callable tools—revenue and partner rankings, period-over-period comparison, player behaviour analysis, plus single-round replay and statistics for specific games. On top of it sit 5 analysis agents and a daily triage routine that chains "check revenue → find anomalous games → shortlist suspect players → investigate → produce the report" into one command. The engineering underneath is deliberately defensive: read-only access, query timeouts, and row caps, so an agent cannot take the warehouse down. Ops and engineering now align on the same re-runnable queries instead of one-off lookups and back-and-forth over chat.

• 06 Delivery governance and automated issue fixing

  Own CI/CD and four-environment releases (DEV / STG / REL / PROD) across 40 game types and 80+ reskinned variants, with deployment, backup verification, version alignment, and release reporting consolidated into one toolset—anyone can confirm "is it live, and on which version" without asking me. Issue handling runs on the same logic: QA files a ticket, an MCP server picks it up, and the agent pulls that project's context and past fixes from a knowledge base spanning 90+ repositories, produces a diagnosis and proposes a fix; an engineer takes it from there. The value is not full autonomy—it is that when the same class of issue recurs across projects, the diagnosis and the fix carry over, cutting implementation time several-fold.