sight

Foundry integration: This skill is invoked by Foundry's F2 INSPECT phase as the sight stream. SIGHT runs in the main thread (Playwright MCP requirement). When run from F2, findings are filed through the Foundry-Defect door and land in foundry-archive/{run}/defects.json; sight never writes that file itself. When run standalone, findings are written as a report. Skip with --no-ui.

/foundry:sight — Deep Browser UI Audit

Sight uses Playwright MCP to deeply exercise a web application. It doesn't just visit pages — it clicks every button, fills every form, opens every dropdown, expands every accordion, triggers every modal, and watches what happens. It reads console logs, tracks network requests, and documents everything that's wrong.

Think: a meticulous QA engineer or a frustrated user trying to break things.

Supports headed mode (GUI) and headless mode (CI/remote).

Prerequisites

• Playwright MCP configured in .mcp.json with devtools enabled:

  Headed (default — GUI available):

  {
    "mcpServers": {
      "playwright": {
        "command": "npx",
        "args": ["@playwright/mcp@latest", "--caps", "vision,devtools"]
      }
    }
  }
  

  Headless (no GUI / CI / remote server):

  {
    "mcpServers": {
      "playwright": {
        "command": "npx",
        "args": ["@playwright/mcp@latest", "--headless", "--caps", "vision,devtools"]
      }
    }
  }
  

• The target page must be accessible (running locally or deployed)

Invocation

Command	Behavior
/foundry:sight <url>	Deep audit, document findings
/foundry:sight <url> --parity <reference>	Compare against a reference design or URL

Core Principle: Exercise Everything AND Verify Outcomes

DO NOT just visit a page, glance at it, and move on. For every page:

1. Find ALL pages — don't rely only on visible navigation. Read the app's router config to discover every defined route and visit it, even if it's not linked in the UI.
2. Read the DOM snapshot — understand every element on the page
3. Interact with every interactive element:
   • Buttons: click them. What happens? New console errors? Network calls? Modal?
   • Links: where do they go? Do they 404?
   • Form fields: type into them. Do they validate? What happens on submit?
   • Dropdowns/selects: open them. Are options populated? Do they filter correctly?
   • Toggles/switches: flip them. Does state change? API call fire?
   • Tables: check every column. Are cells empty? Do sort headers work? Does pagination work?
   • Tabs: click each tab. Does content load? Errors?
   • Search boxes: type a query. Does it filter? Debounce correctly?
   • Modals/dialogs: trigger them. Do they open/close cleanly? Can you escape?
   • Accordions/expandable sections: expand them all
   • Action menus (... buttons): click them. What options appear?
4. Verify the outcome actually rendered — clicking "View Manifest" must show a manifest, not a blank panel. Every action must produce a visible, correct DOM change. Silent no-ops, empty renders, stale content, and stuck spinners are all findings.
5. Check console after every interaction — new errors? warnings?
6. Check network after every interaction — failed requests? slow responses?
7. Screenshot before and after significant interactions
8. Try edge cases:
   • Submit empty forms
   • Enter invalid data (special chars, extremely long strings, SQL injection patterns)
   • Click buttons rapidly
   • Use keyboard navigation (Tab, Enter, Escape)
9. Scenario enumeration — for each page, don't just test what's visible. Think about what a real user would TRY to do:
   • "I see a list of items — can I sort them? Filter them? Search them? Paginate?"
   • "I created an item — can I edit it? Delete it? Duplicate it? Export it?"
   • "This form has 5 fields — what if I fill only 1? What if I fill all with garbage?"
   • "I'm on the detail page — what if I go back? What if I refresh? Bookmark?"
   • "There are 0 items — is there an empty state? Or just a blank table?"
   • "There are 100 items — does pagination work? Performance OK?" Count the scenarios you tried vs the scenarios a user would reasonably attempt. If you tried 5 out of 20 reasonable scenarios, go back and try more. The goal is EXHAUSTIVE scenario coverage, not "a few interactions per page."
10. Verify data roundtrips: after creating or modifying data through a form, navigate to the page that DISPLAYS that data and verify the values match. This catches serialization bugs, missing fields, and data loss:
    1. Fill and submit a create form (e.g., "Create User" with name "Test User")
    2. Navigate to the list/detail page that shows the created item
    3. Verify EVERY field value matches what was submitted
    4. If values don't match or the item doesn't appear: finding (data loss)
    5. Check edge cases: special characters, long strings, empty optional fields