Catch Bugs Before Users Do with Glitch
Finds what's broken on a page — links, images, forms, and the errors behind them — then fixes it, on your say-so.
Some things break quietly. A link that stopped resolving when a page was renamed, an image that never loads on mobile, a form field that isn't built the way it looks. Nobody notices until a client does. Glitch is the specialist who goes looking for them — and, unusually among the InnerCircle, he'll repair what he finds if you ask him to.
Glitch Personality Snapshot
In the app he’s simply Functionality, and he’s the one member of the team who treats a page as something to be caught out. Where Pixel is looking at how a page reads visually and Lexi at how it reads as language, Glitch is hunting. Watch the sidebar while a check runs and he announces himself doing exactly that — Glitch here, looking for bugs — then narrates the sweep as he goes.
That energy stops at the point of writing something down. His findings are deliberately flat: the specific thing that’s wrong, the evidence for it, and what it costs the page rather than why it’s interesting to him. He won’t pad a list to look thorough, and he won’t reach into another specialist’s territory to do it — a genuinely clean page gets a short report, and that’s the intended outcome, not a failed check.
The same restraint runs through how he repairs things. He fixes the fault and stops. When a proper repair would mean touching more than the broken part, he’ll tell you rather than decide for you.
How it actually works
Glitch works two ways, and the difference between them is the most important thing on this page.
| Mode | What Glitch does | Does anything change? |
|---|---|---|
| Checking | Inspects the page and reports what he can see. | No. A check writes nothing, ever. |
| Fixing | Repairs a specific fault you’ve asked him to repair. | Yes — scoped to the fault, and gated by your approval. |
What you can check
A check isn’t limited to one page.
| Target | When to use it |
|---|---|
| A single page | Before a handover, or when something specific has been reported. |
| A whole site | Post-launch sweeps, taking on a site you didn’t build, or a periodic pass over a client on a care plan. |
What Glitch looks for
Glitch reads the page as your visitors see it, across desktop, tablet and mobile.
| What he checks | What that catches |
|---|---|
| Links | Addresses that go nowhere, usually left behind when a page was renamed or removed. |
| Assets | Images, files and references that don’t load. |
| Form structure | Fields and forms that aren’t built properly — visible faults in how the form is put together. |
| Buttons and controls | Things that look interactive but aren’t wired up to anything. |
| Layout breakage | Elements collapsing or disappearing at a breakpoint, content pushed off-screen, overflow that hides something. |
| Broken states | Buttons stuck looking inactive, a form with no success or error message, a component that never resolves. |
| Page structure | Markup that’s gone wrong in a way you can see on the page. |
| Friction | Patterns that get in a visitor’s way or stop them finishing what they came to do. |
| Drift since launch | Things that have quietly degraded on a site nobody has looked at in a while. |
What Glitch doesn’t do
This matters as much as the list above, because it’s what’s still on you.
| He doesn’t | What that means for you |
|---|---|
| Fill in or submit forms | He sees how a form is built and flags faults in it. He can’t tell you whether it actually sends an email when someone hits submit. Test that yourself. |
| Watch the page live | He reads what the browser recorded while the page was captured, not the page as it runs. Errors that only fire when someone clicks, types or submits won’t be in that record. Ask for a live browser check in chat when you need one. |
| Test what happens server-side | Anything behind the page — logic, integrations, delivery — is outside what a check can observe. |
| Guess | If he can’t see evidence of a problem, he won’t invent one. A short list of real faults is the point. |
| Stray into other specialists’ work | Design is Pixel’s, copy is Lexi’s, accessibility is Navi’s, SEO is Index’s. |
Running a check
Glitch reads what the browser captured rather than the live page, so a check finds visible faults rather than ones that only appear when someone clicks.
Checking a single page
Instructions:
Checking a whole site
Instructions:
What comes back
Each fault arrives as its own task, grouped by desktop, tablet and mobile — so you can see at a glance that the footer link is broken everywhere while the form only breaks on phones. Every task says what’s wrong and points at the exact element.
Console findings sit in their own group rather than under a screen size, because they came from what the browser logged rather than from how the page looked at a particular width.
The check also closes with a plain summary of what was found, written in language you can pass on to a client.
Choosing what gets fixed
Nothing is repaired until you ask. When you’re ready, tell Atarim to work through the findings — and be specific about scope. “Just the critical ones.” “Only the mobile problems.” That instruction is read before anything is touched.
Instructions:
What comes with each finding
Alongside the description of what’s wrong, every finding carries the context a developer would otherwise have to go and gather.
| Captured | Why it matters |
|---|---|
| Screenshot | Shows the page as it was when the fault was found. |
| Element location | Identifies the exact element, not the general area of the page. |
| Screen size and browser | Explains faults that only appear on certain setups. |
| Status, priority and tags | Lets the finding move through your process like any other task. |
| The thread | Replies and decisions stay attached to the finding itself. |
A worked example
What Glitch finds: a link in the footer pointing at a page that was renamed three months ago.
What the fix is: the address is corrected. Nothing else.
The link element isn’t rebuilt, its container isn’t touched, and the footer isn’t regenerated. That restraint is deliberate: the smaller the change, the less there is to go wrong on a page you didn’t build recently and can’t fully remember. Where a proper repair genuinely would need more than the broken part, he says so and leaves the decision with you rather than making it.
How Glitch treats your site
This is the part clients ask about, and the part worth being able to answer confidently.
| Rule | What it means in practice |
|---|---|
| Fix the fault, not its surroundings | A broken link means the address gets corrected. He won’t rebuild the button, or the section it sits in. |
| Big fixes get raised, not made | If a proper repair would mean changing more than the broken part, he stops and suggests it instead of doing it. |
| Your live page stays up | He won’t unpublish it, rename it, change its address, or bin it to make room for a new version. |
| Rebuilds happen on a draft | Where something genuinely needs rebuilding, it’s built as a draft, checked, and swapped in once — only when you say so. |
| Three tries, then he asks | If a fix keeps failing he tells you, and asks whether you want it undone or left as is. |
| No silent reversals | He won’t quietly undo his own work and leave you wondering what changed. |
The console pass
Glitch has a check of his own beyond the visual one: the browser console.
Where console output is captured with the page, it’s reviewed as a separate pass — what the browser logged while the page was loading, read against the page it came from. These are the faults a visual scan can’t see because nothing on screen looks wrong.
| Condition | Why |
|---|---|
| Console output has to be captured | The pass runs on what was recorded alongside the page. No console data, no console pass. |
| Glitch has to be in the check | It’s his pass. If the preset didn’t include him, it doesn’t run. |
| It counts as its own pass | Like each screen size, it’s a separate piece of work in the check. |
Where Glitch works
Most people meet Glitch in a page check and assume that’s all he is. He turns up in three more places, and behaves differently in each.
| Where | What he does | How it starts |
|---|---|---|
| Page checks | Inspects the page and reports faults. Changes nothing. | Choose a preset, or pick him with Custom. |
| On the page | Answers questions about a specific element, and can apply the change there and then. | Click an element and ask. |
| In a task | Works inside a single task — investigating, fixing, and commenting the result. | Claro routes the work to him, or you ask in the task. |
| Workspace chat | Picks up bug work across all your projects and sites, with Claro coordinating. | Ask Claro; it routes anything broken to Glitch. |
On the page
Click an element on a page and ask Glitch about it, and he answers about that element specifically. Where he proposes a change, you get Show me and Do it buttons beneath it.
Show me puts the change on the page in front of you. You can toggle it off and back on to compare against the original, regenerate it if it isn’t what you meant, and take a screenshot of the result straight into the thread as a comment.
Do it applies the change with you approval — it queues and runs in the background rather than making you wait — and an Undo control then appears on that same comment if you want it back.
In a task
Glitch also works inside individual tasks. Claro assigns bug work to him, he investigates and fixes it, and the result lands as a comment on that task. You don’t have to be there while it happens — Claro carries the outcome back to you.
Working with a reply
Every AI answer carries a few controls beneath it. Alongside Show me and Do it you can copy the response, and mark it a good or bad response with the thumbs — that rating goes back to us and is how the specialists get better at the work you actually do.
The composer underneath has its own set of choices.
Comment posts normally.
Send to Claro hands your message to Claro instead, for when the thing you want isn’t this specialist’s job.
Add a note posts internally — only Admins and Team Members can see it.
Set internal task hides the whole task from guests and clients, with Unset internal task to put it back.
White-label behaviour
Working with the other specialists
Some faults you might expect from Glitch belong to someone else. Knowing the split saves you re-running checks looking for something he was never going to find.
| Specialist | Handles |
|---|---|
| Pixel | Spacing, alignment, and anything that simply looks wrong. |
| Navi | Missing alt text, keyboard navigation, contrast. |
| Lexi | Wording, tone, and calls to action. |
| Index | Page titles, descriptions, heading order, and search structure. |
| Claro | Turning vague feedback into clear work, and directing the rest. |
Frequently asked questions
Does Glitch find JavaScript errors?
Yes, where console output was captured with the page and Glitch is part of the check. It runs as its own pass over what the browser logged. It’s a read of that record, not a live debugging session.
Does he test whether my form actually works?
No. He checks how the form is built and flags faults in it. He doesn’t fill it in, submit it, or check whether the email arrives.
Will he change my site while checking it?
No. Checking never changes anything. Fixing is a separate thing you ask for, and changes needing sign-off wait for your approval.
Do I have to select Glitch every time?
No. Most presets bring him in automatically. Use Custom when you want to choose the specialists yourself.
What happens if a fix breaks something?
Every fix is checked afterwards, and anything unverified is reported as unconfirmed rather than done. After three failed attempts he stops and asks whether to undo it, rather than reversing his own work.
Will he ever take my page offline to fix it?
No. He won’t unpublish, rename, re-address or delete a live page. Rebuilds are staged as a draft and swapped in once, on your explicit approval.
Why did he only fix part of the problem?
Fixes are deliberately scoped to the fault itself. Where a proper repair would mean changing more than the broken element, he raises it as a recommendation rather than making a sweeping change on his own.
Can I use him on a site that isn’t WordPress?
You can check any page. Applying fixes needs the Atarim WordPress plugin on WordPress 6.9 or later.
Does Glitch only work in page checks?
No. He also answers on the page itself, works inside individual tasks, and picks up bug work across your projects from workspace chat. Only the page check is read-only — in the other places he can apply changes.
Why didn’t my change save?
Changes applied from the page save only on a connected WordPress site. Without the plugin, the same change shows as a live preview and disappears on refresh.
Will my client know they’re talking to Atarim?
Not in a white-labelled workspace. Glitch appears under your agency’s naming, and nothing a client reads is attributed to an AI.
Can I undo a fix later?
Yes, while the saved original still exists — a copy is kept before the change is applied, and undoing restores it. Each change affects one element, so there’s a single thing to put back. You’ll be told plainly if a change can’t be reversed.
What information comes with a finding?
A screenshot, the element it relates to, the screen size and browser it appeared on, and a status, priority and tags. Replies stay attached to the finding itself.
Can I check a whole site rather than one page?
Yes. A check can cover a single page or an entire site.
Can I send the findings to my client?
Every check ends with a plain summary you can pass on, and the page speed and accessibility tests produce their own downloadable reports. There’s no single downloadable file for the check as a whole. Individual findings are tasks, so they can also be assigned or copied into another tracker.
Which findings should I fix first?
Work in priority order: high (red) affects conversions and clarity, medium (orange) covers usability and hierarchy, and lower is cosmetic.
Does he replace a QA pass before launch?
No. He covers what’s visible on the page plus the console pass. Interaction testing, form delivery and anything that only fails on a specific user journey are still yours to check.
Common issues
- Glitch didn't take part in the check — the preset you chose probably didn't include him. Use Custom Preset and select him directly.
- He missed a bug you know about — if finding it needs clicking or submitting, it's outside what a check can see. If it was a console error, check console output was captured and that Glitch was in the review.
- A form is broken but nothing was flagged — he checks how forms are built, not whether they send. Submit it yourself to test delivery.
- A fix won't apply — check the site is on WordPress 6.9 or later, and that nothing is sitting waiting for your approval.
- He flagged something already fixed — run the check again. Findings reflect the page as it was when it ran.
- Nothing changed after a check — expected. Checks never change anything. Ask for the fixes separately.
- You only checked one page and wanted the site — run the check against the whole site rather than a single page.
- Undo isn't available on a change — the saved original is no longer there. Restore from a backup instead, either the whole site or just part of it.
- A change vanished when you refreshed — the site isn't connected, so it applied as a preview only. Connect the plugin to save changes.
- A fix is marked unconfirmed — he couldn't verify it worked, so he's told you rather than claiming success. Check that one by hand.
Conclusion
Glitch covers the faults that are visible on a page and easy to miss — dead links, missing assets, forms and controls that aren't built the way they look. He finds them across every screen size, and repairs them when you ask, without touching anything you didn't ask about.
What he doesn't cover is worth holding onto: interactions, form delivery, and anything that only goes wrong once someone starts using the page are still a manual job. Used with that in mind, he removes the tedious half of a QA pass and leaves you the half that needs judgement. And he isn't confined to checks — you can point at a broken element on any page and have him fix it there. Explore How to Run an AI-Powered Page Review.
Tips & best practices
- Don't read a short report as a shallow one — he won't invent findings to fill space.
- Run him once the page is close to finished, not while it's still being built.
- Ask for fixes in batches so you can actually read the approvals.
- Put a check on a schedule for every site you look after — drift is what he's good at catching.
- Make sure console output is captured if you want the console pass, and still test the journeys that matter by hand.
- Submit your own forms to test delivery, especially on anything that takes payment.
- Tag his findings so they're easy to pull up during release tracking.
- Run him alongside the other specialists rather than on his own.
- Use Show me on the page when a client needs to see the fix before agreeing to it.
- Connect the plugin before a working session, so changes save instead of vanishing on refresh.
- Re-run a check after fixing things by hand, to confirm what's left.
- Undo promptly if a change is wrong — it relies on the saved original being there.
- Pass the check summary on to clients on care plans — it shows the work that would otherwise be invisible.
- Keep your own off-site backups regardless of the protections built in.