Cutting Release Cycles for Xiangqi with a Claude Code Workflow

Introduction

Xiangqi is an online Chinese Chess platform serving more than 100,000 games a day, with about 4.17 million moves played daily across fifteen backend pods. It earns through advertising and premium subscriptions in the Hong Kong, Vietnamese, and Chinese markets, and it is a joint venture between BVS and Arbisoft.

As the product matured, there was still no shared way of working with AI and no written path from ticket to release, so much of each ticket was handled by hand. Nobody asked for an AI rollout, but the delivery problem was Arbisoft's to solve, and that's where our engineering team stepped in.

The Challenge

Xiangqi's engineering ran on solid tooling, but the way work moved through it was manual and inconsistent:

• No shared AI workflow: Developers pasted Jira descriptions into a chat window and did the analysis, planning, pull request text, and board updates by hand.
• Inconsistent output: Two engineers working the same kind of ticket produced different artefacts, so nothing was comparable from one ticket to the next.
• Slow theme delivery: Themes are products BVS sells, and a new theme on two or three pages was taking two weeks.
• Four very different codebases: A large React single-page app, a Flask and Socket.IO backend on EKS with two Redis backends, a GitOps repository of ArgoCD, Helm, and Terraform, and a Playwright test suite meant one uniform setup would fail.

The Approach

We built a written, repeatable ticket-to-PR workflow on Claude Code that any engineer could follow and improve, committed to each repository and shared across all four teams from March 2026:

What We Built

• A ticket-to-PR workflow: The chain runs pick, start, analyse, plan, plan review, implement, self-review, pull request, review comments, and record, with one Claude Code command per step. Commands hold the sequence and skills hold the rules, so changing a rule changes every command that uses it. Every non-trivial ticket produces a plan committed with the code, and opening a pull request publishes that plan to Confluence, where 100 pages are now live.
• Context that knows each codebase: Each repository carries its own committed CLAUDE.md, coding standards, and settings, changed through pull request review like code. The backend file holds the real production topology, added after Claude reasoned about production from a local docker-compose file; once it was in place, that class of wrong answer stopped. Each line of its NEVER list came from a real incident.
• Themes built in days: We proposed replacing page-by-page styling with design tokens, which BVS had not asked for, and shipped the refactor as 20 tickets. On top of it we built two subagents: theme-creator generates the colour ramps and solves the icon-recolour CSS filters with an SPSA optimiser, and board-creator wires raw art into the background, grid lines, piece discs, and positioning tokens. One /add-theme command runs both, so engineers only add files to one directory.
• Skills each team wrote for itself: Backend engineers wrote six domain skills covering board geometry and FEN, the UCI engine protocol, AXF adjudication rules, bot behaviour, trade detection, and test patterns, so no session has to re-explain how a cannon captures. DevOps built helm, security, and infra guardian subagents, and QA built a Playwright and Cucumber flow where a page-inspector agent extracts verified locators before any test is generated.
• Connected tools that read freely and write narrowly: Eight MCP connections reach Jira and Confluence, Figma, Sentry, PostHog, SonarQube, Kubernetes, AWS, and New Relic, each authorised per developer, so Claude Code reaches only what that developer already can. Jira's whole write surface is two status transitions and one field, and GitHub runs through each engineer's own CLI login, so every action is attributed to a person.
• A shared plugin pinned by version: The frontend and backend copies of the same commands had drifted apart, down to different pull request title formats. We moved them into one versioned plugin, so an upstream change reaches a team only when someone bumps the version in a reviewed commit. Its setup command detects a new team's stack and checks their Jira settings live, and other Arbisoft teams have since installed it.
• Guardrails and verification: Committed deny rules block reads of secret files and cloud credentials and refuse destructive commands such as force pushes and hard resets, and we tested them in a live session. Every change, AI-assisted or not, goes through a pull request with SonarQube, and done means a verification command ran and its output was seen. A shared failure log turns each mistake into a rule every team inherits.
• Delivery visibility for BVS: Each pull request carries an AI contribution estimate from a fixed rubric, so tickets months apart are comparable. A delivery dashboard reads Jira and GitHub and is open to BVS's product manager, who can see throughput, planned versus delivered work, and AI contribution without asking us.

The Outcome

We compared two equal 11-week windows in 2026: 31 March to 16 June, before the workflow, and 1 July to 17 September, after it.

• Faster releases: Releases went from every 3.7 weeks to every 2.2 weeks, and no gap between releases in that window was longer than 2.9 weeks.
• Smaller, more frequent increments: Tickets per developer per week rose from 2.38 to 2.78, about 17% higher, as work was split into smaller pieces and shipped more often.
• Themes in days: Every theme since the first one on the new architecture has been built in under a week, against two weeks before. Seven themes shipped between June and September, from Dragon to Chu-Han Rivalry, and we credit the token refactor and the agents together.
• AI contribution on every ticket: Recording went from 15 of 131 tickets to all 155, because the pull request command adds it automatically. 119 of those tickets recorded AI assistance, at a mean of 81%.
• Defects caught before review: Self-review runs before anyone else sees the diff; on one documented ticket it caught four defects before any reviewer did.
• Product work shipped: The subscription and monetisation system reached production in September, including changes we proposed, and two root-cause investigations closed long-standing production problems.

Value Delivered

The workflow gave both sides of the venture something they could use:

• BVS gets sellable themes in days rather than weeks
• Players get a release about every two weeks instead of almost every four
• Every engineer follows the same written path from ticket to pull request
• Each ticket leaves a plan, a pull request with AI contribution, and a Confluence page
• Claude Code reaches only what each developer can already reach, with destructive commands blocked
• Each team extends its own tooling without waiting on the person who built it

Xiangqi's engineering now runs on one shared, versioned Claude Code workflow that every team owns and improves.

Technology Used

The tools and setup behind Xiangqi's workflow:

• AI tools: Claude Code in the terminal and the VS Code extension, and the Claude desktop app
• Workflow: 14 commands, 13 skills, theme, guardian, and QA subagents, committed CLAUDE.md files and coding standards, a failure log, and a versioned shared plugin
• Integrations: MCP servers for Jira and Confluence, Figma, Sentry, PostHog, SonarQube, Kubernetes, AWS, and New Relic, with GitHub through the gh CLI
• Xiangqi's stack: React single-page app, Flask and Socket.IO backend on Amazon EKS with Redis, ArgoCD, Helm, and Terraform, and Playwright and Cucumber tests