cv is my personal site and résumé, live at niclaslindstedt.se. The interesting bit isn't the React app — it's that the CV is a single JSON object, schema-validated at build time, and re-projected into every visible artifact: the rendered site, a bilingual PDF, an OG share image, a sitemap, an in-page search index, and a couple of agent-facing files at /resume.json and /llms.txt.
The CV data lives across a handful of JSON files — one per category, like projects.json, experience.json, companies.json, skills.json. They get merged at build time into one assembled object, and everything else reads from that: the React app, the PDF pipeline, the validator, the /resume.json generator. One shape, one source.
A small validator<sup>1</sup> runs the assembled object through the JSON Schema in schemas/cv.schema.json before anything ships. Anything that breaks the schema fails the build.
That's why a coding agent can update it. The schema is the contract; the validator tells the agent whether an edit is well-formed before it lands. To bootstrap the data I pasted in an old CV and let the agent turn it into the structured shape — from there it's just normal editing. Updating Word PDFs has always been a pain and working with Word files through an agent is not optimal — it never looks as good as I want it to. The CV project has been iterated on until it just feels right.
\nAn update-cv skill in the repo<sup>2</sup> codifies the editing rules so the agent doesn't have to guess. It picks the right file, runs the validator before declaring done, and — because most user-facing strings are { "en": ..., "sv": ... } pairs — writes the Swedish version alongside the English whenever I add or revise a description. Both end up at the same level of polish; the Swedish copy isn't a translation pass tacked on after the fact.
One layer doesn't ship publicly. cv.local.json is gitignored and deep-merged on top of the assembled CV when CV_LOCAL=1 is set — full contact details, longer descriptions, anything I don't want indexed on the open web. make local runs the build with the override active and produces a separate set of PDFs under a different filename. That's the version I actually send when I apply for a job; the public site stays scrubbed.
Not all the CV data is hand-written. Per-project commit stats — total commits, first and last commit dates, year-by-year activity — get pulled from the GitHub GraphQL API at build time<sup>3</sup>. For open-source projects, only my own commits count toward the totals, not those of every contributor. The numbers show up on each project card and are inlined into /resume.json so an agent fetching the JSON gets the activity data without an extra API roundtrip.
Token-less builds (a fresh clone, an external contributor's PR, an ad-hoc local PDF) fall back to a cached copy on a separate data-cache git branch that a scheduled workflow refreshes. The CV doesn't blow up because GitHub returned a 401.
The web CV exposes a lot, but it doesn't shove it at you. Top level: the summary, the focus areas, the projects, the jobs, the skills, the degrees, the languages — each as a card. Click a project and you get the full description, the stack, the skills used, and external links. Click an education entry and you get the program structure, the courses, the credit transfers. The course lists for an entire degree are right there if you want them, but they're behind a click — don't click programs if you don't want course lists. The front page stays scannable; the depth is there for the readers who actually want it. The PDF respects the same idea by collapsing the deep stuff entirely.
\nThe timeline page does something a flat CV can't: it shows how things relate to each other in time. Overlapping engagements, parallel side projects, gaps and clusters — all visible at a glance. It's a separate page (/timeline), but it reads from the same experience.json and projects.json that everything else does.
A search modal sits one keystroke away on the main résumé page. Type a few letters and matches show up grouped by category — projects, jobs, skills, degrees. The index itself is generated at build time from the assembled CV<sup>4</sup> and committed as static JSON, so what's searchable is exactly what's on the page — no separate authoring surface to drift. The ranker is hand-written; no third-party search library. Each searchable record carries a few hidden aliases so common abbreviations like k8s, TS, and react resolve to the right entry without cluttering the visible copy.
That covers the site. The same assembled CV also drives:
\nA bilingual PDF, English and Swedish. A simpler print-only layout gets rendered to static HTML, then opened in a headless browser and saved as a PDF<sup>5</sup>. The PDF doesn't go through the React app at all, so what comes out is identical every time. PDF metadata (Title, Author, Subject, Keywords) gets stamped on the way out so the file shows up correctly in document readers and search results.
\nA social share image — the 1200×630 banner that appears as the preview when someone pastes the URL into Slack, LinkedIn, Twitter, or iMessage. Generated from the same CV via satori. Without one, social previews either fall back to a tiny favicon or skip the preview entirely. With one, the link looks like a polished card with my name, title, and tagline.
\nSEO scaffolding. A page nobody can find is a page that doesn't exist. The site's <head> carries Open Graph and Twitter card meta tags, a canonical URL, a meta description, and JSON-LD structured data describing me as a Person and the site as a WebSite — all derived from the same CV data, all injected at build time. That's what Google reads when it decides what to show in search results, and what LinkedIn or Slack reads when generating a link preview.
Pre-rendered homepage HTML. A single-page React app normally ships an empty <div id="root"> that the browser hydrates on load — which means crawlers and curl see a blank page. The build server-side renders the React tree once and bakes the result into dist/index.html, so no-JS clients get the actual résumé text and search engines index the real content.
A machine-readable /resume.json. The whole CV as a single JSON file, served straight from the site root. Agents can fetch the structured source instead of scraping HTML. /cv.json is a byte-identical alias for the path LLMs commonly guess. Both are discoverable via robots.txt, sitemap.xml, and <link rel="alternate"> tags in the <head>.
An /llms.txt index<sup>6</sup> following the llmstxt.org convention. A small markdown file pointing agents at /resume.json, with the experience and side-project sections baked inline so an agent that only fetches this one file can still answer "which jobs are listed there".
A sitemap. dist/sitemap.xml lists /, /timeline, /resume.json, /cv.json, and /llms.txt; robots.txt points at it. Generated alongside everything else so the URLs stay in sync if anything moves.
Two small build-time helpers tie the pipeline together. One merges the JSON parts into the single assembled object the rest of the build reads from. The other injects the SEO <head> block into the HTML at build time, derived from the same CV data.
The build then runs the generators in sequence — type-check, bundle, then the PDF, /resume.json, /llms.txt, the timeline page, the sitemap — with a few pre-build steps for the timeline data, GitHub activity, and per-project commit stats. The data fetchers degrade gracefully: if a GitHub token isn't configured, the per-project commit stats simply drop out instead of failing the build.
Most of the building blocks are old — schemas, SSR, headless-Chromium PDFs. What I haven't seen elsewhere is treating the schema as a guardrail an agent can edit against, and treating the LLM as a first-class consumer at the same level as the browser. Together those push the work out of "writing a CV" and into something I hand to an agent and review like code.
", "date_published": "2026-05-07T13:06:01Z", "date_modified": "2026-05-13T13:17:42Z", "tags": [ "cv", "typescript", "react", "vite", "resume" ], "authors": [ { "name": "Niclas Lindstedt", "url": "https://niclaslindstedt.se" } ] }, { "id": "https://blog.niclaslindstedt.se/posts/2026-04-22-what-zag-is-and-why-it-exists/", "url": "https://blog.niclaslindstedt.se/posts/2026-04-22-what-zag-is-and-why-it-exists/", "title": "What zag is, and why it exists", "summary": "A meta-agent CLI that unifies Claude, Codex, Gemini, Copilot, and Ollama so swapping providers is a flag change.", "content_html": "zag is a meta-agent CLI with multiple language bindings that let devs code against a unified CLI, so switching between Codex and Claude is as simple as switching a flag. It's written in Rust and published as zag-cli on crates.io.
New models are released every now and then, and most often the newest model is the best one. Unless it is a major jump, it doesn't make sense to adapt all your processes to a different agent CLI, so mostly you are stuck with the worse model until your agent provider releases a new model. zag solves this by unifying the CLI interface for Claude, Codex, Gemini, Copilot, and Ollama. All parameters are mapped internally to the correct one for each agent flavor. zag goes further with size aliases: -m small, -m medium, -m large resolve to the right model per provider, so you can pick a class of model without memorising each vendor's name for it. -p auto -m auto takes it another step — an LLM picks both the provider and the model for you. zag also unifies the output: it tails the agent session logs and turns them into a zag session log.
zag has language bindings for TypeScript, Python, C#, Swift, Java, and Kotlin, helping users programmatically call the agent CLI of their choice. These bindings wrap the zag CLI under the hood, except for the native Rust binding, which re-exports the workspace crates directly with zero subprocess overhead.
\nEach binding exposes a fluent builder with typed output and a live event stream, so you get the agent's responses, tool calls, and thinking as structured events in your language of choice instead of parsing stdout yourself. The examples/ directory shows a few things this unlocks:
\nzag exec and zag input and piping NDJSON events over Server-Sent Events.The obvious one is an agent chat interface tailored to your own workflow, but anything that wants to run an agent from inside a larger program — a queue worker, a dashboard, an IDE plugin — fits.
\nzag uses the actual CLIs and not SDKs. It's meant to run on your own computer, not as a cloud service. That means you can use your subscription without spending 10x on API calls.
\nzag has a bunch of orchestration-enabling commands that make orchestration code a lot easier. The follow-up project zig — also a Rust CLI, published as zig-cli — uses these to provide natural-language orchestration. You tell it what kind of workflow you need, and zig helps you set that up, using zag to avoid getting stuck with a specific provider.
zag ships isolation primitives that work the same across every provider. -w / --worktree runs the agent inside a dedicated git worktree so it can't stomp on your checkout; --sandbox runs it inside a Docker microVM. Both are tracked per-session, so resuming restores the right workspace.
zag has a built-in client/server mode. zag serve starts an HTTPS/WebSocket server on one machine; zag connect on another makes all subsequent commands transparently proxy through. Leave the heavy lifting on your home machine and drive it from your work laptop. If the remote becomes unreachable, zag falls back to local execution automatically.
This post is the high-level pitch; most of what zag actually ships is features I haven't touched yet. Some of the bigger ones I'll come back to:
\n--json, --json-schema with automatic retry, and NDJSON event streams.~/.zag/, and zag syncs it into each provider's native config format.zag listen, zag events, zag subscribe, zag watch, zag search to tail, query, and react to a session's event stream.claude → codex → gemini → copilot → ollama) that keeps scripts working when a CLI is missing or unauthed.zag review and zag plan, plus zag discover to enumerate what each installed provider can actually do on this machine.I will write more about zig in later blog posts.
", "date_published": "2026-04-22T14:52:36Z", "date_modified": "2026-05-13T13:17:42Z", "tags": [ "zag", "meta-agent", "cli", "rust" ], "authors": [ { "name": "Niclas Lindstedt", "url": "https://niclaslindstedt.se" } ] }, { "id": "https://blog.niclaslindstedt.se/posts/2026-04-22-how-this-blog-works/", "url": "https://blog.niclaslindstedt.se/posts/2026-04-22-how-this-blog-works/", "title": "How this blog works", "summary": "A git-tracked blog where I write the prose and a Claude skill pulls my own repos, cites the files, and ships a non-technical version alongside.", "content_html": "Since ideas are more interesting than the code, we need a place to store the ideas. The code is already stored by GitHub. This blog stores the ideas behind the code.
\nThe blog itself is a GitHub repository served by GitHub Pages. It's built on React, and the posts are markdown files with YAML frontmatter for metadata<sup>1</sup>. None of that is the interesting part — terminal UIs in the browser were possible ten years ago. What's new is that writing a post involves invoking a Claude skill<sup>2</sup>. The skill pulls down whichever of my public repositories are relevant to the post<sup>3</sup>, walks their commit history<sup>4</sup>, reads the files the post actually touches, and turns bare project names into links and concrete claims about code into footnotes that open the source in place<sup>5</sup>. I don't want Claude inventing facts about my code. Citations force it to open the file first.
\nI write the posts. Claude structures them into markdown, adds the links, files them where they belong, and deploys to GitHub Pages<sup>6</sup>. It also rewrites every post in a non-technical version, and either version can stand alone, because sometimes the tradeoff I care about is different for a dev than for my parents.
\nThe past year I've been experimenting with spec-driven development and CLIs that lift logic out of prompts and into the tool itself. If the rules live in a prompt they drift. If they live in the binary they don't. oss-spec is what this blog itself conforms to, and I'll be writing about that approach along with the other tools I've built around it. They're all open source on my GitHub.
\nI don't usually blog, but when I do, it's mostly a tech demo.
", "date_published": "2026-04-22T05:51:05Z", "date_modified": "2026-05-13T13:17:42Z", "tags": [ "blog", "meta", "claude-code", "spec-driven-development" ], "authors": [ { "name": "Niclas Lindstedt", "url": "https://niclaslindstedt.se" } ] } ] }