agentsclimarketplace

Responsive ui testing

Skill soden46/syarif-laravel-ai-skills/skills/responsive-ui-testing

Audit Laravel responsive UI with Playwright across mobile, tablet, desktop, Livewire states, overflow, clipping, forms, tables, modals, and navigation.From its SKILL.md

Install
npx -y skills add soden46/syarif-laravel-ai-skills --skill responsive-ui-testing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.4 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it

Responsive UI Testing

Use this skill when asked to test whether a Laravel application interface is responsive, mobile-friendly, or visually stable across screen sizes.

Do not conclude that a page is responsive merely because it loads on one mobile viewport or has no JavaScript errors.

Primary Goals

Verify that the application remains usable and visually correct across:

  • small mobile
  • standard mobile
  • large mobile
  • tablet portrait
  • laptop
  • desktop
  • wide desktop when the project has wide layouts or dashboards

Required Viewports

Test at least these viewports:

TargetWidthHeight
Small mobile320568
Standard mobile375812
Large mobile430932
Tablet portrait7681024
Laptop1366768
Desktop19201080

Also test Playwright mobile device profiles when available, such as an iPhone and a Pixel device.

Required Checks

For every tested page and viewport:

  1. Navigate to the page and wait until network, fonts, images, and Livewire activity settle.
  2. Check for horizontal document overflow.
  3. Check whether visible elements extend outside the viewport.
  4. Detect clipped, overlapping, or unreadable text.
  5. Verify the navbar does not stack into unusable controls.
  6. Verify the sidebar can open and close on small screens.
  7. Verify forms can be completed without horizontal scrolling.
  8. Verify buttons and links remain visible, clickable, and large enough for touch.
  9. Verify tables have deliberate mobile behavior such as horizontal scroll, stacked cards, hidden secondary columns, or a redesigned mobile layout.
  10. Verify modals, dropdowns, date pickers, and select menus fit inside the viewport.
  11. Verify fixed and sticky elements do not cover important content.
  12. Verify images keep their intended aspect ratio and do not stretch or crop important content accidentally.
  13. Interact with Livewire components and repeat layout checks after state changes, validation errors, pagination, filtering, sorting, loading states, and empty states.
  14. Test dark mode when the project supports it.
  15. Capture screenshots for review.
  16. Report failures with page, viewport, browser or device, selector, and evidence.

Horizontal Overflow Check

Use a browser-side assertion like this:

const overflow = await page.evaluate(() => ({
  scrollWidth: document.documentElement.scrollWidth,
  clientWidth: document.documentElement.clientWidth,
  hasOverflow:
    document.documentElement.scrollWidth >
    document.documentElement.clientWidth + 1,
}));

expect(
  overflow.hasOverflow,
  `Horizontal overflow: ${overflow.scrollWidth}px > ${overflow.clientWidth}px`,
).toBeFalsy();

Element Boundary Check

Inspect visible elements and report those extending outside the viewport:

const offenders = await page.evaluate(() => {
  const viewportWidth = window.innerWidth;
  const viewportHeight = window.innerHeight;

  return Array.from(document.querySelectorAll("body *"))
    .filter((element) => {
      const htmlElement = element as HTMLElement;
      const style = window.getComputedStyle(htmlElement);
      const rect = htmlElement.getBoundingClientRect();

      if (
        style.display === "none" ||
        style.visibility === "hidden" ||
        rect.width === 0 ||
        rect.height === 0
      ) {
        return false;
      }

      return (
        rect.left < -1 ||
        rect.right > viewportWidth + 1 ||
        rect.top < -1 ||
        rect.bottom > viewportHeight + 1
      );
    })
    .slice(0, 50)
    .map((element) => ({
      tag: element.tagName.toLowerCase(),
      id: element.id,
      className: String((element as HTMLElement).className),
      text: element.textContent?.trim().slice(0, 80),
      rect: element.getBoundingClientRect().toJSON(),
    }));
});

expect(offenders).toEqual([]);

Treat fixed-position overlays and intentionally scrollable containers carefully. Do not automatically mark deliberate off-canvas navigation as a failure.

Playwright Test Skeleton

Create or update a project-local browser test such as tests/e2e/responsive.spec.ts when the project uses Playwright:

import { expect, test } from "@playwright/test";

const viewports = [
  { name: "mobile-320", width: 320, height: 568 },
  { name: "mobile-375", width: 375, height: 812 },
  { name: "mobile-430", width: 430, height: 932 },
  { name: "tablet-768", width: 768, height: 1024 },
  { name: "laptop-1366", width: 1366, height: 768 },
  { name: "desktop-1920", width: 1920, height: 1080 },
];

const routes = ["/dashboard", "/settings"];

for (const viewport of viewports) {
  test.describe(viewport.name, () => {
    test.use({ viewport });

    for (const route of routes) {
      test(`${route} is responsive`, async ({ page }, testInfo) => {
        await page.goto(route);
        await page.waitForLoadState("networkidle");
        await page.evaluate(() => document.fonts?.ready);

        const overflow = await page.evaluate(() => ({
          documentWidth: document.documentElement.scrollWidth,
          viewportWidth: document.documentElement.clientWidth,
        }));

        expect(
          overflow.documentWidth,
          `Horizontal overflow on ${route}`,
        ).toBeLessThanOrEqual(overflow.viewportWidth + 1);

        await expect(page).toHaveScreenshot(
          `${route.replaceAll("/", "-") || "home"}-${testInfo.project.name}.png`,
          { fullPage: true, animations: "disabled" },
        );
      });
    }
  });
}

Adapt routes to the real Laravel app. Seed deterministic data and authenticate through existing project helpers before asserting protected pages.

Visual Regression Rules

Use screenshots for stable pages after:

  • disabling animations
  • freezing or mocking dynamic timestamps
  • using deterministic seed data
  • hiding unstable third-party widgets
  • waiting for fonts and images
  • avoiding screenshot comparison across inconsistent operating systems

Laravel-Specific Checks

Inspect:

  • Blade layouts and components
  • Livewire components after state changes
  • validation error messages
  • authorization-dependent navigation
  • paginated tables
  • flash messages
  • file-upload components
  • loading indicators
  • empty states
  • long translated strings
  • Tailwind or FlyonUI breakpoint classes
  • dark mode variants when configured

Reporting Format

Group findings by severity:

  • Critical: the page cannot be used at a tested viewport.
  • Major: important content or controls are clipped, inaccessible, overlapping, or impossible to operate.
  • Minor: visual spacing or alignment is degraded but functionality remains usable.

For every issue include:

  • route or page
  • viewport
  • browser or device
  • affected component
  • expected behavior
  • actual behavior
  • screenshot path
  • probable source file
  • recommended fix

Completion Gate

Do not declare the application responsive unless:

  • all required viewports were tested
  • no unexplained horizontal document overflow exists
  • navigation, sidebars, and core forms remain usable
  • tables and modals have deliberate mobile behavior
  • interactive Livewire states were tested
  • dark mode was tested when supported
  • failures and untested pages are explicitly reported

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most design frontend skills give in ~1.5k tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

  • Use CSS variables for color consistencyin 72 of 1169, across 23 files
  • Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
  • Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
  • Add atmospheric background effects and texturesin 57 of 1169, across 9 files
  • Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
  • Implement real working codein 55 of 1169, across 7 files
  • Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
  • Launch chromium in headless modein 47 of 1169, across 4 files
  • Close the browser when donein 47 of 1169, across 4 files
  • Run provided scripts with help flag firstin 47 of 1169, across 4 files
  • Wait for network idle statein 47 of 1169, across 4 files
  • Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

  • test at least six required screen sizes
  • detect clipped, overlapping, or unreadable text
  • verify forms can be completed without scrolling
  • verify tables have deliberate mobile behavior
  • verify modals fit inside the viewport
  • interact with livewire components and repeat checks

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,834. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.