Verify anything the client will see in a browser

The API can only prove a record is correct, not that the screen looks right, and
a Studio-modified form, a portal page or a report PDF can be wrong while every
API read passes. Adds a "Look at the screen" step: prefer Claude in Chrome (uses
the user's own Odoo session), fall back to a Playwright MCP, and where neither is
installed offer the choice once and accept screenshots rather than blocking the
build on a tool install.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -41,6 +41,9 @@ same-named fork silently shadows upstream depending on install order.
   - On **Odoo.sh**: create the project + enter any partner trial code first (web-only), then come back with the DB URL + API key.
 - Optional: **Knowcap** with its MCP connected, as one possible discovery source → [knowcap.ai](https://knowcap.ai).
 - Optional: the **Perplexity MCP** for the native-vs-custom research step (web search works too).
+- Optional but recommended for UI/website work: a browser tool for visual checks — **Claude in
+  Chrome** (uses your existing Odoo session) or a **Playwright MCP**. Without one, the skill
+  asks you for screenshots instead.
 
 ## Quickstart
 

SKILL.md

@@ -299,6 +299,33 @@ progress or delivery view look wrong), costs under selling prices, dates in the
 Derive staged quantities from the ordered quantity rather than hard-coding them, so they
 cannot drift when a formula changes.
 
+### Look at the screen
+
+The API tells you a record is correct. It cannot tell you the demo *looks* right — and the
+demo is a thing people watch. Anything the client will see must be **visually inspected
+before hand-off**, not inferred from a `search_read`:
+
+- a Studio-modified or custom form view (a field can be set, stored, and not on the screen)
+- website / eCommerce pages, the customer portal, the login and branding
+- any hero whose payoff is visual: a blocking dialog, a kanban, a progress bar, a report PDF
+- the run-of-show click-path itself, walked once end to end
+
+**Use a browser tool.** Check what's available before this step, in this order:
+
+1. **Claude in Chrome** — first choice. It drives the user's own Chrome, so an existing Odoo
+   session just works and no credentials get typed into a script. Load the
+   `claude-in-chrome` skill before calling any of its tools.
+2. **Playwright MCP** — use if it's already configured, or when the check should be
+   repeatable/headless. Needs a login step, so it wants a demo user, not the client's admin.
+3. **Neither installed** — say so and offer the choice, once: *"I can verify the screens
+   myself with Claude in Chrome (drives your browser, uses your Odoo session) or Playwright
+   (headless, scriptable, needs a login). Install one, or send me screenshots."* Then take
+   the user's answer and get on with it. Screenshots from the user are a perfectly good
+   fallback — do not block the build on a tool install.
+
+Never claim a screen looks right if nobody looked. "Field is set" and "screen is correct"
+are different claims, and only one of them survives the demo.
+
 ### Sales docs
 
 From `templates/` (brand-themed, `{{placeholder}}`-driven), produce three self-contained
@@ -372,6 +399,8 @@ Rules for the boundary:
 - **Buttons, not fields.** Never advance a record's state with `write` — call the button
   method (see *Move records with buttons, never with fields*).
 - **Batch.** One call over N records, never N calls over one (see *Batch every call you can*).
+- **Anything the client will see gets looked at.** UI, website, portal and report changes are
+  verified in a browser (see *Look at the screen*), never signed off from API reads alone.
 - **Don't hard-code the client.** Everything client-specific lives in `demo_config.json`.
 - **Currency before invoices. Weight before fleet. Pre-stage before the live click.** Order matters.
 - Never hand over an environment holding test records. Purge them and read back the counts;