Add restraint pass and rendered review to the pajamas skill

What does this MR do?

Updates the pajamas skill in .claude/skills/pajamas/SKILL.md, which @gitlab/create-ui ships in the starter template.

• Adds a third non-negotiable: correct component usage is the floor, not the bar. A screen can use every component as documented and still be cluttered and off the spacing scale.
• Adds a "Building a screen" section. Read before you write (no markup until the pages have been read this session). A hierarchy of reuse: the project's existing layout and chrome, then the pattern for the kind of screen, then @gitlab/ui components, and only then utilities on plain elements. Screen-level work reads the foundations (layout, spacing, type, color) and the pattern page, styles with token-backed utilities only, takes icons and illustrations from the libraries instead of drawing or generating imagery, and writes copy to the UI text guidance.
• Extends the no-guessing rule past props, slots, and events to token, utility, icon, and illustration names: read them, and when nothing matches say so rather than substituting a near miss.
• Adds a restraint pass to the review steps: the usual tells of generated UI, each tied to the Pajamas page that rules it out. Removing an element is a normal review outcome.
• Adds a rendered review: screenshot the running UI and hand it to a critic, a fresh subagent that sees only the screenshots and a design.gitlab.com baseline. It asks for prioritized gaps and a score and stops after two rounds.
• Cites rules by section anchor (components/badge#when-not-to-use), not just by page, so a reviewer can check the claim.
• Adds prototype to the skill's trigger description, plus a patch changeset for @gitlab/create-ui.

Why

Chad Vavra shared Anshu Chimala's post, https://www.lennysnewsletter.com/p/how-to-turn-your-ai-into-a-world, and said he was thinking of it in relation to the pajamas skill. Two parts of it apply to a design-system context. The first is the critic loop: the model that built a screen is a poor judge of it, so a separate model should judge screenshots, not code, against an objective bar. Pajamas already gives us that bar in the rendered examples on design.gitlab.com and in GitLab.com itself. The second is the "cut what doesn't add value" pass. Models add and rarely remove, and until now the skill only checked how each component was used, never whether the composed screen was any good.

I left out the post's variety techniques (seed strings, "ambitious" prompts, image and video generation). They aim at one-of-a-kind screens, and Pajamas wants the opposite: one product, shared foundations, restraint. The post's last section, "Remove AI tells", is paywalled, so the tells list in the skill comes from the Pajamas pages rather than from the post.

Jeremy Elder then shared a second set of sources in the follow-up thread (https://gitlab.slack.com/archives/C0BS7HJM4G3/p1788358341404149, internal), and a few things from those are in here too:

• https://brandstructure.design/articles/reference-and-guidance/ splits design system documentation into reference (what a component is, checkable) and guidance (what to do with it, authored), and points out that composition rules above the component (a template, a journey) have no home in any of the component spec formats. In the skill, the "Building a screen" section is that composition layer, and the closest thing Pajamas has to it is the patterns. It also argues rules should be citable by id, which is where the section-anchor citation comes from.
• The component spec projects it surveys (DSDS, specs, DS Contracts, uSpec, Spektral) all extract reference deterministically from source rather than inferring it, and DS Contracts in particular refuses rather than invents when something doesn't exist. The skill already reads source for props, slots, and events; this extends the same rule to token, utility, icon, and illustration names.
• The "How the design system stops an agent from hallucinating UI" diagram (a Claude artifact Jeremy linked, from the AI & Design Systems course) runs a request through stations: ground before generating, rules from layered files, consult live truth over MCP, and compose by forking the largest existing thing (page template, then recipe, then component) rather than building from primitives. The read-before-you-write rule and the hierarchy of reuse come from there.
• https://github.com/bradfrost/skills, which Jeremy added afterwards. Its ds-inspection skill is a tool to run against Pajamas itself (stations 9 and 10 are the AI-readiness ones: machine-readable docs, agent access, and "the generation test": hand an agent the docs, ask for a settings form, watch where it trips). That's a separate exercise from this MR, but its product-inspection skill has a visual design station whose checklist I borrowed for the critic: one dominant element per screen, the same construct rendered the same way everywhere, alignment of edges and baselines, icon size and placement, and both color modes. Its "loading, empty, error, success" states check became a bullet in "Building a screen", pointing at the loading, empty-states, and saving-and-feedback patterns. Two of its ground rules are in here too: an evidence chain for the rendered review (browser tool, then user screenshots, then code-only, and say which), and the split between mechanical gaps the agent fixes and design decisions the agent puts to the user.

Related MRs

• !6296 (merged) (Adam Ferch) widens the skill's trigger and adds a tokens-only-projects section. Both MRs touch the frontmatter description, so whichever merges second will need a small conflict resolution. I've kept my description change to one added word so that's easy.
• !6278 (merged) (Scott de Jonge) adds a css skill. Once it merges, the styling bullets in "Building a screen" should route to it instead of repeating it.

Still to do before this leaves draft

I haven't run the generation test yet: a fresh create-ui prototype, a settings form and a list page built with the updated skill, and a log of where it trips. I want to do that, and check that a subagent can actually take a screenshot in that setup, before I mark this ready. The failure log is also the next round of edits to the skill.

Follow-ups, not in this MR

• Chad Vavra suggested an "art director" skill that other skills call on. The rendered review section is the seed of that; if it works, it probably wants to be its own skill rather than a section of this one.
• Pajamas has component pages and patterns but nothing at the template or journey level, which is the gap the brandstructure article names. That's a docs question, not a skill one.
• Chad Vavra's other point stands: this is art direction in a prompt, and the parts that are mechanically checkable (hard-coded colors, spacing off the scale) belong in lint or CI, not in a skill.
• Run ds-inspection stations 9 and 10 from https://github.com/bradfrost/skills against Pajamas itself. That answers "how AI-ready is the design system" with evidence rather than with this skill's opinion.
• The bradfrost skills are shaped as an orchestrator SKILL.md plus one self-contained file per station. That's the shape for the "entrypoint skill plus granular skills" idea Scott and I have been discussing: a pajamas orchestrator with separate files for component API, building a screen, the restraint pass, and the rendered review, loaded as needed.