Revisiting a half-finished project with agentic debugging
Returning to an old project often means confronting the UI issues you left behind. That was the premise of a recent debugging session on OctoArcade, a collection of GitHub-themed mini-games built with Next.js and TypeScript. Instead of manually tracing layout problems, the session took a different route: letting GitHub Copilot agent mode work alongside the Playwright MCP server to identify and fix visual bugs in near real time.
Preparing Copilot with current context
Before starting any agentic work, it's worth verifying that Copilot's custom instructions files — .github/copilot-instructions.md and *.instructions.md — are current. These files carry expectations about coding style, repo structure, and working practices, which directly influence how Copilot behaves in agent mode. When the instructions fall out of date, a simple prompt asking Copilot to review and update those files helps restore the context it needs:
Based on the #codebase, please can you update the custom instructions file for accuracy? Please make sure to keep the structure (i.e. headings etc.) as-is. Thanks!It's also practical to instruct Copilot to refresh key documentation such as the README whenever it makes significant changes, like refactoring or adding features, so the repository stays accurate over time.
Giving Copilot browser access via Playwright MCP
The Playwright MCP server bridges the gap between Copilot's agent mode and a real browser environment. Through the Model Context Protocol, Copilot gains structured tools to load pages, simulate clicks and navigation, inspect rendered layouts, and capture screenshots — all without relying on vision models. To connect it, the MCP configuration only needs a short entry:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}Once the server is running, Copilot has access to a set of browser interaction tools including browser_snapshot, browser_navigate, browser_click, browser_type, browser_hover, browser_resize, and browser_take_screenshot. A full list is in the Playwright MCP server README's tools section.
The debugging session: issues found and fixed
The main problem was visible across multiple pages: the navigation header was overlapping game content, and some games had inconsistent spacing between the canvas and footer. The workflow that followed demonstrated both the strengths and limits of agentic debugging.
Starting with an explicit prompt
The first step was describing the problem precisely. Copilot agent mode was asked to inspect pages where content sat behind the navigation bar and to identify layout inconsistencies. The prompt needed to be specific about which pages to check and what behavior was expected:
I have spotted that there is a bit of a UI error. It seems like the main content of any page "starts" behind the navigation bar. This is more evident on the games like octosnap, octopong and octobrickbreaker.
Can you take a look at the site using Playwright (you'll need to spin up an instance of the server), take a look at the pages, and then investigate? Thanks!Copilot loaded pages and configured each game, but it didn't attempt to actually run the games, which meant it missed some context. A follow-up prompt addressed that:
Sorry, I wanted you to take a look when a game is actually loaded too. Can you play the game Octopong and Octosnap – I think it’s very visible in those? Do that before you build a plan.The lesson here is familiar: more context yields better results. Copilot is like a teammate — it only knows what you communicate. Once given the right direction, it launched a browser, navigated through the app, and diagnosed where content was hidden or misaligned.
The root cause turned out to be architectural. Each game page had its own DynamicHeader component with separate local state, which overlaid the main navigation bar from the root layout. Copilot's fix was to use the root layout navbar throughout and pass context up from individual pages, so only one component manages state and updates propagate cleanly.
At this stage, the debugging was effectively hands-off. Copilot applied the fix, reran the app, checked the results visually, caught its own linting errors, and iteratively resolved them.
Chasing the remaining UI gaps
One bug didn't reproduce clearly in the livestream but was visible on a local screen: small gaps between the OctoPong board and footer. When prompted to fix this, Copilot made changes, yet each attempt introduced side effects — games extending beyond the viewport or missing paddles in Pong.
| Prompt | Result | Reflection |
|---|---|---|
| I’ve noticed a minor UI bug on the Octopong game page (this only happens when the game is actually live). There is a small space between the game itself and the footer. I want the game to extend all the way to the footer (not necessarily push the footer beyond the fold though). Can you use the Playwright MCP server to explore what’s going on, build a structured plan / todo list to resolve the actions? Thanks | It achieved what I had asked, but the pong paddles no longer displayed (which was a side effect of the container now being 0 height). Through no fault of Copilot, I hadn’t asked for the game components (e.g. Paddle/Ball) to be visible in the game area. The game was still playing (in a 0 height container), but the key components were not visible to me as the player. | – Good clarity on tools to use. – Good clarity on asking for a plan (as Copilot asked me to review/approve before making the changes). – Lack of clarity on the full requirements (i.e. having the game components be visible and working). |
| Just to jump in, can you test again? It looks like the paddles and the ball are now missing as a result of the change? | The game began working again, however it introduced the gap that we early sought to resolve. | – Solved the immediate challenge of making game components visible. – Lack of clarity that the earlier requirements were still required. |
| Can you check the game once again? The spacing issues are still there. The requirements are: 1. The game is playable (i.e. balls and paddles are visible and one paddle is usable for the player). 2. The game area covers the “full space” between header and footer. I think the space problem is back. You must meet both requirements please, thanks. | Once again, Copilot fulfilled the requirements! But this time, the game extended beyond the viewport, and so a user would have to scroll to move the paddle to prevent the ball scoring against them (which is not an ideal experience!). | – Solved all of the requirements we outlined – Lack of clarity in the actual requirements (that the game should not extend beyond the viewport). |
| Thanks! Sorry, I forgot to give you a third requirement. Your solution makes the game extend beyond the fold, which makes the user have to “scroll” to play the game. These are the requirements you must meet: 1. The game is fully functional (paddles/ball working and visible). 2. There is no space between the game and the footer. 3. The game must not extend beyond the fold (i.e. the user must not have to scroll to see any part of the game board. So the game board at maximum must end at the bottom of the screen). The footer can be below the fold. Please feel free to reword/rewrite my requirements, as I struggled to define them. Make sure you confirm with me the requirements are accurate. | Success! After we prompted Copilot with our full requirements, it was able to think through and iteratively approach the problem to get to the working layout. | – A full set of requirements solved all of the requirements we outlined. – While there were some minor issues in the mobile view, (a small gap between the navigation bar and game), other pages hadn’t yet been optimised for mobile. Since this isn’t a priority, it can be a task for later. |
The culprit wasn't Copilot's execution but the clarity of the requirements. Getting the desired outcome took several attempts, and the real challenge was articulating exactly what the fix should look like. That required iterating on prompts, testing the output, and adjusting direction until the explanation matched the intended result.
Practical guidance for agentic UI work
The session distilled into a few repeatable habits for using Copilot agent mode with MCP servers:
- Keep custom instructions fresh: The agent pulls repo context and coding conventions from these files, so they need periodic updates.
- Equip Copilot with MCP tools: Playwright MCP turns Copilot into a tester capable of end-to-end inspection rather than just code generation.
- Be explicit about requirements: If a behavior matters — like footer spacing or viewport handling — write it into the prompt instead of expecting the agent to infer it.
- Work in small increments: Commit after each meaningful change so it's easy to roll back and isolate what introduced a new problem.
What the session confirmed
Agentic tooling like Copilot agent mode paired with Playwright MCP can move the needle on UI debugging, provided the right context is in place. The other takeaway is that describing requirements is genuinely hard — and that's acceptable. Iteration, feedback, and occasional missteps are inseparable from solving layout bugs this way. The workflow isn't about one perfect prompt; it's about steady progress.
