Contact
Menu
EN 中文
All work

WebForge

Edit websites by chatting with an agent built on the Claude Agent SDK

Prototype Solo

No public link. This page describes the problem, decisions and outcome.

At a glance

Problem
Small website changes usually wait for an engineer.
What I built
WebForge is a browser app where you pick a website project and tell it what to change in plain language.
Outcome
A working prototype in 3 days; chat-to-commit, multi-project switching and the file sidebar each passed a recorded acceptance smoke test.
My role
Solo
Period
2026-05-25 → 2026-05-27

Abilities shown

Each links to the ability and its level on the Skills page.

The problem

Small website changes usually wait for an engineer. The people who own the content cannot touch the code, and should not need git to publish a fix. I wanted to see whether an AI agent could sit between them and the repository, and what guardrails it would need.

What I built

WebForge is a browser app where you pick a website project and tell it what to change in plain language. An agent reads and edits files inside that project only. After each turn it drafts a commit message, and nothing is written to git until you confirm, edit or discard it. A right-hand panel shows the file tree, file previews, and the live Staging and Production builds.

It is a pnpm monorepo with three packages: a Node server, a React web client and a shared typed protocol. I built it with Claude Code over 5 written plans (milestones M1 to M4, with M3 split in two), plus design specs and acceptance notes.

How it works

  1. The server scans a projects folder and lists every site with a git repo and a .webforge.json config.
  2. Opening a site starts an Agent SDK session with its working directory locked to that folder. The SDK session id is captured so later turns resume the same conversation.
  3. Agent output (text, tool calls, results) streams to the browser over Socket.IO, character by character.
  4. At the end of a turn the server diffs the work tree and sends a commit proposal. On accept it makes the commit and pushes to a staging branch.
  5. A watcher polls Cloudflare Pages every 5 seconds and reports the staging and production build states.
  6. “Go live” fast-forwards staging into main. “Start over” resets staging to main with a force-with-lease push. Both open a confirmation dialog first.

Decisions

  • Agent SDK, not a wrapped CLI. Claude Code, Cowork and the Agent SDK share one engine; a custom GUI on the headless SDK gives typed events instead of parsing terminal output.
  • The agent drafts, the person makes the commit. Every change passes a confirm step, so a bad turn can be thrown away before it reaches history.
  • Deployed previews instead of local dev servers. The target users are not engineers, so the preview had to be the real deployed site, not a Node process on a port. I dropped the original local-server plan mid-project.
  • Git stays invisible. Users see two previews and two buttons; branches, ports and deployment ids never appear in the interface.

Outcome

A working single-user prototype, run locally and not deployed for others. Chat-to-commit, multi-project switching and the file sidebar each passed a recorded acceptance smoke test. The prototype was built between 25 and 27 May 2026.