chromaui/chromatic

Reads the open reviewer comment threads on a Chromatic build, maps each one to its story and component, makes the changes the reviewers asked for, and drafts a reply for each thread. Use when a Chromatic build has comments or discussions, when a reviewer left feedback on snapshots, or when the user asks what reviewers said about their UI in Chromatic or asks to reply to or resolve a reviewer's thread.

Says whether a branch is ready to merge from Chromatic's side, by checking its latest build against the current commit, broken and denied tests, changes still waiting for review, open reviewer comments and new accessibility violations, and lists what is left. Use when the user asks if their branch or pull request is ready to merge, what is blocking the Chromatic check, or what is left to do before merging, and before you merge a pull request yourself in a repository tested by Chromatic.

Checks that this repository is connected to the right Chromatic project and that the project is set up to test it, by comparing the project's framework, linked repository, enabled features and recent builds with the repository's own config, CI and git remote. Use when the user asks whether Chromatic is set up correctly, when Chromatic tools return a project that looks unfamiliar, when builds are missing or stale, after connecting a new project, or when the user asks to change a project setting such as UI Tests, browsers or accessibility tests.

Finds which Chromatic project this repository belongs to with a read-only lookup from the git remote, then records the id in chromatic.config.json so every Chromatic tool knows which project to ask about. Use before asking the user for a project id, whenever a Chromatic tool needs a projectId and chromatic.config.json is missing or has none. Use also when the user asks to connect a Chromatic project, asks which project a repository uses, or shares a link to their Chromatic project.

Before building a new UI component, checks the repository and the project's published Storybook on Chromatic for one that already does the job, and reports the closest matches with links to their stories. Use when the user asks for a new component, asks whether one already exists ("do we have a date picker?"), or when about to write a component that a design system might already provide.

Finds the accessibility violations a Chromatic build reported, fixes them in the component source, and verifies the fix on the next build. Use when a Chromatic build reports accessibility changes, when CI fails on a11y, or when the user asks which stories have accessibility violations or got worse, asks to fix axe or WCAG violations, or asks whether a pushed fix cleared them.

Finds the stories a Chromatic build could not capture, reads each capture error (render and interaction timeouts, JavaScript errors, failed play functions, missing or off-page stories, oversized snapshots), fixes the cause in the repository, and verifies on the next build. Use when a Chromatic build is BROKEN, reports component errors or capture errors, or when CI fails on Chromatic with errors rather than visual changes.

Reports the latest Chromatic build for this repository's project, on the current branch unless another is named. Use when the user asks what Chromatic thinks of their branch, whether the build passed or is still running, for the build id the accessibility tools need, or right after a push to see whether Chromatic has built the new commit.

Answers questions about Chromatic data with a read-only GraphQL query, such as a build by its number, the tests on a build by status, how many tests are pending or broken, which Chromatic user is signed in, reviewer comments, quarantined stories, or the components in a published Storybook. Use before calling chromatic_query or chromatic_search_schema, because it holds tested queries for these questions and the API rules that make a guessed query fail. Never reads the project token or the Figma token, which are secrets.

Shows where a Chromatic project's snapshots go, by component, story, mode and browser, and proposes story parameter changes that cut them without losing coverage the team relies on. Use when the user asks why Chromatic uses so many snapshots, how many snapshots the project uses, how to lower the bill or stay under the plan, why a build was limited and took no snapshots, or which stories cost the most to test.

Reviews the visual changes a Chromatic build is waiting on, compares each changed snapshot with the code change on the branch, and shows the person which changes look intended and which look like regressions, with before, after and diff pictures. Use right after you push or open a pull request that changes components, styles, tokens or stories, when a Chromatic build is PENDING, when CI reports visual changes, when the user asks what changed visually or whether Chromatic's changes are expected, before merging a pull request that has a Chromatic check, and before you accept or deny any change in Chromatic, including on a go-ahead such as "ship it", and after Chromatic declines one because a newer build superseded it. Accepts or denies changes only when the user asks for that by name.

Runs a Chromatic build from this machine with the Chromatic CLI, limited to the stories being worked on, waits for the result, and reports it, so a fix can be verified without pushing and waiting for CI. Use when the user asks to run Chromatic, to verify a fix on Chromatic now, or to check why TurboSnap tested more stories than expected.

Lists a Chromatic project's quarantined stories and the tests a build ignored as unstable, finds what makes each story render differently from run to run, and fixes the cause in the story or component. Use when the user asks about flaky, unstable or quarantined stories in Chromatic, asks to quarantine a story or take one out of quarantine, asks why a story keeps showing changes nobody made, or whether a quarantined story can come back. Quarantines or unquarantines a story only when the user asks.