Stress-Test Your Web App

Use a coding agent to find and fix layouts that fail with messy data.

Introduction

30 Second Summary

A web page can look solid with tidy demo content. One unusually long name or crowded list can push text outside its card and hide the controls people need.

In this project, you will use a coding agent to expose layout failures in a small web page. You will repair each failure with the same messy data in place, leaving behind before-and-after screenshots plus committed fixes.

What You'll Build

Load your finished page with long names, odd email addresses, and crowded lists to see every detail stay readable at desktop and phone widths.

By the end of this project, you'll have:

A stress-tested page that keeps very long names, odd email addresses, and crowded lists inside a usable layout.
A repeatable messy-data check that reveals overflow, clipped controls, and layouts that collapse at desktop or phone widths.
Before-and-after screenshots paired with Git commits that make each broken state and its fix easy to compare.
Secret Mission: An optional challenge to push your skills further.

Are there any prerequisites?

You need a small page that contains a name, an email, and a list of items. You also need a coding agent that can load skills plus Node.js or another local development server.

Before We Start

Stress-testing a page only works when you can run it locally. You also need a reliable record of every change.

Your AI coding agent needs a command-line session before it can test the page. This step prepares your local workspace before any project files exist.

In this step, get ready to:

Prepare a modern browser with a code editor.
Confirm Git with Node.js on your computer.
Install an authenticated coding-agent command-line tool.

Prepare your desktop tools

A code editor gives you one place to change files. This walkthrough uses Visual Studio Code because its terminal panel keeps your code with your commands.

Your current browser is already open because you are viewing this project. Choose your operating system below to install the editor.

macOS

Open the official Visual Studio Code download page in your browser.
Download the Universal .dmg installer.
Open the downloaded .dmg file.
Drag Visual Studio Code into your Applications folder.
Press Cmd+Space to open Spotlight.
Type Visual Studio Code into Spotlight.
Press Enter to start the editor.

Windows

Open the official Visual Studio Code download page in your browser.
Download the User Installer for your computer.
Run the downloaded installer.
Complete the installer with its default options.
Press the Windows key to open search.
Type Visual Studio Code into search.
Press Enter to start the editor.

Linux

Open the official Visual Studio Code Linux setup guide in your browser.
Choose the package instructions for your Linux distribution.
Install Visual Studio Code with the documented package method.
Open your desktop app search.
Type Visual Studio Code into the search field.
Start Visual Studio Code from the search results.

Your editor is ready when you can see its main window. The browser displaying this project is ready for the pages you test later.

Git stores each layout fix as a checkpoint. A version check confirms that its command-line tool is available before you create the repository.

Open a new terminal panel from the top menu in Visual Studio Code.
Check whether Git is available by running this command:

git --version

What does this command prove?

The command asks Git to print its installed version. A version in the output proves your terminal can find Git.

✔️ I see a Git version

Good. Git is installed with access from your terminal.

ⓧ Git is unavailable

Git needs to be installed before your terminal can track the project.

Open the official Git downloads page in your browser.
Select the installer for your operating system.
Complete the installer with its default options.
Close the terminal panel after the installation finishes.
Open a new terminal panel from the top menu in Visual Studio Code.
Confirm Git is now available by running this command:

git --version

A printed Git version confirms that the new terminal loaded the installation.

Still cannot run Git?

Restart Visual Studio Code so it reloads your system command paths.
Rerun the official Git installer if the installation stopped early.

Ask for help with the exact result you see: help me make Git available in my Visual Studio Code terminal.

Set up a local web server

Node.js can run the local web server that sends your page to the browser. Its long-term support release provides a stable choice for this project.

Check whether Node.js is available by running this command in the terminal panel:

node --version

What does this command prove?

The command asks Node.js to print its installed version. A version in the output proves the runtime is available to local server commands.

✔️ I see a Node.js version

That is another setup hurdle cleared. Node.js is ready to serve the page locally.

ⓧ Node.js is unavailable

Node.js needs to be installed before you can start the local server.

Open the official Node.js download page in your browser.
Select the LTS release for your operating system.
Download the prebuilt installer.
Complete the installer with its default options.
Close the terminal panel after the installation finishes.
Open a new terminal panel from the top menu in Visual Studio Code.
Confirm Node.js is now available by running this command:

node --version

A printed Node.js version confirms that the new terminal loaded the runtime.

Still cannot run Node.js?

Restart Visual Studio Code so the editor reloads your system command paths.
Check that you downloaded the installer for your operating system.

Ask for help with your operating system details: help me make Node.js available in my Visual Studio Code terminal.

Authenticate your coding agent

This project needs a coding-agent CLI that can load Agent Skills. Authentication gives that local session permission to accept your prompts.

Choose the tab that matches your current coding-agent setup.

✔️ My coding-agent CLI is installed

Start your coding-agent CLI by following its official provider instructions.
Complete the provider sign-in flow if the session requests authentication.
Confirm that the terminal displays an interactive prompt from your coding agent.

ⓧ I need a coding-agent CLI

Skill support matters because a later step loads the UI-testing skill into your agent.

Review the supported coding agents in the official GitHub CLI skill installer reference.
Choose a coding-agent CLI that supports Agent Skills.
Open that provider's official installation guide.
Install the coding-agent CLI with the provider's current instructions.
Complete the provider's sign-in flow.
Start a new authenticated session in your terminal.

Before you send the check, predict whether the authenticated agent can answer with the requested word.

Verify the active coding-agent session by sending this prompt:

Reply with READY if this coding-agent session is authenticated and accepting prompts.

What does this check prove?

The prompt requires a live response from the coding agent. The response confirms that installation with authentication both succeeded.

You should see READY in the agent's response. Your coding agent can now take part in the project.

No response from the agent?

Check whether the coding-agent session is still waiting for you to finish browser authentication.
Restart the coding-agent CLI after completing the provider sign-in flow.
Review the provider's official account-access guidance if the session closes immediately.

Ask for help without sharing tokens or credentials: help me troubleshoot my coding-agent CLI authentication.

Before the final check, picture the three success signals you expect to find in your terminal history.

Scroll back to the printed Git version.
Locate the printed Node.js version.
Confirm the coding agent's READY response.

You should find all three signals. Your full local development environment is ready.

Your browser with local tooling can now support the complete test loop. Next, you will create the repository with the page that your agent tries to break.

Build and Capture the Clean Page

Stress-testing only means something when you can compare a broken layout with a known-good starting point. This step creates that control sample before hostile data touches the page.

You'll use your coding agent to build a small page with ordinary data. Then you'll preserve its clean state in Git.

In this step, get ready to:

Create a repository for the baseline page.
Build a locally runnable page with normal demo data.
Preserve the working state with a screenshot plus an initial Git commit.

Prepare a safe starting point

A dedicated repository keeps the page files together with the screenshots that document each test. The first commit gives you a clean point to compare against later.

Create the messy-data-page repository on your Desktop by running these commands:

cd ~/Desktop
mkdir messy-data-page
cd messy-data-page
mkdir screenshots
git init

What does this setup do?

The first command places the project on your Desktop so you can find it easily.
The messy-data-page folder holds the web page files.
The screenshots folder keeps your visual evidence beside the page.
The git init command turns the current folder into a Git repository.

Good start. Your terminal confirms that an empty Git repository was initialized inside messy-data-page.

Repository setup failed?

Check that your terminal can access the Desktop. Confirm that a folder named messy-data-page does not already exist there.

If the folder already exists from an earlier attempt, choose a different empty folder or remove the unfinished copy first.

help me create and initialize the messy-data-page repository

Build and run the clean page

The clean page needs enough text-heavy structure to make later layout failures visible. Normal demo data gives you a calm baseline before the stress test begins.

Your agent may request permission before writing files or starting a local process. Review each request so its changes stay inside messy-data-page.

Start your authenticated coding-agent CLI from the current terminal using the command from your setup.
Ask the agent to build a small single-page profile card or contact list inside the current messy-data-page folder.
Require the page to display the name Maya Chen.
Require the page to display the email address maya.chen@example.com.
Require the page to display a short list of ordinary project activities.
Require the page to display a visible action button labelled Send message.
Approve file changes that stay inside messy-data-page.
Ask the agent to start the page with your available local web-server option.

The agent reports a localhost URL when the server is ready. Keep the server process running while you capture the baseline.

Record the reported URL here: your localhost URL.
Paste your localhost URL into your browser's address bar.
Press Enter to load the page.

You should see a card or list layout with Maya Chen as the name. You should also see the normal email address, a short item list, plus the Send message button.

Page missing or incomplete?

Check that the local server process is still running in the terminal.
Confirm that the browser URL matches the localhost URL reported by your agent.
Ask the agent to inspect the rendered page against the name, email, list, plus button requirements.

help me diagnose my missing baseline page

✔️ My page matches the baseline

Your clean page is running with normal demo data. Keep the local server running for the screenshot.

ⓧ I'd like to double check the full code

Your coding agent may choose any locally runnable file structure. The complete generated project must produce the same baseline result.

Confirm that the complete project displays a normal name.
Confirm that the complete project displays a normal email address.
Confirm that the complete project displays a short item list.
Confirm that the complete project displays a visible action button.
Ask the coding agent to correct any missing requirement inside messy-data-page.
Refresh the browser to confirm the corrected page still loads from your localhost URL.

Capture and commit the baseline

A useful baseline shows the entire browser window at a normal desktop width. The screenshot becomes your visual control for every break you uncover later.

Set the browser window to a comfortable desktop width.
Confirm that the normal name is fully visible.
Confirm that the normal email address is fully visible.
Confirm that the short list is fully visible.
Confirm that the action button is fully visible.

macOS

Press Shift+Command+4 to begin a screenshot.
Press the Space bar to switch to window capture.
Click the browser window to capture it.
In Finder, move the new screenshot from your Desktop into the messy-data-page/screenshots folder.
Rename the screenshot to clean-baseline.png.

Windows

Press the Windows key+Shift+S to open the snipping overlay.
Select Window as the snipping mode.
Click the browser window to capture it.
Select the screenshot notification to open it in Snipping Tool.
Press Ctrl+S to save a copy.
Select the messy-data-page/screenshots folder.
Enter clean-baseline.png as the file name.
Click Save.

That's your control sample captured. It preserves exactly how the page looked before the hostile-data testing begins.

A commit now freezes the working page plus its clean screenshot as one recoverable baseline. Future fixes can be compared against this exact point.

Open a second terminal from your code editor inside the messy-data-page folder.
Record the entire baseline in Git by running these commands:

git add .
git commit -m "Initial commit"

What does this commit contain?

The git add . command stages the locally runnable page plus its baseline screenshot.
The commit records those staged files with the message Initial commit.

Before you inspect the history, which commit message do you expect to see?

Verify the repository history by running this command:

git log --oneline

What does this check prove?

The git log --oneline command displays each saved commit in a compact format.

You should see a short commit hash followed by Initial commit.

Commit not created?

If Git asks for your identity, follow the instructions printed in the terminal. Run the commit commands again after your identity is configured.

If Git reports that there is nothing to commit, confirm that the coding agent created the page files inside messy-data-page.

help me fix my initial Git commit

Your baseline is complete. The page runs locally, its normal data is visible, plus its clean state is saved in Git.

Baseline checkpoint

Your Git repository contains a locally runnable profile or contact-list page.
Your page displays a normal name, a normal email address, a short list, plus an action button.
Your browser displays the page from a localhost URL.
Your screenshots folder contains the clean baseline captured before hostile-data testing.
Your repository history contains the Initial commit entry for the working baseline page.

Your control sample is safely preserved. Next, you'll equip your coding agent with the skill that stress-tests this layout.

Install the Break-UI Skill

Your baseline page is running with normal demo data. The clean screenshot preserves its starting layout.

Your initial Git commit preserves the working code. That gives you a safe point to return to after testing.

Normal demo data has not tested the page's limits. An Agent Skill is a reusable instruction set that gives your coding agent a consistent workflow.

In this step, you will install break-ui so the agent can introduce hostile data in the next step.

In this step, get ready to:

Install the break-ui skill from emilkowalski/skills for your authenticated coding agent.
Confirm break-ui appears in the installed-skill list.

Install break-ui from the skills repository

The official Skills CLI downloads skills from a repository. Project scope keeps the installed skill connected to this web app repository.

The installer can ask which detected coding agent should receive the skill. It can also ask which installation scope to use.

What should you choose?

Choose the coding agent where you are already authenticated. Choose project scope so break-ui is available while you work in this repository.

Your terminal may ask for permission to download the Skills CLI. Approve that download to continue.

Return to the authenticated coding agent from the previous step.
Open a second terminal panel for the web app repository.
Install only break-ui by running this command:

npx skills add emilkowalski/skills --skill break-ui

What does this command do?

The npx skills add command starts the installer without requiring a separate global CLI installation.
The emilkowalski/skills value identifies the source repository.
The --skill break-ui option limits the installation to the stress-testing skill.

Select your authenticated coding agent if a target prompt appears.
Select project scope if a scope prompt appears.
Confirm the installation when the installer asks for approval.

You should see a confirmation that one skill was installed for the selected coding agent. Good progress. The hostile-data workflow is now attached to this repository.

Skill installation failed?

Check that the terminal is using the web app repository as its current folder.
Check your internet connection if the installer cannot reach the source repository.
Use a terminal where npx is available if the Skills CLI cannot start.

Help me install break-ui in my coding agent.

Confirm break-ui in the installed-skill list

An installation message proves that the download finished. The installed-skill list proves that your coding agent can find the skill in its configured location.

Before you check, which skill name do you expect the list to contain?

Display the installed skills by running this command:

npx skills list

What does this command check?

The command scans the supported coding-agent locations for installed skills. Its output shows which skill names are available to your agent.

You should see break-ui in the installed-skill list. That listing confirms the skill is ready for the stress test.

Don't see break-ui?

Run the list command from the same web app repository where you installed the skill.
Rerun the installation command if break-ui is absent.
Select the authenticated coding agent when the installer asks for a target.

Help me find my installed break-ui skill.

That's the installation proven. Your baseline page remains untouched. Next up, you will run break-ui against the layout to reveal what normal demo data was hiding.

Find Layout Breaks

Your clean baseline proves the page works with friendly demo data. It says little about what happens when real input stops fitting.

The installed break-ui skill supplies hostile inputs. This step records each layout failure before any repair begins.

In this step, get ready to:

Run break-ui against the locally running page with the required hostile fixture.
Inspect the page across multiple browser widths.
Capture a before-fix screenshot for every layout failure.

Run break-ui against the page

Hostile-data testing swaps tidy values for inputs that strain the layout. Keeping every case in one fixture makes each later comparison reliable.

Switch back to the coding-agent chat from earlier.
Draft a test request using the installed break-ui skill.
Point the request at the locally running page from earlier.
Require an overlong name as the first test case.
Require an unusual or long email address as the second test case.
Require a long item list as the third test case.
Require the skill to keep one exact hostile-data fixture throughout the test.
Require the skill to report failures without applying fixes.

Before you submit the request, make a mental prediction about the first part of the card that will fail.

Submit the test request in your coding agent.

The page should now show all three hostile cases. The agent should report the visible layout failures it found.

What counts as a layout break?

Visible overflow sends an overlong name past the card boundary.
Clipping hides part of an unusual or long email address.
A long item list displaces the action button from its expected position.

Did the page stay unchanged?

Confirm that the local development page from earlier is still running. Point the test request at that running page again.

Tell the agent to stop after documenting failures if it begins editing the layout.

Help me diagnose why the installed break-ui skill did not test my locally running page.

Capture every visible break

A useful screenshot proves which input caused a specific failure. The hostile fixture must stay unchanged while you collect that evidence.

Return to the local browser page from earlier.
Keep the hostile-data fixture exactly as the skill generated it.
Inspect the overlong name at the current browser width.
Inspect the unusual or long email address at the current browser width.
Inspect the action button after the long item list.
Capture one screenshot for each visible break.
Frame each screenshot around the affected card or list.
Include the nearest layout boundary in each screenshot.

Subtle breaks can be fiddly to spot at first. A narrow window often exposes controls that have shifted or text that no longer fits.

Narrow the browser window to a phone-like width.
Repeat the three layout inspections with the same hostile fixture.
Capture one screenshot for each new failure visible at the narrow width.

You now have a visual record of every break caused by the hostile fixture. Each image preserves the evidence that the next repair must address.

Verify the evidence set

A trustworthy before-fix record uses one repeatable fixture. It also leaves the normal page ready for the next step.

Switch back to the coding agent from earlier.
Ask break-ui to preserve the exact hostile-data fixture for the next repair pass.
Ask break-ui to restore the normal demo data without changing the layout.
Return to the local browser page.
Refresh the page.

You should see the normal name, email address, short item list, and action button again. The page should remain locally runnable.

Before you compare the images, predict whether every reported failure can be matched to one hostile value.

Compare the clean baseline with the before-fix screenshots in your image viewer.
Match each screenshot to its hostile-data case.
Confirm that every observed failure has a screenshot.
Confirm that every before-fix screenshot uses the preserved hostile fixture.

The baseline should show the clean layout with normal demo data. Each before-fix screenshot should show a specific failure caused by the same hostile fixture.

Your breakage map is ready. Next, you will let the agent repair one failure at a time while holding the hostile fixture constant.

Fix Each Broken Layout

You now have concrete evidence of every layout break that break-ui found. Each before-fix screenshot gives you a fixed test case for the repair.

Batching repairs makes it hard to connect a change to its result. You will keep the hostile data unchanged while your coding agent fixes one break at a time.

In this step, get ready to:

Give your coding agent one documented layout break at a time.
Produce a matching after-fix screenshot for every repaired break.
Create separate Git commits for the verified fixes.

Apply one focused fix

A robust fix keeps every value readable. Clipping can hide the symptom while the user's data disappears.

Select one documented break from your before-fix screenshots.
Return to the coding agent from earlier.
Ask it to restore the exact hostile case from the selected screenshot using the same test method as before.
Switch back to the locally running page from earlier.
Confirm the same hostile values are visible.
Return to your coding agent.
Ask it to identify the root cause of the selected break without editing any files.
Ask it to propose the smallest layout change that preserves the complete content.

Keep the Data Reachable

A layout can look tidy after content has been clipped from view. A passing fix keeps long names plus unusual email addresses available to the user.

The action button must also remain reachable. Visual neatness never outweighs access to the page's content or controls.

Review the proposed fix for complete content visibility.
Ask the agent to revise any proposal that makes data unreachable.
Ask the agent to apply only the approved fix.
Return to the locally running page.
Reload the current page.
Compare the repaired area with its before-fix screenshot.

You should see the selected break improve while the same hostile values remain visible. Other parts of the page should retain their previous layout.

Fix Not Visible?

Confirm the coding agent edited the files used by the running page.
Confirm the browser still displays the selected hostile case.
Reload the page after the local app finishes rebuilding.

If the break remains unchanged, help me diagnose why my layout fix is not visible.

Verify and capture the repair

A repair passes when the original hostile case stays readable across different widths. The before-fix screenshot provides the reference for a fair comparison.

Keep the exact hostile test case displayed.
Check the repaired layout at the desktop width represented by the before-fix screenshot.
Resize the browser to a phone-width view.
Check that all hostile content remains readable.
Check that the action button remains reachable.
Return the browser to the width represented by the before-fix screenshot.
Capture an after-fix screenshot using the same framing.
Store the screenshot with its matching before-fix screenshot.

That comparison is meaningful because the data stayed fixed. The layout change is the only moving part.

Commit each fix and run the final check

A focused commit records which change solved each break. This also limits the risk of a shared layout edit changing an unrelated part of the page.

Return to your coding agent.
Ask it to show the files changed by the current fix.
Confirm the changes only address the selected layout break.
Ask it to create a Git commit with a message that names the repaired break.
Ask it to show the latest commit summary.
Confirm the summary contains the selected fix.
Repeat the complete repair loop for each remaining before-fix screenshot.
Confirm each documented break has a matching after-fix screenshot plus a dedicated fix commit.

You should now have a one-to-one record for every break. Each record connects the original failure to its verified repair.

Commit Contains Unrelated Changes?

Ask the coding agent to leave unrelated changes out of the commit.
Keep shared component edits only when the selected break requires them.
Verify the commit summary again before continuing.

If the changes are difficult to separate, help me create a focused commit for one layout fix.

Before the final check, which test case do you expect to put the most pressure on the repaired layout?

Switch back to the locally running page.
Restore the normal demo data.
Compare the normal page with your baseline screenshot.
Load each hostile test case in turn.
Test each case at a desktop width.
Test each case at a phone width.
Confirm each case preserves readable content plus a reachable action button.
Restore the normal demo data after the checks.

Your normal page should match its baseline appearance. Every hostile case should keep its content readable at both widths.

The action button should stay reachable in every case.

That is a strong finish because your repository now has a focused commit for every verified fix.

Your page now survives the hostile cases break-ui found. Next, you will invent one harder case of your own.

Test Your Worst Case

The break-ui skill exposed weak spots in your page. Your verified fixes now protect the content that broke during those tests.

A responsive layout can still fail on an edge case that an automated test did not try. This step adds a learner-defined case to your test data before you preserve the result in Git.

In this step, get ready to:

Define a worst-case value that goes beyond the existing hostile data.
Verify that every character remains readable at desktop width and phone width.
Preserve the final evidence in your repository with a new commit.

Define your own edge case

Your existing hostile data came from the coding agent. A learner-defined case checks whether the fixes handle a value that you choose yourself.

Create a surname that contains exactly 60 characters.
Record the surname here: your 60-character surname.
Switch back to the authenticated coding agent from earlier.
Ask the agent to replace the name in the existing hostile-data test case with your 60-character surname.
Tell the agent to keep the unusual email address unchanged.
Tell the agent to keep the long item list unchanged.
Ask the agent to report which test-data file it changed.
Ask the agent to confirm that the surname contains exactly 60 characters.

Your hostile-data test now combines your surname with the existing email address. It also keeps the long item list in place.

Ask the agent to display the updated hostile-data test case in the running page.
Return to the local browser from earlier.
Refresh the page.

You should see your learner-defined surname inside the page. The same unusual email address and long item list should still be visible.

Still seeing the normal demo data?

Ask the agent to identify the data source used by the running page.
Ask the agent to render the hostile-data test case from that source.
Refresh the local page after the agent finishes.

If the normal data remains visible, help me connect my hostile-data test case to the running page.

Challenge the fixed layout

A successful edge-case test protects the content at more than one width. The surname must remain readable while the list and action button stay inside the layout.

Before you check, what do you expect the layout to do at both widths? Hold that prediction in mind.

Refresh the local page.
Inspect the page at its current desktop width.
Check that the complete surname stays inside its card or list row.
Check that the unusual email address remains readable.
Check that the item list stays inside its intended area.
Check that the action button remains visible.
Resize the browser until the content area is roughly as narrow as a phone screen.
Repeat the same checks at the narrow width.

You should see every character remain readable inside the layout. The long item list should stay contained.

The action button should remain visible at both widths. That is strong evidence that your fixes survive a test you designed yourself.

Did your case expose another break?

Ask the coding agent to fix only the layout behavior that failed.
Tell the agent to preserve every surname character instead of hiding clipped content.
Repeat the desktop-width check with the same hostile data.
Repeat the phone-width check with the same hostile data.

If the same value still breaks the page, help me diagnose the remaining overflow without hiding any content.

Capture a screenshot of the successful learner-defined case at the narrow width.
Save the screenshot beside the after-fix screenshots from earlier.

Preserve the final evidence

Your screenshot proves that the fixed page handles the extra case. Pairing it with the earlier evidence makes the improvement easy to review.

Return to the screenshot location used earlier.
Arrange each before-fix screenshot beside its corresponding after-fix screenshot.
Place the learner-defined screenshot with the after-fix results.
Ask the coding agent to preserve your surname in the hostile-data test cases.
Ask the coding agent to restore the running page to its normal demo data without deleting the hostile-data test cases.
Return to the local browser.
Refresh the page.

You should see the normal name and email address again. Your learner-defined value remains available in the saved test data.

Use the Git workflow from earlier to stage the updated hostile-data test case.
Stage any final layout fix that your learner-defined case required.
Stage the new screenshot with the existing screenshot evidence.
Create a final commit that describes the learner-defined worst-case verification.

Before the final check, what do you expect the repository to report after the commit? Keep your prediction in mind.

Ask the coding agent to confirm that the final verification commit is present.
Ask the coding agent to confirm that the repository has no uncommitted changes.

You should see the final verification commit in the repository history. You should also see confirmation that every staged change is committed.

You have now tested the page with automated hostile data plus an edge case of your own. The repository preserves the fixture and the visual proof.

Secret mission

Prove Every Character Stays Visible

Take the same hostile data to a phone-sized browser width. Prove that every value remains readable. Confirm that the action button stays accessible without sacrificing the normal layout.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs locally, so it has no ongoing cloud cost.

Resources you used:

The running local development server that serves your profile or contact-list page.
The web app repository containing your page, Git history, hostile-data fixtures, layout fixes, and screenshots.
The break-ui skill installed in your authenticated coding agent.

Keep everything running

No action needed. Choose this if you are still testing edge cases or improving the page.

The local development server stays active while its terminal process keeps running.
The web app repository retains the baseline commit, fix commits, test fixtures, and final layout.
The before-fix screenshots remain beside their matching after-fix screenshots.
The break-ui skill remains available for future interface tests.

Pause - I'll come back to this later

Shut down the running page to free its local port. Your repository and testing evidence remain ready for the next session.

Switch back to the terminal where the local page is running.
Press Ctrl+C to stop the local development server.
Return to the browser tab that displayed the local page.
Refresh the browser tab to check that the local page no longer responds.

You will see that the page no longer loads after the refresh. That result confirms the server process has stopped.

Good progress. Your Git history and screenshots remain safe inside the repository.

Keep the web app repository on your computer for later testing.
Leave the break-ui skill installed if you plan to stress-test more interfaces.

Delete - I don't want to use this again

Remove the local project files for a clean start. You can also remove the agent skill if you do not want it available for other projects.

Stop the local page

Switch back to the terminal where the local page is running.
Press Ctrl+C to stop the local development server.
Return to the browser tab that displayed the local page.
Refresh the browser tab to confirm that the page no longer responds.

That closes the running part of the project. Your files remain safe until you remove the repository.

Delete the repository

Deletion is permanent

This is the irreversible part of cleanup. Deleting the repository removes the page, Git history, hostile-data fixtures, and screenshots stored inside it.

Use your operating system's file browser to locate the web app repository.
Check that the repository contains the profile or contact-list page from this project.
Check that any screenshots you want to preserve also exist outside the repository.
Move the repository folder to your operating system's deleted-items area.
Permanently clear that deleted-items area.
Check the repository's original location to confirm that the folder is gone.

Remove the skill if needed

The coding agent stores the skill outside the deleted repository. The skill remains available until you remove it through that agent.

Return to your authenticated coding agent.
Use the agent's documented skill-removal flow to remove break-ui.
Return to the agent's installed-skill listing.
Confirm that break-ui no longer appears in the listing.

Cleanup is complete. The local server, repository, screenshots, and optional agent skill are now removed.

Nice Work!

You did it! Your page now keeps its content readable when hostile data tries to break the layout. Your Git history preserves the evidence behind every fix.

You've learned how to:

Use the break-ui skill to stress-test a web page with hostile data. Your cases covered overlong names, unusual email addresses, and long item lists.
Diagnose layout failures such as overflowing text or displaced controls. Your paired screenshots make each break visible.
Apply and verify overflow-safe fixes one at a time. Your commits record how the page moved from each failure to a responsive layout with readable content and accessible controls.
Secret Mission: Extended the hostile-data fixture with your own worst-case value. You proved the repaired layout still holds under a test such as a 60-character surname.

Ready to quiz yourself?