4 25 min

Developer: build the site

Role
Developer
Outcome
Your site, running on your laptop
Time box
25 minutes

The Developer builds your site from two files: your content file and your design brief. Before it writes a line of code, it reads current guidance on how to build for today's web.

Your site stays plain HTML, CSS and JavaScript (the three languages of a web page). One small build step (a tool that turns your files into the finished site) puts your content into the pages. It needs nothing more to install. The Developer changes only files in site/.

Start the Developer

  1. In Antigravity IDE, start a new chat in the agent panel (the + button at the top of the panel).
  2. Check the model name under the chat box: it says Gemini 3.8 Flash. If not, click it and pick Gemini 3.8 Flash.

Then type:

Agent chat

Start the Developer step.

First it checks your design brief. Then it reads the guides it needs from Modern Web Guidance, which is stored in your repo, among them the guide for your signature move. It tells you in two sentences which guides it read, and one thing it builds differently because of them.

Fonts: already in your repo

The fonts of the five styles come with your repo, together with their licences, in the folder fonts/. The Developer runs node tools/fonts.mjs: it copies the fonts your brief names into site/assets/fonts/. Nothing to download and nothing to answer. Your site loads its fonts from itself, not from another server.

At home: add a font that is not in your repo

Your site never loads a font from another server: that would send every visitor's IP address (the number that identifies their internet connection) to that server. So the font files go into your repo.

  1. Open fonts.google.com, search for the font, click Get font, then Download all.
  2. Unzip the download:

Double-click the downloaded file in your Downloads folder.

  1. In your portfolio folder, open site, then assets. No folder called fonts there yet? Create it: in Finder with File → New Folder, in File Explorer with New → Folder, in Files with a right-click and New Folder.
  2. Copy all the files from the unzipped folder into fonts, the licence file too.
  3. Start a fresh chat and ask the Developer to use it, for example "Use the font Lora from site/assets/fonts/ for the headings."

Your signature move

Your design brief names one signature move: the one effect people remember. Examples are sections that slide into view as you scroll, or a header that shrinks when you scroll down. The Developer reads the matching Modern Web Guidance guide before it builds it.

Some visitors set their computer to reduce motion, because movement makes them feel unwell. For them, your move becomes a gentle fade, or nothing moves. Nothing breaks, and nothing is hidden.

Let it build

Now the Developer writes your stylesheet in your style and builds your signature move. It starts the preview in a terminal of its own and runs the Check (a script that tests your site). When the Check finds a problem in the Developer's own work, the Developer fixes it.

The preview builds your site first: node tools/build.mjs puts your content into finished HTML pages. That is called pre-rendering. Search engines, AI agents and link previews can then read your whole page without running JavaScript.

You do not run the build yourself: the preview, the Check and publishing all build first. After a change, reload the page: the preview builds your site again. The finished pages go into the folder _site/, which Git ignores. Never edit it: the files you change stay the ones in site/.

Building takes a few minutes. Stay in the chat and keep it on this one task.

Look at your site

When the Developer is done, it asks you to open the preview. Open the address it gives you, such as http://localhost:8000, in Chrome. Only you can see this address: it is your own laptop.

You see your content in your style. Look for your signature move too, the way the Developer described it. Then switch your computer between light and dark mode and look again. Your site follows it:

Apple menu → System Settings → Appearance → Light or Dark.

The Check result is part of the Developer's read-back. Five of six items pass. The privacy page needs attention until the Lawyer writes it. That is expected. The accessibility item uses axe (an automatic accessibility test), with the rules behind the accessibility score of Lighthouse (Chrome's quality audit):

What the Check prints (the end of it)

  PASS             Content file matches the schema
  PASS             Accessibility (the axe rules Lighthouse scores)
  PASS             No errors in the browser console
  PASS             What an agent sees: your content without JavaScript
  NEEDS ATTENTION  Privacy page written
                   - privacy.html is still the placeholder from the template. The Lawyer role writes the real page.
  PASS             No phone number or postal address in the site

5 of 6 items pass, 1 needs attention.
This Check only reports. It never stops you from publishing.

The Developer ends by sending you on: "The Developer is done. Start a fresh chat and ask for QA: it audits accessibility and performance in Chrome and fixes what it finds."

If something goes wrong

Ask your agent first. Start a fresh chat and type the question below. The agent reads your repo and tells you what is done and what comes next. Got an error message? Paste it into the chat, and it explains it.

Agent chat

Where am I?
The preview address does not open

Fix: the preview runs only while its terminal runs. Ask the agent: "Start the preview again." If port 8000 is taken, the preview picks another one and prints it.

The preview says "Your site could not be built"

Cause: something in site/ is broken, so the build stops. The page names what is wrong.

Fix: copy that message into the Developer's chat; it fixes its own files. A problem in site/content.json belongs to the Analyst, in a fresh chat. After the fix, a reload shows your site again.

The page looks unstyled, or the cards sit in one long column

Fix: reload the page in Chrome. Still wrong? Tell the Developer what you see, in one sentence. QA looks at the layout in the next Block too.

The agent wants to change site/content.json

Fix: say no. Content changes belong to the Analyst, in a fresh chat.

Fell behind?

When the Developer Block's time is up and you are not done, jump to its checkpoint. A checkpoint (the finished state of this Block) brings your site to where the room is. It keeps your own content file, design brief and spec.

First stop the agent in your old chat, if it is still working: click the stop button in the agent panel. Otherwise it can keep changing files after the checkpoint has run.

Then, in Antigravity IDE, open a terminal (the window for typing commands) with the menu Terminal → New Terminal. It opens in your portfolio folder. Paste this command (Cmd+V on a Mac, Ctrl+V on Windows, Ctrl+Shift+V on Linux) and press Enter:

Terminal · same on Mac, Windows and Linux

node tools/checkpoint.mjs developer

It lists, file by file, what it kept and what it changed. The last lines tell you what to do next: start a fresh chat and ask for QA. If it says Nothing to change, you were already there. Two Blocks behind? This one checkpoint is enough: it includes the earlier Blocks.

Or let the agent run it for you. Start a fresh chat and type:

Agent chat

Catch me up: the room just finished the Developer block.

The checkpoint adds the Developer's finished page, in the colours and fonts of your own design brief once the brief is finished. If a font of your brief is not in site/assets/fonts/, the page shows the next font in the list.

Use the Block that has just ended, not the one that starts now.