# Build your own illustrated city guide

Recipe revision: mumbai-20260908-d5ea3d22b647

Reconstructed Codex recipe, September 2026. These are new prompts derived from the public project's observed structure, not its original conversation. The recipe has not been tested as an end-to-end recreation. It describes a similar experience, not an exact restoration.

Replace [CITY] and choose your own landmarks. Bring owned/licensed artwork or generate new imagery; the showcased plates are not offered under an open reuse license.

## 1. Define your city guide

Build an illustrated city guide for [CITY] as an accessible, static website. The experience begins with an illustrated overview map and opens into six landmark pages. Treat each page like a museum plate: one dominant illustration, a short factual caption, and a few clearly labeled links. Start by asking me for the audience, six landmarks, available artwork, source material and preferred framework. Inspect the existing repository and its instructions before editing. Preserve existing work. Do not invent historical facts, personal stories, asset licenses or event information. Separate researched facts from illustrative interpretation. First propose the route and content structure; then implement one complete landmark as a vertical slice.

## 2. Gather the ingredients

For the approved city and landmarks, create a small content manifest with stable IDs, names, short descriptions, source URLs, fact-check dates, image paths, alt text, captions and related sections. Use authoritative sources for factual claims. Record uncertainty rather than filling gaps. Create an asset plan for an overview map and one illustration per landmark. Use my supplied artwork only with its stated rights, or generate new artwork with clear provenance. Do not copy the Mumbai plates or assume they carry an open license. Keep labels and essential information in HTML even if the illustration also contains lettering. Date any temporary events and make them optional. No live API, account, location tracking or payment integration is needed.

## 3. Build the illustrated journey

Implement the approved overview and landmark pages using ordinary links and readable HTML. Make the overview image responsive without cropping away landmarks. Add accessible named hotspots where useful, plus a visible text list of all six destinations so mobile users never depend on tiny targets. Each landmark gets a large figure, caption, optional history/stories/visual-detail sections backed by the manifest, and a visible back link. Browser Back must work. Do not create empty routes for unresearched sections. Give images explicit dimensions; optimize them and lazy-load below-the-fold media. The content must remain usable without JavaScript.

## 4. Give it a coherent visual language

Use a restrained museum-folio direction: warm paper, dark ink, serif display typography and a single muted accent. Keep the artwork dominant and the interface quiet. Use one consistent illustration brief across plates, but adapt subject and composition to each landmark. Avoid dashboard cards, decorative statistics and generic marketing copy. Keep image labels supplementary to readable captions. Add subtle focus/hover feedback and, only where useful, a short entrance transition. Honor prefers-reduced-motion. Test long landmark names, small screens, image-loading failures and high-contrast text.

## 5. Verify and leave a rebuild kit

Run the repository's required checks and production build. Inspect the homepage and every implemented landmark at desktop and mobile widths. Verify keyboard navigation, visible focus, back links, readable captions, no horizontal overflow, no missing assets and a usable no-JavaScript view. Report the actual tests performed and any limitations; do not claim untested behavior passed. Produce a README with setup/build commands, runtime version, content-editing instructions, source citations and asset provenance. Propose a minimal preservation file list: source, dependency lockfile, irreplaceable assets and data. Exclude secrets, dependencies, caches and generated build output by default. Do not publish, transfer an archive, or remove hosting until I authorize those actions.