メニュー
Page and screen testing skill. Tests that composed pages have correct layout structure (header, main, footer, nav), all required sections are present, responsive metadata exists, and token binding is consistent. Use when verifying a composed view or screen. Writes a .test.ts file and runs vitest.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | test-page |
| description | Page and screen testing skill. Tests that composed pages have correct layout structure (header, main, footer, nav), all required sections are present, responsive metadata exists, and token binding is consistent. Use when verifying a composed view or screen. Writes a .test.ts file and runs vitest. |
Page testing verifies the structural integrity of composed pages and screens. It checks landmark roles, section presence, responsive support, navigation, and token binding across the entire page.
| Function | What it checks |
|---|---|
checkPage(html, render) | Composite: structure + sections + responsive + tokens |
assertPageHasSections(html, sections) | Required landmark roles, IDs, or text |
assertHasPageStructure(html) | Header, main, footer landmarks |
assertHasNavigation(html) | Nav element, links, or menu role |
assertHasResponsiveMeta(html) | Viewport meta or @media queries |
assertPageTokenBinding(render) | No raw hex colors outside allowed set |
// Define expected sections as an array:
const sections = [
{ role: 'banner', required: true },
{ role: 'navigation', required: true },
{ role: 'main', required: true },
{ role: 'contentinfo', required: true },
{ text: 'Dashboard', required: true },
{ selector: '[data-testid="stats-section"]', required: false },
];
assertPageHasSections(renderedHtml, sections);
skills/test-engineering/test-scenarios/craft-page.tsskills/test-engineering/test-scenarios/craft-sections.tsskills/test-engineering/test-scenarios/responsive.tsnpx vitest run src/__tests__/<Name>-page.test.ts --reporter=json
| Assertion | Common failure | Fix |
|---|---|---|
assertHasPageStructure | Missing <header>, <main>, or <footer> | Add landmark elements to the page layout |
assertPageHasSections | Required section not found | Add the missing section component |
assertHasNavigation | No nav/link/menu elements | Add navigation component |
assertHasResponsiveMeta | No viewport meta or @media | Add <meta viewport> or responsive CSS |
Infer a design system's tokens + voice from a brand reference (screenshots or a URL) — vision-assisted. Use for /mds:system:create --mode extract, feeding the design-system-author skill.
Reason about color on-system — pick/adjust accent, surfaces, and status colors within a design system's palette, check contrast/accessibility, and propose token changes (not raw hex). Adapted from open-design's color-expert. Use for color decisions during build, review, or system edits.
Build a reusable, on-system React+Tailwind component from an intent. Use when creating or editing a component in emdesign. Composes design-system primitives from "@ds", references token roles only, emits a CSF story, and feeds the verify loop.
Author or maintain a design system's DESIGN.md + tokens.css (the contract). Use when fixing the SYSTEM rather than a component — adding tokens, tightening anti-patterns, or capturing visual rules. Adapted from open-design's design-md (Google Labs / Stitch).
Designer-who-codes visual audit + fix. Use to tighten a component before shipping — run the four-source critique, then make atomic, on-system fixes with before/after screenshots. Adapted from open-design's design-review (gstack) to emdesign's code-first loop.
Create or update a design system to the emdesign quality bar — author the 9-section DESIGN.md + tokens.css + base primitives. Use for the System flow (/mds:system:create | :update). Knows the four sources: brief, blank, import, extract.