Recon

Description

Reads a site that is being replaced and separates what survives the rebuild from what does not. Output has two consumers: Part A is a self-sufficient design brief, Part B is the engineer's build dossier. Keep them strictly separated.

Prompt

<context>
You are performing recon on an existing website that is being replaced with a
ground-up rebuild. Nothing about the current site is a constraint on the new one.
Its structure, page hierarchy, navigation, visual design, and marketing copy are
all being discarded. What survives is the business underneath it: what this
company does, who buys from it, what it sells, and the handful of facts and
assets that are genuinely theirs.

Your output has two consumers, and they need different things:

- **Part A — Design Brief.** Goes to a visual design tool that will produce a new
  site from scratch. It must be readable in one pass and self-sufficient: if it
  were the only thing handed over, it should be enough to design from. Every
  sentence in Part A shapes a design decision. Anything that doesn't belongs in
  Part B.
- **Part B — Build Dossier.** Goes to an engineer at implementation time. Full
  data, asset URLs, operational configuration, migration notes, client questions.

Keep them strictly separated. Do not let Part B material leak into Part A.
</context>

<task>
Browse the website at [SITE_URL], including its sitemap, robots.txt, structured
data, and any embedded JSON or API payloads behind interactive components.

Before writing anything, work through these in order:

1. **What is this business, really?** Not what the site says it is — what it
   actually sells, to whom, and how it makes money.
2. **Who are the audience segments?** Identify two or three distinct groups. For
   each: who they are, what brought them to the site, and what a successful visit
   looks like for them. Different segments usually want different things from the
   same page.
3. **What is the positioning insight?** The single true, specific thing about this
   business that the current site fails to say out loud. Look for it in the places
   marketing copy doesn't reach: product names, menu items, service descriptions,
   staff pages, the way prices are structured. This is the most important line in
   the briefing.
4. **What is the catalog / content shape?** Not the full data — the shape. How
   many categories, how many items, price range and clustering, description
   length, which items carry options or variants or tags. A designer needs the
   pattern; the engineer needs the data.
5. **What page types does this business need?** Propose a template set from
   first principles based on what the business does. Do not reproduce the existing
   sitemap. If the current site is missing a page type the business obviously
   needs, say so.
6. **What is genuinely theirs and worth keeping?** Facts, real customer language,
   proprietary names, owner-shot photography, testimonials. Distinguish these from
   generic filler that any competitor could have written.
7. **What should this NOT look like?** Identify the lazy default this category
   invites — the visual and structural cliché a designer would land on by reflex.
</task>

<constraints>
- **Quarantine the old copy.** Existing marketing prose is a contamination risk,
  not source material. Extract the *facts* it contains and discard the wording.
  If specific phrasing is worth quoting, it goes in Part B under an explicit
  "do not reuse" heading — never in Part A. The only exception is proprietary
  terminology (product names, a real tagline the business actually owns).
- **Judgment is required about positioning, audience, and content quality.** State
  plainly when content is filler, when structure is broken, or when the site
  misrepresents the business. Do not pad a thin site to make it look substantial.
- **Judgment about aesthetics is not wanted.** Do not describe colors, fonts,
  spacing, or layout except where a choice reveals something about the brand that
  isn't recorded anywhere else.
- **Separate observed from inferred.** Mark anything you concluded rather than
  read. Mark anything you could not verify — pages behind auth, bot-blocked
  endpoints, JavaScript-only content, third-party embeds you could not open.
- **Flag contradictions rather than resolving them.** Where the site states a fact
  more than once and the versions disagree, report every version and mark it as
  requiring client confirmation. Do not pick a winner.
- Part A should fit on roughly one page. Part B has no length limit.
</constraints>

<output_format>
A single Markdown document with two top-level parts.

# Part A — Design Brief

## The Business
One paragraph. What they do, where, at what price point, and how they make money.

## Audience
Two or three segments. For each: who they are, what brought them here, and what
a successful visit looks like.

## Positioning Insight
One to three sentences. The true, specific thing about this business that should
drive the new design. Name the tension or contrast if there is one.

## Voice & Vocabulary
- Proprietary names, product names, and terminology that must carry forward
- Any tagline the business genuinely owns
- The register the business actually speaks in, evidenced by where you found it

## Facts That Must Appear
Concrete, verified information the new site has to communicate — what they sell,
where they are, when they're open, how to buy. Facts only, no prose.

## Proposed Template Set
The page types this business needs, derived from the audience segments above.
For each: its job, and which segment it serves. Note where this differs from
what exists today and why.

## Content Shape
For each template that displays a collection: how many items, how many groupings,
price range and clustering, typical description length, which items carry
variants, options, or tags. Include three to six representative examples — not
the full set.

## Assets Available
What imagery exists and is usable, in one or two lines. Quality and quantity
only; URLs and formats go in Part B.

## Anti-Brief
The default this category invites, stated explicitly so it can be avoided.
Include any real constraint that pulls against it — price point, location,
audience, scale.

## Blocking Questions
Anything unresolved that would change the design if answered differently.

---

# Part B — Build Dossier

## Business Info
Every contact and operational detail found anywhere on the site. Include the
field even when absent, marked `Not found`. List every conflicting version of
any field, with its source.

## Full Content Extraction
Complete data for every catalog, menu, service list, or collection — every item,
description, price, variant, option, and tag.

## Operational Configuration
Modifiers, add-ons, dietary or attribute flags, fulfillment options, integrations,
and any third-party rails (POS, booking, payment, ordering) the rebuild inherits.

## Asset Inventory
Table: asset, source URL, native dimensions, file size, format, and whether it is
production-quality or reference-only. Note anything that must be pulled before
migration, and any stock or placeholder assets to skip.

## SEO Signals to Preserve
Existing title and meta targeting, any keyword the site is clearly built around,
structured data present, and anything with likely inbound links.

## Redirect Map
Every existing URL mapped to its destination in the proposed template set, or
marked for removal.

## Old Copy — Do Not Reuse
Verbatim existing marketing copy, quarantined here for reference only.

## Red Flags & Client Questions
Defects, contradictions, missing content, and false claims in structured data.
Separate the ones that block launch from the ones that are merely improvements.

## Verification Notes
What you could not access, what was inferred rather than read, and what a
JavaScript-rendered capture may have missed.
</output_format>