--- name: product-context-verification description: "When the user asks to build a site/page/artifact for a real-named business, event, place, or organization (a camp, a brand, a conference, a school, a cafe, a product), FIRST verify whether that entity actually exists before inventing content. If it does exist, search the web for real facts (location, history, features, photos) and use them. If it doesn't or is ambiguous, ask the user ONE clarifying question before proceeding. Never silently fabricate details for a real-sounding name. Triggers: proper nouns in the brief (any named company, venue, product, school, event, cafe, hotel, camp, etc.), especially when combined with a location hint — any 'make me a site/landing for X' where X could plausibly exist." version: 1.0.0 license: MIT source: skillport/originals tags: [research, context, fact-checking, brief-interpretation, anti-hallucination] category: workflow trust_tier: verified --- # Product Context Verification Stops the model from confidently inventing facts about a real thing. The single most-embarrassing failure in site-building sessions is writing up a fictional history, address, and program for a real camp/cafe/school — when a 5-second web search would have given the correct details or revealed that the entity is fictional. ## When this skill activates The user's request includes a **proper noun** (named entity) for an organization, product, place, or event, and asks you to build something for it. Examples: - "Build a landing page for Camp Sunlight." - "Redesign cafe-linnea.com." - "Write copy for the Antelope Press 2026 catalogue." - "Make a site for Hotel Marine Bay in Brighton." - Any brief in any language that contains a named entity + a request to create a site/page/artifact for it. This skill does NOT activate for: - Clearly-fictional names ("a camp called Pine Compass") where the user is inviting invention - Generic requests ("build a landing page for a kids camp") — no entity to verify - Tasks where the user has already shared the brief/content/site directly ## Three-step protocol ### Step 1 — Detect the named entity Before writing any copy or picking any images, extract every proper noun that refers to an organization, place, product, event. If there are any, go to Step 2. If none, skip this skill. ### Step 2 — Quick web research Search the web using ONE clear query combining the entity name + the strongest discriminator the user gave (location, industry, year). If you have `WebSearch`, use it; otherwise, ask the user if they want you to search (never silently skip). Examples: - `"Camp Sunlight" Michigan kids summer` (not just `Camp Sunlight` — dozens may share the name) - `"Cafe Linnea" Portland` - `"Hotel Marine Bay" Brighton` - For non-English entities: include the city/region and the industry keyword to narrow results. Read the top 3-5 results. Decide one of: - **EXISTS, clearly this one** — at least one authoritative result (own site, Wikipedia, official registry, news) matches the location/industry/details in the brief. Proceed to Step 3 with real facts. - **EXISTS, ambiguous** — multiple entities with the same name, none clearly matching. Stop and ask the user ONE question (see "How to ask" below). - **DOESN'T EXIST / UNFINDABLE** — zero credible matches. Tell the user plainly: "I couldn't find a real `` in ``. Should I (a) build this as a fictional/new venture, inventing details to fit, or (b) is the name different?" ### Step 3 — Use real facts Once you've confirmed which entity this is: - **Address, phone, dates** — use what you found. Don't invent "123 Pine Street" when the real address is on the official page. - **History, founding year, programs** — quote what's published. If the official site says "since 1978", use that. Don't round to "since 1980" for aesthetic. - **Photos** — prefer real photos of the actual place over generic stock. Use `curated-image-sourcing` → Bing Images with query `"" ` to get actual property shots. Stock landscape is a fallback, not the first choice. - **Tone & copy** — match the voice of the real entity if they have a web presence. If their site describes a pine-forest setting, don't invent a lakeside location; if they describe a downtown cafe, don't write copy for a beachside venue. - **Phone/contact** — if you can't find the real one, leave a clearly-flagged placeholder `+7 (XXX) XXX-XX-XX` rather than making up digits. Call this out in the handoff message. If certain facts are not findable on the web (e.g., current pricing, 2026 program details), mark them explicitly in the handoff: "I used real facts where I could find them. The following are placeholders I need you to confirm or correct: program dates, 2026 prices, the director's name." ## How to ask (when ambiguous or non-existent) Keep it to ONE question, phrased for fast resolution. Do NOT list all your options or ask six sub-questions. Templates: > "I found multiple entities named `` in ``. Is it the one at ``, or a different one? Or do you want me to build this as a new project under that name?" > "I couldn't find a `` in ``. Is this a new venture you're launching, or do you have the real URL I can look up?" When the user's brief is in a non-English language, ask the clarifying question in THAT language. Don't force English on a native speaker for a one-line question. Then WAIT for an answer. Do not start building while waiting. ## Anti-patterns to refuse - **Silently fabricating history/address/phone/program dates** for a real-sounding entity because "it sounded plausible." This is the worst failure mode — the user sees the site, thinks "that's not my camp", and loses trust in the whole output. - **Guessing photos of the real place** by using generic regional landscape. OK as fallback with a note, but first try Bing Images with the entity name — many small businesses have real photos indexed. - **Ignoring the brief's proper noun**, treating "Camp Sunlight" as a generic name and making a generic template. Proper nouns carry information: they signal the user wants THIS specific entity, not a template. - **Asking multiple questions** instead of one focused one. One question gets answered; four questions get ignored. - **Asking questions about unrelated details** (palette, tone, audience) when the real question is "does this entity exist." Resolve the entity first, then the design. ## Integration with other skills - `curated-image-sourcing` — once the entity is confirmed real, bias toward Bing Images with `""` as the primary query. Stock scenes become decoration, not the hero. - `frontend-design` — use real copy voice and tone if found; otherwise match the industry/audience (kids summer camp ≠ corporate SaaS). - `cyrillic-typography` — applies normally. ## Pre-ship checklist Before handing off the page: - [ ] Every proper noun in the brief was either (a) confirmed via web search with a cited source, or (b) flagged to the user with a clarifying question. - [ ] No invented addresses, phones, dates, or prices for a confirmed-real entity. - [ ] If entity doesn't exist and user wanted it built anyway, it's explicit in the handoff: "I built this as a fictional venture under the name ``; swap in your real details here ↓" - [ ] Sources list at bottom of the handoff: which facts came from which URLs.