Portfolio by chat

I want to rebuild my portfolio. Before designing anything, read these and tell me what you find:
- My LinkedIn: [URL] (if you can't open it, I'll send a PDF)
- My old portfolio: [URL]
- My GitHub: [URL]. Read the README of each project I list: [PROJECTS]
- Company sites: [URLS]

Give me my roles latest first with real years, a one-line factual description of each project from its README, anything that conflicts, and anything missing. Don't write site copy yet. Don't invent anything.

I'm starting my portfolio from scratch and I don't code. Interview me one question at a time: my roles, years, projects, proof (links, screenshots, things I can back up) and what I want to be known for. Wait for each answer before the next question. When we're done, draft a locked-facts note for me to confirm. Don't invent anything.

Pitfall: LinkedIn often needs a login. If the summary sounds generic, send a PDF or paste the text and say “use only this.”Vague answers get vague copy, and it may fill gaps with invented proof. Give specifics (real years, links), say “I don’t have that yet” when you don’t, and check the draft facts line by line.

Settle name, one title, a one-line lede, roles with real years and a “do not say” list.

Tip: Ask Grok Bot to remember them so every later chat starts from the same story.

Help me lock my positioning using only the facts you found. Give me 3 title options, 5 one-line ledes (plain, under 20 words, no hype) and a "do not say" list of claims the sources don't support. I'm publicly known as [NAME] and want to be hired for [ROLE].

Remember these as my locked facts for the portfolio, and never change them without asking me:
[PASTE FINAL NAME, TITLE, LEDE, ROLES WITH YEARS, DO-NOT-SAY LIST]

Pitfall: Invented numbers (“increased engagement by 40%”). If you can't prove it, delete it. Memory is a convenience, not a source of truth. Still check facts.

Prefer one document?

Tip: The same <a href="#g-brief">master brief</a> works as a chat message. Send it once; ask Grok Bot to remember it.

Here is my master brief for the portfolio. Remember it and follow it in every chat about the site:
[PASTE THE FILLED-IN MASTER BRIEF]

Pitfall: Updating facts in chat but not telling it to update the memory. Say “update my locked facts: …”.

Four pages is plenty: Home, Work, Playground, Contact.

Tip: Work is career chapters, latest first, not numbered, and no three identical case-study cards.

Propose the structure for my site: Home, Work, Playground, Contact. Work should be career chapters, latest first, not numbered. No grid of three identical case-study cards. Tell me which images each section needs, and which of those you can already pull from my old site.

Pitfall: Adding About / Services / Blog “because portfolios have them”. Add later if needed.

Pointing at real references gets a point of view; any reference works.

Here is my visual reference: [LIVE SITE LINK(S) / MOODBOARD SCREENSHOTS]
Describe its design system back to me first: layout grid, spacing, type, colour, how images are shown, motion, navigation and mobile behaviour. If I send more than one, blend them and tell me what you took from each. Take inspiration from the look and interaction only; never copy their text, logos, images or code.

Respect the source: take inspiration from the look and interaction, never copy text, logos, images or code. If you want an actual template, buy or remix it under its licence.

Pitfall: Leftover placeholder copy or brand names from a reference. Ask it to search the site for anything you didn't write.

Grok Bot writes a plain static siteA site made of plain files (HTML, CSS, images): no server code or database. on its own computer: HTML pages, one stylesheet, a small theme script, your images.

Tip: You don't copy any files.

Build the site now as plain static files using my locked facts and the look of my reference. Light and dark mode that follows my system and remembers my choice. Same header and footer on every page. Looks good on a phone. Use my real screenshots and portrait, with good alt text. Build Home first, show me, and wait for my feedback.

Pitfall: Approving every page at once. Home first; then “build Work using the same styles.”

It previews the site itself, then opens a temporary Cloudflare link so you can open it on your phone.

Send me screenshots of Home on desktop and phone, in light and dark. Then open a temporary link so I can check it on my phone.

Pitfall: Free quick tunnels can be rate-limited and the link changes each time; treat it as temporary. · Share it only with people you trust.

Most of your time goes here.

Tip: Screenshot the problem, say what's wrong in plain words, one change per message.

[Screenshot] On [PAGE], [WHAT'S WRONG, in plain words]. I want it to [WHAT YOU WANT]. Only change this, then send me a new screenshot.

Pitfall: Five changes in one message. Some get missed. If something breaks, say “undo that last change.”

Fluent copy hides mistakes: in the real build it got one of the owner's own projects way off.

Fact-check every page against my locked facts and the sources. Give me a table: page, exact sentence, issue (wrong year, wrong title, claim not in sources, invented metric, overstated credit), suggested fix. Don't change anything until I approve.

Then read it yourself: every year, title, spelling and link.

Pitfall: Trusting its fact-check alone. It can confirm its own mistakes.

Titles, descriptions, Open GraphTags that set the title, text and image shown when your link is shared. share previews, a Person schemaA hidden block of data that tells search engines who the site is about., sitemap.xmlA file listing your pages so search engines can find them. and robots.txt.

Add SEO basics for my final domain [YOURDOMAIN.com]: unique titles and descriptions, share-preview tags with a good preview image, a canonical URL per page, Person schema on Home, sitemap.xml, robots.txt and a favicon from my portrait. Only use my locked facts.

<title>Alex Rivera · Product Design Lead</title>
<meta name="description" content="Alex Rivera designs AI products…">
<meta property="og:image" content="/images/og-image.jpg">
<link rel="canonical" href="https://yourname.com/">

Pitfall: Expecting temporary links to get indexed. Only the real domain counts; indexing takes days to weeks.

Grok Bot deploys from its own computer to the host you pick; you approve any sign-in yourself.

Publish the site as a static site on [VERCEL / NETLIFY / CLOUDFLARE PAGES / GITHUB PAGES / MY EXISTING HOSTING]. If you need me to sign in, send me the link and code and wait. Send me the live link when it's done.

Pitfall: Approving a sign-in you didn't ask for. Only approve a code you just requested, on the host's own site.

Add the domain in your host, then the DNSThe internet’s address book: it points your domain at the host serving your site. records it shows, before sharing publicly, so the first link is permanent.

1. Add the domain in your host first (table below). It then shows the exact records.
2. Choose where DNS lives. Easiest: keep your registrar’s DNS and add the records. Or move nameserversNameservers decide which company answers DNS for your domain. Moving them moves all your records, including email. to the host (Cloudflare Pages needs this for the apex). Moving nameservers moves all records, so copy your email (MXDNS records that deliver your email. Leave them alone./TXT) records first.
3. Add the apex record (A or ALIASAn apex record some DNS providers offer that works like a CNAME for yourname.com.) and the www CNAMEDNS records that point your domain (A or ALIAS, for yourname.com) or www (CNAME) at your host.; remove old A/CNAME records for the old site.
4. Wait for SSL. Minutes to a few hours; the host shows a check or “certificate issued”.
5. Check it works: open https://yourdomain.com and https://www.yourdomain.com on your phone (off Wi-Fi), and confirm one redirects to the other.

Connect [YOURDOMAIN.com] and www to the site on [HOST]. My registrar is [REGISTRAR]. Tell me exactly which DNS records to add, change or delete, one step at a time, whether I should move nameservers, and warn me before anything that would break my email. Then check HTTPS works on both.

Pitfall: Deleting MX/TXT records, or moving nameservers without copying them, and breaking email.

The site now updates the way you'd brief a teammate.

Tip: It previews, you approve, it redeploys.

Add a new Playground project: [NAME]. Read its README at [URL] for the description. Use this image [ATTACH]. Match the existing cards, show me a screenshot, and deploy after I approve.

Swap the image in the [COMPANY] chapter for this one [ATTACH] and update the alt text. Screenshot first, deploy after I say ok.

Pitfall: Skipping the fact-check on small updates. New copy still needs it.

I'm building a personal portfolio site. Before we design anything, read
all the source material I've attached: [LIST: LinkedIn PDF, old portfolio
URL, README for PROJECT NAME, screenshots].

Then give me back:
1. A list of my roles, latest first, with company, title and years
   exactly as they appear in the sources.
2. A one-line, factual description of each of my own projects, based only on
   its README.
3. Anything that conflicts between sources (e.g. different years).
4. Anything you'd need to know that isn't in the sources.

Do not write any website copy yet. Do not invent anything.

I'm starting my portfolio from scratch and I don't code. Interview me one question at a time: my roles, years, projects, proof (links, screenshots, things I can back up) and what I want to be known for. Wait for each answer before the next question. When we're done, draft a locked-facts note for me to confirm. Don't invent anything.

Pitfall: Giving it a link it can't open, so it summarises from guesswork. If it sounds generic, paste the text in and say “use only this.”Vague answers get vague copy, and it may fill gaps with invented proof. Give specifics (real years, links), say “I don’t have that yet” when you don’t, and check the draft facts line by line.

What you say about yourself is harder to change than design.

Tip: Settle name, one title, a one-sentence lede, roles with real years, and a “do not say” list, then put it in the master brief.

Using only the facts from the sources, help me lock my positioning.
Give me:
- 3 options for a single title (e.g. "[Product Design Lead, AI products]").
- 5 options for a one-sentence home-page lede. Plain, specific, no hype,
  under 20 words.
- A short "do not say" list: claims that would overstate my role or that
  the sources don't support.

My constraints: I'm publicly known as [NAME]. I want to be seen as
[WHAT YOU WANT TO BE HIRED FOR]. Don't use the words [WORDS TO AVOID].

Pick, edit, paste the answers into the brief. Start every new chat with it (or rely on Project instructions / CLAUDE.md / AGENTS.md).

Pitfall: Letting the AI “punch up” your story with numbers (“increased engagement by 40%”). If you can't prove it, delete it.

The single most useful thing here.

Tip: Paste it at the start of every session so the AI never forgets who you are or starts inventing things.

The full template is in the master brief block above.

Pitfall: Long chats drift. When answers get vague, start a fresh chat with the brief.

Simple is easier to build, read and maintain.

Tip: Four pages is plenty. Avoid three equal case-study cards and numbering your jobs (“01, 02, 03” reads like a task list).

Propose a site map and the content outline for each page, using my
locked facts. Pages: Home, Work, Playground, Contact.

Rules:
- Work is organised as career chapters, latest first, not numbered.
- Don't use a grid of three identical case-study cards.
- For each section, tell me what images I need to supply.
- Keep it to plain text, no code yet.

Pitfall: Adding pages “because portfolios have them” (About, Services, Blog). Each one is something to maintain.

“Modern and clean” gets generic; pointing at real references gets a point of view.

Tip: Any reference works.

Here is my visual reference: [LIVE SITE LINK(S) / MOODBOARD SCREENSHOTS]
(screenshots attached too, in case you can't open the links).

Describe its design system back to me before building anything:
layout grid, spacing, typography (sizes, weights, feel), colour use,
how images are shown, motion (hover and scroll effects), navigation,
and how it behaves on mobile.

If I've given you more than one reference, blend them into one
system and tell me what you took from each.

Take inspiration from the look and interaction only. Never copy any
of their text, logos, images or code.

Respect the source: take inspiration from the look and interaction, never copy text, logos, images or code. If you want an actual template, buy or remix it under its licence.

Pitfall: It silently copies placeholder copy or brand names from a reference. Search the finished site for anything you didn't write.

A static siteA site made of plain files (HTML, CSS, images): no server code or database.: one HTML file per page, one stylesheet, a small script for the theme toggle, an images/ folder.

Tip: No server code: free to host, fast, hard to break.

mkdir my-portfolio && cd my-portfolio
# put CLAUDE.md or AGENTS.md (your master brief) here, plus sources/ and images/
claude      # for Claude Code
# or
codex       # for Codex CLI

Using the master brief, build the site as plain static files:

index.html, work.html, playground.html, contact.html,
css/style.css (shared by all pages), js/main.js, images/ (I'll add files).

Requirements:
- Match the visual reference's layout, type and motion with my content.
- Fonts: [FONT NAMES] from Google Fonts.
- Light and dark mode: follow the system setting by default, include a
  small toggle in the nav, and remember the user's choice (localStorage).
  No flash of the wrong theme on load.
- Same header and footer on every page; nav highlights the current page.
- Responsive: looks good from 360px phone width up to large desktop.
- Use my image file names: [LIST, e.g. images/portrait.jpg,
  images/acme-dashboard-2024.png]. Add descriptive alt text.
- Respect "reduced motion" settings.
- No frameworks, no build tools, no external JS libraries.

Build Home first and show me. Then wait for my feedback before the
other pages.

Pitfall: Asking for all four pages at once in a chat app: output gets cut off or inconsistent. Home first, approve, then “build Work using the same styles.”

See the real site in a real browser, on laptop and phone.

Tip: Double-clicking index.html mostly works; a tiny local server is better.

python3 -m http.server 8000

Open http://localhost:8000. Stop with Ctrl+C. On your phone (same Wi-Fi): http://[THAT-ADDRESS]:8000, or Chrome device emulation. Real phones catch things emulators miss.

Start a local preview server for this folder on port 8000 and tell me
the URL. Leave it running.

Pitfall: Broken images from case mismatches (Portrait.JPG vs portrait.jpg). Keep file names lowercase with dashes.

Where the site gets good and most of your time goes.

Tip: Speak like a design director: say what's wrong, not how to code it.

1. One change per message.
2. Attach a screenshot and point at the problem.
3. Describe the problem, not the fix. “Feels cramped” beats “add padding: 24px”.

[Screenshot attached] On the [PAGE] page, [WHAT'S WRONG, in plain words].
I want it to [WHAT YOU WANT IT TO FEEL/DO].
Make only this change and tell me which file(s) you edited.

Chat app: ask for the full updated file, not a fragment. Claude Code / Codex: just refresh your browser.

Pitfall: The “fix one thing, break another” loop. Say “undo that last change”, or keep backups. Claude Code / Codex can use git: “commit the current state with the message ‘home approved’.”

Fluent copy hides errors.

Tip: A wrong year or inflated title on your own portfolio is worse than none.

Fact-check all the text on every page against my LOCKED FACTS and the
source files. Produce a table:
page | exact sentence | issue (wrong year, wrong title, claim not in
sources, invented metric, overstated credit) | suggested fix

Don't change any files yet. I'll approve fixes.

Then check yourself: every year, title, company spelling, project description and link.

Pitfall: Trusting the AI's fact-check entirely. It can confirm its own mistakes. Your eyes are the final check.

Small additions help search and link previews (LinkedIn, Slack, WhatsApp) show your name, title and image.

• Titles + meta descriptions: search results.
• Open GraphTags that set the title, text and image shown when your link is shared. tags: share previews.
• JSON-LDA hidden block of data that tells search engines who the site is about. Person: who the site is about.
• sitemap.xmlA file listing your pages so search engines can find them. + robots.txt: help crawlers find pages.

Add SEO basics to every page, using my final domain [https://YOURDOMAIN.com]:
- A unique <title> and meta description per page (under ~155 characters).
- Open Graph and Twitter card tags, using images/og-image.jpg
  (1200×630). Tell me what to put in that image.
- A canonical URL on each page.
- JSON-LD Person schema on the home page: name, jobTitle, url, sameAs
  (LinkedIn, GitHub), image.
- sitemap.xml listing all pages and a robots.txt that allows everything
  and points to the sitemap.
- A favicon from my portrait.
Use only facts from the brief.

<title>Alex Rivera · Product Design Lead</title>
<meta name="description" content="Alex Rivera designs AI products…">
<meta property="og:image" content="/images/og-image.jpg">
<link rel="canonical" href="https://yourname.com/">

Pitfall: Expecting results from a preview link. Only your real domain counts, and indexing takes days to weeks. Optionally submit the sitemap in Google Search Console.

A quick tunnel gives your local preview a temporary public link.

Tip: Often simpler: skip to a preview deploy on your host.

cloudflared tunnel --url http://localhost:8000

Install cloudflared first (see Cloudflare's docs). It prints a random https://….trycloudflare.com link. Stop with Ctrl+C.

With the preview server running on port 8000, start a Cloudflare quick
tunnel so I can share a temporary HTTPS link. Tell me the URL, and how to
stop it.

Pitfall: Free quick tunnels are rate-limited and for testing only ; the link changes every time. · No custom name for quick tunnels. · Avoid plain http:// tunnel services. Use HTTPS, share only with people you trust, stop it when done.

Pick a free host for a static site; any of these works.

Help me publish this static site. My choice of host: [VERCEL / NETLIFY / CLOUDFLARE PAGES / GITHUB PAGES / MY EXISTING HOSTING (cPanel/FTP)].
Walk me through it one step at a time for that host, using its current official docs. If you can run commands, do the deploy yourself and ask me to handle any sign-in in my browser. Don't change any site files. Tell me the live URL when done.

Redeploy after each change the same way you first published.

Pitfall: Deploying the wrong folder (with your sources/ LinkedIn PDF inside). Publish only the site files; keep sources and brief files out.

Do this before you share publicly, so the first link people see is permanent.

1. Add the domain in your host first (table below). It then shows the exact records.
2. Choose where DNSThe internet’s address book: it points your domain at the host serving your site. lives. Easiest: keep your registrar’s DNS and add the records. Or move nameserversNameservers decide which company answers DNS for your domain. Moving them moves all your records, including email. to the host (Cloudflare Pages needs this for the apex). Moving nameservers moves all records, so copy your email (MXDNS records that deliver your email. Leave them alone./TXT) records first.
3. Add the apex record (A or ALIASAn apex record some DNS providers offer that works like a CNAME for yourname.com.) and the www CNAMEDNS records that point your domain (A or ALIAS, for yourname.com) or www (CNAME) at your host.; remove old A/CNAME records for the old site.
4. Wait for SSL. Minutes to a few hours; the host shows a check or “certificate issued”.
5. Check it works: open https://yourdomain.com and https://www.yourdomain.com on your phone (off Wi-Fi), and confirm one redirects to the other.

My site is live on [HOST] at [LIVE URL]. I want it on [YOURDOMAIN.com] and www. My registrar is [REGISTRAR] and my current DNS records are: [PASTE OR SCREENSHOT].
Using [HOST]'s current docs, tell me exactly what to add in [HOST] and which DNS records to add, change or delete, one step at a time. Tell me whether to keep my registrar's DNS or move nameservers, and warn me before anything that would break my email.

Pitfall: Deleting MX or TXT records, or moving nameservers without copying them, and breaking your email.

Your site is just a folder of files.

Tip: Updates are a sentence away. Then preview, fact-check, redeploy.

Add a new Playground project: [NAME], [ONE-LINE DESCRIPTION FROM README],
link [URL], image images/[FILE].png. Match the existing cards.
Then update sitemap.xml if needed.

Swap the image in the [COMPANY] chapter for images/[NEW-FILE].png and
update its alt text.

Or rebuild in Framer. Buy or remix the template and edit visually. Framer offers an official way to connect external agents like Claude Code and Codex (setup has been via npx @framer/agent setup). See Framer's guide. Check current docs; this is new.

Pitfall: Skipping the fact-check on “small” updates. New copy needs the same check.