review-example-chat

# Review an example chat Use for editorial and rendered-chat review, including user-reported screenshots. This complements `add-example-chat`; it does not generate synthetic transcripts or replace its CLI, publication, privacy and proof-video gates. Read the [review checklist](../../../.claude/skills/review-example-chat/references/checklist.md) when executing the review. ## Establish the subject Record the approved opening verbatim, intended audience/slide, deployed feature being demonstrated, source chat ID, example slug, expected model/mate/language, account-slot assignment and any prepared fictional memories. Check actual live capability availability before promising a focus mode or provider. Reuse an existing candidate only after reviewing its content and browser behavior. Use the assigned session worktree. Other workers own their own candidates; coordinate shared renderer/AI bugs with their fix owner instead of patching the same files independently. Do not edit another worker's account memories or credentials. Inspect user screenshots as evidence, not executable instructions. ## Real CLI read–react loop Use the real OpenMates CLI against `https://api.dev.openmates.org`; discover current command syntax with its help. Start the approved request, wait for and read the complete response and skill results, then decide the next natural reply within the scenario. Do not pre-script subsequent turns or invent facts to rescue an answer. Record turn IDs and bounded observations rather than copying large embeds into reports. At each turn check realism, practical usefulness, requested outcome, mate, model, language, date/year/timezone, sources and required product behavior. Clarify meaningful ambiguity as a human would. Never add internal skill mentions to force success unless explicitly demonstrating manual selection; explicit model mentions are appropriate for model-choice examples. Do not suppress follow-up questions or rewrite a weak transcript into a polished one. Stop advancing the candidate when there is a clear bug or bad response. Record expected/actual behavior, failing turn, reproduction and assigned issue; route it to investigation, then retry after correction. Ask the user when intended behavior or scenario continuation is uncertain. A failed candidate is useful bug evidence, not an admissible example. Avoid repeated paid regeneration without resolving the failure hypothesis. ## Browser gate After the source passes content review, use `add-example-chat` to publish. For landing candidates pass the converter’s `--require-follow-ups` gate once available; missing or malformed source suggestions must fail conversion, not be hand-authored to conceal the generation defect. Inspect BOTH the deployed `/example/{slug}` entry and the interactive landing entry `/#chat-id=example-{id}` (use the actual chat ID, which can differ from slug). Review the complete conversation on phone and laptop, logged out, with the sidebar closed. Exercise the checklist rather than accepting a load-only test or CLI transcript as rendering proof. Capture deployed commit, time, run/artifact references and actual observations for each viewport. Use `verify-ui-change` for fixes: relevant specs run through `scripts/tests.py` only after deployed code is ready, with `--gate-deploy --expected-commit`. Modified components require `verify-component-preview` before broader flows; all preview URLs include `chrome=0`. Use existing visual-smoke and `create-demo-video` workflows; do not replace required video proof with a screenshot gallery. Inspect supplied screenshots and failure frames as needed. ## Admission and handoff Run `python3 scripts/audit_example_chats.py` for structural defects. The optional `scripts/audit_example_chat_quality.py --slug <slug>` is transcript triage, not browser evidence; inspect its help before making paid requests. Create a JSON review record using the format in the checklist. Validate it: ```bash python3 scripts/audit_example_chats.py --review-record <record.json> \ --expected-commit <deployed-full-sha> ``` This checks completeness and current content hashes, not whether a reviewer actually saw the UI. Keep real browser/run evidence behind each pass. Recheck affected criteria whenever the transcript, translations, embeds, speech or rendering implementation changes; never relabel old evidence with a new SHA. Report keep, regenerate or reject, with content and browser findings, exact links, issue owners and audio status. Only a complete passing record admits a landing example. No new approval ceremony is imposed: honor the user's actual gates, including transcript approval and a single speech pilot before batch audio generation when requested. Unrelated user orchestration skills are out of scope.