Role Design + build · AI-native
Stack TypeScript · MCP · npm
Year 2026
Ship npm · Open source
$ review_jp_ui · ai-generated registration page
19/100 FAIL 8 findings · 2 spec · 6 convention
  • SPEC · JLReqtext-align: justify on Japanese text. Browsers lack print-quality CJK justification, so spacing goes uneven. Use left-align. W3C JLReq §3
  • SPEC · JISword-break: keep-all not set. Text can break at illegal positions (punctuation at line start). JIS X 4051 kinsoku
  • CONVENTIONline-height: 1.2 is too tight for kanji. Set 1.8 or more.
  • CONVENTIONfont-size: 13px sits below the 14px kanji legibility floor.
  • CONVENTIONNo Japanese font in the stack. Kanji falls back to whatever the OS provides.
review_jp_ui scoring AI-generated CSS against the standard. Each finding marks hard spec (JLReq / JIS) separately from documented convention, so authority is never overstated.
One surface, up close. The registration form an agent writes by default, beside the one the tool corrects it into.

I have been building sites with AI, and the same thing kept happening: the output looks right in English and quietly breaks in Japanese. Line-height too tight for kanji. No Japanese font in the stack, so characters fall back to whatever the OS happens to have. Text set to justify, which browsers cannot do well for CJK. Sub-14px kanji. And on every form, the reversed name order and the single combined phone field. None of it is the model's fault. The conventions just are not in its training data densely enough to beat the English defaults.

Years on Japanese products had given me that checklist in my head. The first version of this tool wrote it down as generators an agent could call: ask for a Japanese form, get correct markup back.

Generating a correct form solved the easy half. The harder half runs the other way. Once an agent has written a page, nothing tells it the page is wrong for Japan. It cannot see its own 1.2 line-height or its justified paragraphs.

So the tool became a checker. Point it at real CSS and markup and it scores them against the actual standards, the W3C Requirements for Japanese Text Layout and JIS X 4051, and hands back every violation with its fix. The form generator is still inside. It is now one tool among the checks.

01

Spec and convention, never blurred

Some of these rules are law. Line-breaking is specified in the W3C JLReq and JIS X 4051. Others are documented practice, like 1.8 line-height for kanji. Every finding says which it is and cites the source, so the tool never dresses a preference up as a standard. For something an agent will apply without arguing, that line is the whole point.

02

Catch, not just generate

Producing a correct component is useful. Catching an incorrect one is more useful, because that is the failure that actually ships. The core tool reads code the agent already wrote and returns a score with line-level fixes, so correctness can happen at review, not only at generation.

03

Cover the mistakes AI actually makes

I did not try to encode all of Japanese web design. I targeted the surfaces where AI output reliably breaks: typography, line-breaking, colour, forms, keigo, trust. Each is narrow enough to be prescriptive about.

04

No keys, no network

Every rule, prefecture, name, and postal code ships inside the package. Running it needs only npm. No auth, no quota, no outbound calls.

Open source on GitHub, published on npm, now at v2.0.0. Validated Premium on the lobehub MCP directory. About 440 monthly downloads as of April 2026. Scaffolded with Claude Code; the tool design, the spec research, and every ship decision are mine.

npm · japan-ux-mcp GitHub lobehub
Most design systems live in a document a person reads once. Turning mine into tools an agent could call was the first step. What I did not expect was that the more valuable direction was the opposite one: not producing correct Japanese UI, but catching incorrect Japanese UI in code already written. A style guide that can grade its own output.
Next PayPay MCP