Personal Lab
This Portfolio
Personal portfolio built with Claude Design and Claude Code, on a free stack.
Personal project — the site itself is exhibit A of the method on /method.
Problem
The standard GenAI-engineer portfolio is a GitHub README or a Notion page: skill buried in wall text, no visual system, no documented method. This site closes that gap — shipped work, a documented process, and a contact in under two minutes. It is also proof that advanced prompting, run as an engineering discipline rather than a shortcut, produces artefacts that hold up.
The site you’re reading is project #1: a complete, internally consistent design system (WHITE NOON), built component by component against a token contract, every section rendering fully with all living behaviour switched off.
Constraints
- Everything free, no paid dependency: Cloudflare Pages, Vite, SIL OFL fonts.
- No prior experience with the front-end stack (Vite, GSAP, Lenis) before starting.
- The design system had to be complete and internally consistent before any production code — because otherwise the build loop produces incoherent output.
- Every section must render fully with all living behaviour switched off, so the static version is a complete, navigable document, not a shell waiting for JS.
- Launch on four shipped entries, not ten planned ones.
Approach
Design system first. Seven DNA cards synthesised into three candidates; a pairwise tournament converged on WHITE NOON — warm-white field, one decisive red line, strict token budget. Output: the design-system spec, the contract Claude Code builds against.
IA before components. The sections-IA doc resolved slug permanence, naming gates, and the graduation mechanism before any component existed — because a static host with no redirects makes a published URL permanent.
Living System specified, not improvised. The Field Conditions module — eleven named behaviours (Heliostat, New Route, Crosswind, Slipstream, Patina, Heartbeat, First Breath, Threshold Cut, Crack, Vault Blur, Scanline) — was fully specced before any JS, each with a governor, a reduced-motion fallback, and a static honest state.
Build against the spec. Component by component, each verified against its token-contract entry before the next was started.
META
Claude did
Generated the design system from a structured brief — tokens, WCAG contrast ratios, component anatomy, motion timing, the Field Conditions spec — and produced component CSS/JS from spec entries under token-only rules.
Guillermo did
Defined the seven DNA cards, ran the tournament, made every directional call, authored all constraints and content, and reviewed every generated block against the token contract before proceeding.
One exchange
The first Field Conditions draft had Heliostat and Slipstream fighting for a single governor slot. Fix: Heliostat became a governor-exempt field-state transition (≤4 crossfades/day, zero rAF); the slot now arbitrates only trace-level behaviours. That field-state-vs-trace distinction is a principle I carry into any layered animation system.
Stack & Architecture
| Models | Claude Design (direction & spec), Claude Code (implementation) |
| Build | Vite (vanilla JS), Cloudflare Pages |
| Motion | GSAP + ScrollTrigger, Lenis smooth scroll |
| Living System | Custom field-conditions module, < 8KB gzip target, localStorage only |
| Fonts | Space Grotesk, DM Sans, Share Tech Mono, Cormorant Garamond (SIL OFL, self-hosted) |
| Tokens | CSS custom properties in assets/tokens.css |
The Field Conditions module writes only --fc-* custom properties and data-attributes; components style themselves off those hooks in pure CSS. One shared requestAnimationFrame loop drives all continuous behaviours and suspends on tab-hide or when no behaviour has work.
Outcome
- A shipped portfolio with a complete, internally consistent design system (WHITE NOON), documented well enough to hand to another engineer.
- The Field Conditions Living System runs eleven named behaviours, each with a reduced-motion fallback and a static honest state, with no paid animation library beyond GSAP.
- The site is a worked example of the method it describes: every page explaining how I work with Claude was itself built with Claude.
- [PLACEHOLDER — Guillermo to confirm: Lighthouse scores, bundle size, or other measured performance facts before launch.]
Lessons
- A design system is a contract, not a style guide — it earns its cost only when it is specific enough that a code generator cannot deviate from it accidentally (token names, cap rules, forbidden states included).
- Specifying the failure mode of every ambient behaviour before any JS is written is what keeps a living system from becoming a decoration pile.
- The hardest decision was not visual — it was slug permanence and the client-naming gate, resolved before the first URL shipped, because a static host has no redirects.
Artifacts
- Design system spec — portfolio-kit/design-system.md PUBLIC (in repo)
- IA decisions — portfolio-kit/decisions/sections-ia.md PUBLIC (in repo)
- CSS tokens — portfolio-kit/assets/tokens.css PUBLIC (in repo)
- Live site — [PLACEHOLDER — Guillermo to confirm: Cloudflare Pages URL] PUBLIC
Next
- Worked-example annotated build log (a real prompt → output → correction → result sequence from the Living System build) — planned for the LLMwiki project.
- Graduate planned personal projects as they ship; each card collapses in place to the stub variant per the graduation mechanism.
HYPOTHESIS: An app shaped around one learner’s real friction beats a generic app shaped around the average user’s assumed friction — built for how I actually study Vietnamese, integrating listening, reading, and active recall in a single flow.
EXISTS TODAY: Spec drafted — input modes, session structure, and progression model are written down; no code exists yet. Scheduled after LLMwiki vault reaches its first milestone.
FIRST MILESTONE: A working session loop — vocabulary card → listening clip → typed answer → spaced-repetition scheduling — covering [PLACEHOLDER — Guillermo to confirm: vocabulary scope]. Target: [PLACEHOLDER — Guillermo to confirm: target date].
PLANNED START: [PLACEHOLDER — Guillermo to confirm: planned start quarter]
HYPOTHESIS: A reader agent ingests YouTube videos and LinkedIn reposts into a structured wiki vault; a manager agent then updates, corrects, links, and prunes entries as the field moves. A maintained knowledge base beats an ever-growing bookmark pile.
EXISTS TODAY: Agent roles defined (reader, manager), tool list and vault schema drafted (claim, source, date, confidence, linked entries, superseded-by). No code written.
FIRST MILESTONE: Manager agent successfully correcting [PLACEHOLDER — Guillermo to confirm: number of seeded wiki entries] when fed a conflicting source — claim diff logged, old version retained, link added. Target: [PLACEHOLDER — Guillermo to confirm: target date].
PLANNED START: [PLACEHOLDER — Guillermo to confirm: planned start quarter]
HYPOTHESIS: A curated, version-controlled collection of the Claude skills, prompt harnesses, and evaluation patterns proven useful across real builds. Each entry is named, tested and reusable. Formalising what works once means every future project starts one level higher.
EXISTS TODAY: Concept and motivation are clear; nothing is written or collected yet. Scheduled to start once LLMwiki vault is past its first milestone, because LLMwiki will itself generate the first batch of harnesses worth collecting.
FIRST MILESTONE: [PLACEHOLDER — Guillermo to confirm: number of harnesses] documented, individually runnable harnesses extracted from the Gestamp, Zelebrix, and LLMwiki builds — each with a one-paragraph description, a worked example, and the failure it prevents. Target: [PLACEHOLDER — Guillermo to confirm: target date].
PLANNED START: [PLACEHOLDER — Guillermo to confirm: planned start quarter]