Augmented Workflows — Mark Smalley

The Numbers

16 Days, One Ecosystem

In May 2026, I built Moddable Games from zero to production: a complete open-source games studio with two game engines, 37 game families, 16 AI-callable MCP tools, Consumer SDKs, and a 2,974-page rulebook pipeline. 535 commits across 10+ repositories in the initial 16-day sprint, all of which can be audited, forked or downloaded from GitHub. Read the full story.

The figures below are the state at the end of that sprint. Since then the two engines have been consolidated into a single micro-kernel, and the ecosystem now stands at 204 playable variants across 10 families, 89 MCP tools, and 9,765 rulebook pages. See where it is now.

535

Commits shipped

Chess variants

MCP tools

Hexmap games

2,974

Rulebook pages

169

JS modules

How It Works

The Workflow

Architecture First

Every project starts with plugin architecture, data separation, and API-readiness. I design for composition, not for the first feature, but for the 71st. The chess engine's registerVariant() pattern means adding variant #72 takes minutes, not hours.

AI as Force Multiplier

AI handles the volume work: generating variant implementations, producing documentation, writing test coverage. I handle the architecture, the judgment calls, and the quality bar. The ratio is roughly: I design the system once, then ship 71 variants through it.

Cross-Project Consistency

Global rules propagate across all repos automatically. Cache busting, link behaviour, CSS architecture, data patterns, versioning: solved once, enforced everywhere. Changes in one project trigger audits across siblings.

Visual Verification Loop

Every PDF page is rendered and inspected. Every CSS change is screenshot-verified. Every embed is tested across contexts. Nothing ships without visual sign-off. I iterate until every page passes.

Ship Continuously

No staging branches, no sprint ceremonies, no deployment pipelines. Push to main, GitHub Pages deploys, version bumps bust caches. The entire ecosystem deploys in seconds. 535 commits in 16 days means shipping roughly every 40 minutes, including three days spent camping in the Yorkshire Dales, deploying over 3G.

Autonomous Pipeline

Issues aren't a backlog. They're a typed queue. A structured pipeline across six repositories uses labels to route work through research and implementation agents running on cloud infrastructure — no terminal open, no machine running. Research agents investigate and scope. Implementation agents branch, build, and merge. I review the diff. The system processes work without being told to look.

Philosophy

Principles That Scale

No Frameworks

Vanilla JS, zero build step, zero dependencies. Every project runs on any static server. The constraint forces clean architecture rather than hiding complexity behind abstractions.

Data Drives Everything

Content lives in JSON. Pages are templates that consume data. Adding a new game, variant, or article means adding a JSON entry, not touching markup, styles, or deployment.

Plugin Over Config

Extension via composition, not configuration. The chess engine doesn't have a "variant config schema"; it has hooks. Variants compose behaviours. The system grows without the core changing.

Progressive API-Readiness

Every project shapes its data like API responses from day one. When it's time to add a real backend, the swap is a URL change, not a rewrite. Already proven across 6 repos.

Solve at Source

Don't patch symptoms. If bullet alignment is broken, fix the CSS shape, not per-element overrides. If data is inconsistent, fix the single source of truth, not the downstream copies.

Auditable by Default

Public repos. Semantic commits. Version-stamped deployments. Every claim on this page can be verified by reading the git history. Transparency is a feature, not a vulnerability.

How It Works Now

The Moddable Layer Cake

The two engines above were the May 2026 shape. What replaced them is a four-repository stack where each layer has exactly one job and depends only on the layer below it. Nothing reaches sideways or upward. The reframing that made it possible: if content is structured data rather than code, the rendering layer holds no knowledge, so it can be thrown away and rebuilt without losing anything.

Rules

rules.moddable.games

Pure structured content and zero code. 46 games, 296 variants, 458 oracle tables, and 3,385 entities as markdown and YAML frontmatter, behind a machine-readable API.

Engine

engine.moddable.games

Resolves rule definitions into playable states with as little code as possible. 204 playable variants across 10 families over six topologies, covered by 6,527 tests. A new variant is a frontmatter file.

Tools

tools.moddable.games

The only private repository, and the value layer. 89 MCP tools, a REST API, a JavaScript SDK, and embeddable widgets wrapping the engine into services: puzzle generation, AI opponents, board rendering, oracle composition.

Web

moddable.games

A static site generator consuming tools through iframes and API calls. All content in JSON and markdown, zero game logic. Disposable by design, which is the point.

Each layer is independently deployable on its own subdomain. The engine does not need the web to function, and an AI agent can play a full game through MCP without a browser. Read the full architecture write-up.

Try It

Live Engine Demos

These run on the stack described above, embedded through the same Tools SDK that moddable.games uses. The family and variant lists are fetched live from the Tools API rather than typed into this page, so everything the engine can play is here.

Hex maps are generators rather than rule variants, so they sit outside the play API: