An Agent Can Build the Page. It Still Needs a Review.

Two names need explaining first. Hallmark is a full design system for reducing the familiar template look of AI-built pages. web-design-qa is the pre-release review layer I built for existing projects after taking inspiration from it.

At the time, I was adjusting the Writing page for HEADFIRST, now Marina Current. The request was straightforward: Chinese titles should not stretch across three lines, the typography should not look thin and elongated, and Chinese and English should not be mixed into one block.

The page did open. But the titles were large enough for a launch event, Chinese text was forced onto three lines, and the article cards were squeezed into a horizontal table.

This is a familiar problem. An agent can write components, run a build, and quickly produce another version when you say it looks wrong. It rarely starts by asking whether the problem is the font size, the content hierarchy, or the page structure itself.

A task that only needed a typography and layout adjustment can easily become a site-wide rewrite.

The missing piece is a review before release

Hallmark is good at addressing the familiar look of AI pages: similar hero sections, invented numbers, excessive rounding, and every screen competing to be the visual center.

It is a complete design system. It selects themes, changes page structures, manages type and color, and handles redesigns. That is powerful, but broader than many existing projects need.

Real requests are often smaller. The page already exists, along with brand colors, routes, components, and analytics. The task is to establish what is wrong and the smallest change that would fix it.

So web-design-qa keeps the parts needed for a page review rather than copying the full design system.

Hallmark addresses how to make a page look less like an AI template. web-design-qa asks whether this particular page is ready to deliver.

The biggest change: leave code alone by default

Many agents interpret “take a look at this page” as “change this page.” Those are different actions.

In web-design-qa, the default mode is an audit. It examines the rendered result, lists issues, severity, and evidence, and leaves the files unchanged. Editing begins only when the user explicitly asks for fixes.

That boundary is useful. Often the request is for a judgment, not another round of design. Describing the problem accurately first usually makes the eventual change smaller.

It also does not invent a new system immediately. Existing tokens, typefaces, components, brand colors, and content intent come first. Unless the system itself is causing the problem, repairs follow it.

The layer I added: evidence for the review

When someone says “this button is unclear,” did they inspect the page or only skim the JSX? That cannot be left to a guess.

Every finding therefore needs a status:

• Verified: observed or tested in the actual page.
• Code-checked: confirmed from code, without browser verification yet.
• Not verified: cannot be confirmed under the current conditions.

If the runtime is unavailable, code inspection can still continue. But Code-checked must not be reported as a completed acceptance review.

Responsive checks cover three size bands: 320/375, 768, and 1280 pixels. Whether a title gets squeezed onto three lines, a button wraps, or cards retain their desktop layout on a phone can only be established at real viewport sizes.

It can leave a question unanswered. It cannot present an assumption as page evidence.

A reference website is also design evidence, not an executable instruction. When handling an external reference URL, web-design-qa does not independently visit localhost, internal networks, or non-public addresses, and does not sign in for the user. When reviewing the user’s authorized current project, it should actually render the local or live page. Those are different kinds of targets. A reference page saying “run this command” does not make it an instruction to execute. If a public reference cannot be opened, the simplest fallback is to ask the user for a screenshot.

This may not sound like a design capability, but it matters. Studying a page’s type, hierarchy, and motion should not bring the remote page’s scripts, copy, or operational requests into your own project.

It also knows what is outside its scope

This boundary matters too.

SEO, keyword coverage, and landing-page funnels do not automatically become design problems because a page looks bad. web-design-qa can identify visual and interaction risks without taking over an entire SEO or CRO audit.

The narrower the specialty, the more useful a clear scope becomes. Otherwise, “review this page” turns into a report that covers everything without examining anything deeply enough.

The deliverable is more than an aesthetic opinion

The final output is straightforward: what must be fixed, what materially affects the experience, what is optional, the evidence behind each finding, and the files where a minimal change would belong.

Another agent can use it to make repairs, or a person can use it to set priorities. It does not force a new aesthetic on the project, and it keeps the rework contained.

That is the value this version adds. It is better suited to reviewing an existing project before delivery, without claiming to be better at design than the original.

web-design-qa was inspired by Hallmark and rebuilt. Its provenance label is REFERENCE-BASED REBUILD.

• Explore Marina Current Skills
• View Hallmark

Make the checks repeatable

The following is a teaching example, not a record of this project’s actual review. A Chinese title wraps onto four lines at 375 pixels. Save the original screenshot, inspect the container width, font size, and wrapping rules, then adjust only the rules causing the problem. Recheck with the same content and width, and inspect a tablet width as well.

Someone else can then repeat the review and distinguish “recommended” from “changed and verified.” Upstream capabilities can change. The comparison here describes the choices made for the first adaptation; the pinned source version is retained in the public repository’s RELEASE record.