Building a Human-vs-AI UNO Game with Uncle Bob's SwarmForge Four-Pack
One agent. Four disciplined handoffs. One complete UNO game.
Specification, implementation, validation, and architecture closure become a sequential CTRL NODE graph.
Uncle Bob's SwarmForge organizes AI-assisted software work as disciplined handoffs between specialized roles. Its four-pack workflow follows a compact loop: specifier → coder → refactorer → architect → specifier. The specifier turns intent into approved Gherkin behavior, the coder implements tested slices, the refactorer improves the code without changing behavior, and the architect reviews structure and closes the loop. See the SwarmForge README for the original workflow.
This experiment translates that idea into a CTRL NODE graph. Instead of launching four independent terminal agents, we use Single Agent mode and encode each responsibility as a separate task. Every stage reads the previous handoff, performs one bounded responsibility, and writes the context required by the next stage.
The product is a browser-based UNO game for two players: one human and one machine-controlled opponent. The human must be able to choose cards, draw, select a color after a Wild, and declare UNO. The machine must make strategic decisions rather than choosing legal cards at random.
Step 1 — Describe the Four-Pack workflow
Open Graphs & Workflows → New, choose Create With AI, and keep Agent Mode set to Single Agent. The graph will use one selected execution agent while separating specification, implementation, validation, and finalization into four sequential tasks.
Create a complete browser-based UNO game using Uncle Bob's SwarmForge four-pack methodology. Use four sequential stages: design, build, AI validation, and final corrections. The human must choose cards and declare UNO; the machine opponent must play strategically.
Here is the prompt used to generate the graph:
Create a complete browser-based UNO game using Uncle Bob's SwarmForge four-pack methodology.
The game has two players: Player 1 is a machine-controlled opponent that must use the rules intelligently, and Player 2 is a human. During the human turn, the player must be able to choose which card to play, draw a card, choose a color after playing a Wild, and declare UNO.
Create a sequential Single Agent graph with four stages:
1. Design the architecture, complete UNO rules, AI strategy, visual system, and an AI-controlled HANDOFF.md.
2. Build the complete HTML/CSS/JavaScript game from that handoff.
3. Validate rules, interaction, AI behavior, and visual quality by reading and reasoning about the source code, producing validation-report.md.
4. Fix every reported issue, polish the game, and write HANDOFF-COMPLETE.md.
Use the SwarmForge handoff protocol as inspiration, adapted so each CTRL NODE task passes a complete AI-controlled handoff to the next task without human approval between stages. The game must run by opening its HTML directly and must not depend on external visual assets or unavailable sh/go tooling.
The important constraint is the handoff chain. Each task owns one quality boundary and must leave durable written context for the next task. The graph remains sequential because implementation depends on design, validation depends on implementation, and finalization depends on the validation report.
Step 2 — Review the AI proposal
Choose the execution agent and select Generate Graph. CTRL NODE returns a four-task proposal before anything is created or executed.
The proposal adapts Four-Pack to the available environment:
- Architecture and rules design combines specification and up-front architecture.
- Game implementation builds the playable browser game from
HANDOFF.md. - AI validation of rules and gameplay replaces unavailable shell or Go validation tools with a structured source review.
- Final corrections and handoff closure applies every finding and produces the completion handoff.
This is not a literal reimplementation of SwarmForge. It preserves the useful discipline — explicit roles, bounded work, durable handoffs, and a final architecture gate — while expressing it as a CTRL NODE workflow.
Step 3 — Inspect the generated Designer graph
Choose Create Graph after reviewing the proposal. The result is an editable linear graph with four connected tasks assigned to the same Single Agent execution template.
The graph deliberately stops at Designer in this article. The following sections document exactly what each generated task is expected to do; execution results will be added after the run is complete.
Generated task instructions
1. Architecture and rules design
Design the complete architecture of a two-player UNO game in HTML, CSS, and JavaScript. Player 1 is a strategic machine opponent and Player 2 is a human who can select cards, draw, choose a Wild color, and declare UNO.
Define the project file structure; the deck and card model for colors, numbers, Skip, Reverse, Draw Two, Wild, and Wild Draw Four; the turn state machine; legal-play and draw rules; victory detection; and the penalty for failing to declare UNO. In a two-player game, specify that Reverse behaves like Skip.
Design the machine strategy: legal-card priorities, when to retain Wild cards, how to choose the dominant color in its hand, and when to use Skip, Reverse, or Draw Two to block the human. Define a responsive visual system with an UNO-inspired palette, typography, a two-player table layout, and CSS/SVG animations without external assets.
Because shell and Go tools are unavailable, define an AI-driven validation path. Finish by writing HANDOFF.md, following the intent of SwarmForge's handoff protocol, with all architecture decisions, rules, and implementation requirements needed by the build stage.
2. Game implementation
Read HANDOFF.md and treat it as the mandatory specification. Implement the complete UNO game in HTML, CSS, and JavaScript, either as one self-contained index.html or a minimal linked file set.
Include deck creation and shuffling, initial dealing, complete turn logic, all special cards, human card selection, Wild color selection, drawing, UNO declaration, victory handling, and a non-trivial machine strategy. The AI should reduce its hand intelligently, retain Wild cards for useful moments, select its most common color, and use action cards to disrupt the human when appropriate.
Create a polished responsive interface with dimensional cards, gradients, smooth deal/play/draw animations, and clear current-turn and game-state feedback. The game must run by opening the HTML directly. Update HANDOFF.md with the final file structure, implementation decisions, and any open points for validation.
3. AI validation of rules and gameplay
Act as the validation tool that SwarmForge would normally invoke through scripts. Read the previous HANDOFF.md and all generated source code; validate by tracing and reasoning about the implementation rather than executing it.
Check turn order, Reverse-as-Skip behavior for two players, Skip, Draw Two, Wild, Wild Draw Four, forced drawing, victory detection, UNO declaration and penalties, human interactions, edge cases, strategic machine decisions, responsive presentation, and animation coverage.
Write validation-report.md with a clear PASS/FAIL result for every criterion and a concrete correction list. End with an AI-controlled handoff telling the finalization stage exactly what must change.
4. Final corrections and handoff closure
Read validation-report.md and correct every failed or incomplete rule, interaction, AI behavior, and visual requirement. Recheck each correction against its validation criterion by reading the resulting code.
Polish style consistency, animation quality, readability, turn feedback, UNO feedback, and Draw Two/Draw Four events. Confirm that the final game runs directly from its HTML without shell or Go tooling.
Finish by writing HANDOFF-COMPLETE.md. Summarize the complete AI-to-AI chain — design → build → validate → finalize — and confirm that the UNO game is complete, playable, and ready for delivery without an additional human approval step.
Step 4 — Execute the architecture and rules design
The first node did not write application code. It produced the specification that every later node must follow, then handed that specification to Build.
The run created five aligned documents:
docs/ARCHITECTURE.mddefines the file structure, 108-card data model, turn state machine, and module boundaries.docs/RULES.mdis the normative source for legal plays, drawing, reshuffling, victory, and UNO penalties.docs/AI_STRATEGY.mddescribes a scored decision model for retaining Wild cards, selecting colors, reducing the AI hand, and disrupting the human player.docs/VISUAL_SPEC.mddefines the responsive table, palette, typography, cards, and CSS/SVG animations.HANDOFF.mdrecords the decisions, acceptance criteria, risks, and exact work expected from Build.
The architecture settled several details that could otherwise become ambiguous during implementation. Reverse acts as Skip in a two-player match. Draw cards cannot be stacked. A player must draw only when no legal move exists. The discard pile is recycled when the draw pile is exhausted, preserving its top card. The AI always starts, while the opening discard is always a number card so the match begins from a predictable state.
UNO handling is intentionally asymmetric. The machine declares UNO automatically; the human receives a five-second window and draws two cards if the declaration is missed. A winning card ends the game before any action-card penalty is applied. Wild Draw Four challenges were excluded from this MVP and documented as a deliberate simplification rather than an implementation defect.
The task log reports that all five documents were audited line by line and found internally consistent. No files were changed during the verification pass: the design package already covered the complete requirement and the repository correctly remained documentation-only at this stage.
Architecture handoff
Build now has an executable specification rather than a loose prompt. It must read all four design documents, implement the game without external dependencies, and update the existing HANDOFF.md with its final file structure and implementation report. Validation will later use RULES.md, AI_STRATEGY.md, and the handoff checklist as its source of truth.
Step 5 — Build the game
The Build node turned that handoff into a modular browser game. A later continue follow-up found that the implementation had already completed before the original run stopped reporting output, so it audited the files on disk instead of rewriting them.
The resulting project contains one index.html, six CSS files, and ten JavaScript modules. The JavaScript separates cards, deck creation, players, rules, game state, AI strategy, UNO timing, animations, UI rendering, and application startup. This keeps rule decisions isolated from presentation while still allowing the game to run by opening index.html directly.
The follow-up verified the implementation at four levels:
- Structure — all declared HTML, CSS, and JavaScript files exist and are loaded in dependency order.
- Syntax — all ten JavaScript modules pass
node --check. - Self-contained delivery — the game has no CDN, remote image, font, package, bundler, or runtime dependency.
- Connected behavior — dealing, drawing, and playing animations are called by the UI rather than merely being defined as unused helpers.
The implementation covers the full 108-card deck, initial deal, two-player action-card behavior, Wild color selection, drawing, UNO declaration, victory handling, and a non-random AI. Its scoring model favors useful hand reduction, preserves Wild cards for stronger moments, chooses the most common remaining color, and uses Skip, Reverse, and Draw Two to pressure the human player.
HANDOFF.md now marks Build as complete and identifies the implementation areas the validation node must inspect: gameState.js, rules.js, ai.js, and the human interaction layer. The follow-up found no regressions or missing artifacts and made no code changes.
Step 6 — Validate rules and gameplay
The Validation node treated the design documents and HANDOFF.md as the source of truth, then traced the implementation without changing it. All 12 acceptance criteria passed: turn order, Reverse-as-Skip, Skip, Draw Two, Wild, Wild Draw Four, forced drawing and reshuffling, victory handling, UNO timing, guarded human interactions, strategic AI decisions, and responsive presentation with connected animations.
The review also followed the critical flows across module boundaries. It traced the full turn state machine, draw-pile recovery, winning action cards, stale UNO timers, AI scoring, and the event chain from the game engine to the UI. This matters because isolated functions can look correct while their integration is incomplete — as the earlier animation wiring issue demonstrated.
Validation produced validation-report.md with a global PASS and three non-blocking improvements:
- Remove keyboard focus and button semantics from cards that cannot be played and from decorative discard elements.
- Prevent the real discard card from refreshing before a flying Wild-card animation has landed.
- Add an explicit game epoch so timers from a previous match cannot survive a restart.
No application code changed during this stage. Its output was evidence and a precise handoff: the game was already functionally valid, while Finalize received a bounded list of optional improvements.
Step 7 — Finalize and improve the generated code
Finalize could have closed the pipeline immediately because Validation found no failures. Instead, it applied all three optional findings and used them as a focused improvement pass over the initially generated implementation.
Accessibility semantics now match actual behavior: only playable cards enter the keyboard tab order, inert cards expose aria-disabled, and decorative discard elements are no longer presented as buttons. Wild-card rendering now waits for the flight animation to finish before refreshing the discard pile. A new gameEpoch invalidates AI and UNO timers when a match restarts, making an already guarded implementation explicitly safe against stale asynchronous work.
The final node also added non-blocking event toasts for Skip, Reverse, Draw Two, Wild Draw Four, UNO declarations, and UNO penalties. These complement the existing live status rather than replacing it, preserving accessibility while making important game events easier to follow visually.
The improved code passed syntax checks across all ten JavaScript modules. A temporary Node harness simulated 300 complete AI-versus-AI matches without exceptions, infinite loops, or invalid winners, and a directed restart test confirmed that the new epoch guard rejects timers from the previous match. The dependency scan again found no remote assets or runtime packages.
Finally, HANDOFF-COMPLETE.md closed the complete chain — design → build → validate → finalize — and recorded the final artifacts, decisions, verification evidence, and remaining methodological limitation: no node had access to a real browser, so a manual browser play-through remains a useful complementary check rather than a pipeline blocker.
What the Four-Pack changes about human intervention
The value of this Four-Pack-inspired graph is not that humans disappear from software development. It is that their intervention becomes bounded and intentional. A human defines the objective and can review the proposal, but does not need to repeatedly restate the rules between stages or manually coordinate every correction.
Each node receives a narrow responsibility, a durable input, and a concrete output:
- Design converts intent into normative documents and acceptance criteria.
- Build implements those decisions and reports its exact structure.
- Validation challenges the implementation against the written contract.
- Finalize consumes the report, improves the code, and closes the handoff.
This structure reduces conversational supervision because context does not depend on memory or an informal chat history. It travels through HANDOFF.md, design documents, validation-report.md, and finally HANDOFF-COMPLETE.md. Human review can therefore happen at meaningful gates — the original intent, the proposed graph, or the final product — instead of being required after every internal step.
The run also shows how AI-generated code can improve itself without pretending that the first generation was perfect. Build produced a complete game. Validation independently found no blocking defects but identified three concrete weaknesses. Finalize then changed the implementation in response to that evidence, strengthened asynchronous safety and accessibility, removed an animation race, and added clearer event feedback.
That is the practical feedback loop: generate → inspect → report → improve → verify. The autonomy is constrained by explicit rules and artifacts, while the improvement remains traceable to a finding, a code change, and fresh verification evidence. The result is less human micromanagement, not less engineering discipline.
The completed UNO game running directly from index.html. The Four-Pack handoffs turned the initial AI-generated implementation into a validated, polished, self-contained game.