Design system check in pull requests: notes, blocking

Once the design system in code is connected, FISYCO reviews every pull request in the project's repository against it. It leaves one comment with design system notes and posts a FISYCO design system check on the latest commit. By default the notes are suggestions; you can make the check block merging.

Before you start

A repository is connected to the project. See Connect a repository.
The design system in code is connected and indexed at least once. See Connect the design system in code. Until the first index finishes, the review stays silent: there is nothing to compare with.
On GitHub, the FISYCO GitHub App needs the Checks: read and write permission to post the check. Without it, the comment still appears.

What the review looks at

FISYCO runs the review when a pull request on GitHub, a merge request on GitLab or a pull request on Bitbucket is opened, reopened or gets new commits. It reads only the .tsx and .jsx files the pull request changes, at the latest commit, up to 60 of them. Files outside the pull request are not read.

Those files are compared with the latest index of your design system, the token, icon and illustration libraries connected to it, and your team's rules.

Note	What triggers it
Your team's design system rules	a component your rules hide, or text your team listed as forbidden in code
This already exists in your design system	a component outside the design system that closely matches one inside it; the note names that component and, when it can, an example of its use
Deprecated components	a component marked deprecated, with its replacement when one is known
Colours written past the tokens	a colour written as a value, with the matching token when there is one; a raw scale token instead of a semantic one; a px spacing value that equals a token
Icons inlined instead of taken from the library	an `<svg>` pasted into the code or an SVG file used as an image, with the library asset when it matches
Shared components changed here	a changed design system component that is used elsewhere, with how many places and files use it

Each note links to the file and line. One comment holds up to 12 notes, with your team's rules listed first.

The comment and the check

One comment per pull request. FISYCO edits it on every push instead of adding new ones. If a push resolves all notes, the comment says the earlier notes are resolved. A pull request that never had notes gets no comment.
One check on the latest commit. Without notes it passes. With notes it is neutral: visible, but not red.
GitLab shows a commit status and Bitbucket a report, both named FISYCO design system. Neither has a neutral state, so with notes they still pass, and the description gives the count.

Every completed review is also recorded in the design system's Activity log as Pull request checked.

Make the check blocking

Open the project, find Design system in code under From code and go to Settings.
In Pull request check, turn on Block merging while design system notes remain. Only workspace admins can change it.
In your repository's branch protection rules, mark FISYCO design system as a required check.

With the setting on, the check fails while notes remain, on all three hosts, and the comment says your workspace requires it to pass. It stops a merge only after step 3, because it is the branch protection rule that blocks merging.

Start with the default. Watch which notes people fix and which they ignore, tune your team's rules, and turn on blocking once the notes are trusted.

Your team's rules

The same Settings page has Rules for AI agents. The review follows them too: hidden components, deprecated components, text that is forbidden in code, and whether colours and spacing must go through tokens. If your team turns off Colors only through tokens, colour values stop producing notes. The same rules reach AI agents through the FISYCO MCP server. See Rules for AI agents.

The conversation in FISYCO's own pull requests

When FISYCO opens a pull request with a patch, it also answers comments there. This works on GitHub and covers comments, line comments and reviews.

A question or remark gets a reply listing what the pull request changes, taken from the same record as its description.
Approvals and thanks, such as "LGTM" or an emoji, get no reply. Neither do messages from bots.
FISYCO never rewrites the branch because of a comment. The branch belongs to your team, so a requested change is yours to make.
Pull requests opened by people get no replies: there FISYCO only runs the review above.

How patches are prepared and when they open is covered in Patches and autonomy.