Goal: add as many features as possible to a game with your partner using several coding agents at once. The challenge is to keep the agents busy while managing multiple sessions and integrating their changes well. Give each agent its own branch and worktree, review its changes, and combine the changes in one shared repository.
Your main result is an HTML report: how long each agent worked and how long it waited for you, the repository’s history graph, and a short description of what you accomplished. Your agent makes the data; you check it. The report is what we discuss at the end.
Your partner must be new. Pair up with someone you did not work with in Lab 1 or Lab 2. This is enforced: the lab instructor checks every pair at the start.
Before the session
The starting game is Coin Dash. Play it first: arrow keys or WASD, collect the yellow coins, avoid the red drones. It is a small JavaScript game that runs entirely in the browser.
- Have your agent inspect the repository before it runs anything. Ask it to clone the
repository and read every file, then tell you what each one does, whether anything reaches the
network or runs outside the browser, and whether the large file under
vendor/really is the Phaser release it claims to be (it can compare a checksum against the copy on the CDN named in the README). Read its answer. Only then ask it to run the game locally. A repository from a stranger is code you have not read, and that includes one from your instructor. - Try the included
lab-reportskill on that session. Start a fresh agent session in the cloned repository and invoke/lab-reportin Claude Code or$lab-reportin Codex. Give it a time window covering the inspection you just did. It produces a JSON export and a report page; open the page and load the JSON to check the timeline. If the skill is not listed, ask the agent to read.claude/skills/lab-report/SKILL.mdand follow it. If it cannot find your logs, ask the lab instructor before class. - Confirm you can create a GitHub repository and push to it. If you log in with
gh auth login, know what it grants: a standing token, saved on your laptop, that reaches every repository your account can reach, for any program you run. We narrow it in a later week.
Phase 1 — Set up together (15 min)
Work in pairs, one laptop each. One partner creates the pair’s repository from the template
(the Use this template button on GitHub, or ask the agent to run gh repo create with
--template avivz/coin-dash) and adds the other partner as a collaborator. Both clone it and
open the game in a browser. Keep it browser-only throughout the lab; there is nothing to deploy.
Check access from both laptops. Each partner has the agent push a small agreed change. Then synchronize both clones, save a clean checkpoint, and record its commit identifier. Ask the agent to show the history so you can identify your shared starting version.
Record the lab’s start and end times, including the timezone. Use the same times on both laptops for your reports.
Ask your agent to handle branches, commits, merges and pushes. Run git diff yourself when
reviewing its changes. You should understand what you are asking for and check what happened.
Phase 2 — Build, review, and combine changes (60 min)
Start several agents. Each of you starts two concurrent tasks, with a separate branch and worktree for each. Choose different features with your partner. Keep agents busy with new features as you review and integrate completed ones; add more sessions as you get comfortable. Push yourself, but slow down and ask for help if Git or juggling sessions gets confusing.
Try delegating as well as opening sessions yourself. Give one agent a complete brief for parallel subagents, then try separate sessions where you answer questions and adjust requests. For example, delegate two visual alternatives and choose one, or delegate two independent features. If your tool cannot run subagents, use separate sessions and note that in your report.
Feature ideas
A pause key, scoring sounds, a new visual style, difficulty presets, touch controls, a high score that survives a reload, power-ups, enemies with different behaviour, levels, or a two-player mode. Choose your own ideas too. Give the agent the behaviour you want, and keep features small enough to try during the lab.
Review and integrate as you go. In your own terminal, run git diff in the feature’s worktree
and read the changes against what you asked for. Run the game there before accepting the feature.
After combining changes, play the game again and push the working version.
Running the diff yourself — syntax reminder
Ask the agent for the feature’s worktree path and the commit it started from. Open a terminal in
that folder. Replace START_COMMIT below with that commit’s identifier:
git diff --stat START_COMMIT
git diff START_COMMITThe first command summarizes the changed files; the second shows the changes in tracked files
from the starting version to what is in this worktree now, including changes the agent already
committed. Lines beginning with - were removed; lines beginning with + were added.
If the output opens in a pager, press q to return to the terminal.
Plain git diff only shows unstaged changes, so it can be empty after the agent commits even
though the feature changed several files. Keep the starting commit in the command.
New files: run git status --short. Files marked ?? are untracked and absent from the diff;
open those files separately. A new file already added to Git can appear in the diff.
Use whichever integration approach you are comfortable with: merge or rebase, then merge.
Feel free to experiment. Rebase only your own unshared work, not shared main. If a push is
refused, bring in your partner’s changes, check the result, and push again.
If there is a conflict, agree on what the combined game should do and check the resolution.
Stop and ask for an explanation whenever you lose track of the branches.
Keep a few observations. Note a moment you lost track of a session, spent time coordinating, or had trouble combining changes. The logs can show activity, but they cannot tell us where your attention was.
Near the end, finish and make the report. Allow about ten minutes within this work block.
Stop starting features, merge what you want to keep, push, and play the final game. On each
laptop, use lab-report with the lab’s time window. It writes and checks that laptop’s JSON,
history graph included, and provides the report page. Move one export to the other laptop, load
both JSON files into the page together, and save the combined HTML.
Check the agent’s description of what you did: merged is not the same as checked working. Add your own observations and check how your changes came together in the history graph. Print the tree yourself too, in your own terminal, and compare it with the report’s:
git log --graph --oneline --decorate --allOne line per commit, the branch lines drawn on the left, branch names in brackets, every branch included. Do not spend the remaining lab time polishing the report.
Phase 3 — Show and discuss (15 min)
Each pair opens its report and briefly shares what it accomplished and one observation from the timeline or the history graph. We will discuss:
- Could you switch your attention fast enough to manage several sessions? Where did you lose track or spend time coordinating?
- How did you combine your changes? Did anything make it difficult?
- How did you check that the combined changes worked?
What to show the lab instructor
- Your saved HTML report: both partners’ timelines, how long the agents worked and waited on each laptop, the history graph, and your description and observations.
- The game and its history: demonstrate the changes you marked as working. Each partner explains one contribution and how it became part of the shared game.
- The report uploaded to Moodle before you leave: Lab 3 report.
It takes one
.htmlfile, the page you saved; each partner uploads the pair’s file.
How you’re graded
Report and walkthrough checked by the lab instructor: 3 points. Sharing your findings in the closing discussion: 1 point. Max grade: 4 of 4 points.
Late for the lab (over 10 minutes): -1 point HTML report not uploaded to Moodle: -1 point Unprepared for the lab (for example, no working setup): -1 point or more
Not graded: appearance, feature count, number of agents, or how long the agents ran.