Stop 2 of 9 · Weekly
A site with Claude Code
A Figma export becomes a repository: the brief, four checks wired to every pull request, the phone pass on the branch preview, and the merge Dany does herself.
The build is a repository now
One landing page fits in one HTML file. A five-page site for Verde Landscaping does not. When Dany moved the hand-coded work into one repository per client, three things became possible: two people editing the same site without emailing zip files, a preview address per branch, and checks that run before anybody merges. Claude Code works in that repository the way Mo does, in branches.
The unit of work is one branch, one pull request, one preview. Nothing else about a client site changes.
The brief, and why the Figma export is not it
Export the frames as PNG at 2x into design/, and export the variables or styles as a text file if the Figma file has them. Then write down the part a picture cannot carry.
| The frame shows | You still have to say |
|---|---|
| The layout at one width | The breakpoints, and what stacks first |
| Colours as pixels | The hex values, and which one is the text colour |
| A heading | The font, the fallback, the weight, the scale |
| A button | What it does on tap, and where it goes |
This repository is verde-landscaping, a five page site for a landscaping company: home, services, projects, about, contact. design/ has one PNG per page exported at 2x, and tokens.txt has our colours, type scale and spacing steps. Build plain HTML and CSS, no framework and no build step. One stylesheet built from the tokens, one partial per shared piece. Mobile first from 360 pixels. Use components from ../studio-kit wherever one fits, and tell me which ones you used. Work on a branch called build/initial and stop before opening a pull request. Show me the file tree and the home page first, and list anything in design/ you could not build as drawn.
Four checks worth having
Dany's checks are not unit tests. They are the four questions she used to ask herself at eleven at night, written as scripts that either pass or do not: every internal link resolves, every image has alt text or an explicit empty alt, headings run in order with one h1 per page, and no page loads more than 500 kilobytes.
Write four small Node scripts in checks/, one per rule: internal links resolve to a file that exists, every image has alt text or an explicit empty alt, headings are in order with one h1 per page, and no page exceeds 500 kilobytes on first load. Each prints its failures with the file and the line, and exits non-zero if there are any. Then add a GitHub Actions workflow that runs all four on every pull request. Run them locally first and show me what fails on this branch as it stands.
The review pass on a phone
The branch gets a preview address. Dany opens it on her own phone, on mobile data, standing up, because that is how the client's customers will see it.
[paste the preview address for the branch] Open this at 390 pixels wide and walk all five pages as a visitor on a slow connection. For each page tell me what is on screen before I scroll, anything I have to pinch to read, tap targets under 44 pixels, anything that moves after the fonts load, and how long until the hero image appears. One table, worst first, then the three fixes that change the most for a visitor.
The pull request a person merges
Open the pull request from build/initial into main. In the description: what this branch adds page by page, which studio-kit components it uses, the result of each of the four checks, the three things you were unsure about and guessed, and anything in design/ you could not build. Do not merge it.
Dany reads the diff, opens the preview, merges. The host builds from main. That is the only door in.