Frontman: an MCP proxy inside the dev server that edits source from a browser click

The dev server becomes an MCP server answering at localhost/frontman

Frontman does not start from your source files. The framework integration turns your local dev server into an MCP server, and the agent queries it for two categories of context. On the client side it gets the DOM tree, computed CSS, screenshots and the current element selection. On the server side it gets routes, server logs, query timing and compiled modules. That split is the design: the browser is the starting point and the source file is derived from it, through source maps, which is also why the tool claims to beat IDE based agents at knowing which component owns a given node. The chat interface then sits on a path of its own, localhost/frontman, next to the live view of the app rather than in a separate window. There is a second entry point outside the browser. Frontman ships as an OpenClaw skill and the tree carries an openclaw-skill/ directory for it:

openclaw skill install frontman-dev

The stated split of duties is blunt: OpenClaw for general purpose automation covering shell, messaging and files, Frontman for precise visual editing inside your codebase.

The Next.js install leaves one generated file to move by hand

The Next.js quickstart is four lines, and the second one is a manual fixup rather than something the installer does for you:

npx @frontman-ai/nextjs install
# If your project uses src/: mv proxy.ts src/proxy.ts
npm run dev
# Open http://localhost:3000/frontman

A project that keeps its sources under src/ therefore ends up with the generated proxy file at the repository root until somebody moves it, and the quickstart gives no reason the installer writes it there in the first place. Both routers are covered, App Router and Pages Router, and Turbopack is named as compatible. Once the page is open the loop is a click and a sentence: select the element, describe the change, and the edit lands in whichever component or stylesheet the source maps say owns that DOM node. The examples the project picks are all small frontend changes, copy swaps, spacing fixes, a button on one internal route, with the diff reviewed before it lands.

Astro sets a Node floor while Vite guesses the framework

Astro is the only stack with an explicit version floor: Astro 5, 6 and 7 on Node.js 22.19 or newer. Its integration sits in the Astro integration registry and is described as understanding Islands architecture, content collections, and SSR and hybrid modes. The install is two commands and a port:

npx astro add @frontman-ai/astro
npm run dev
# Open http://localhost:4321/frontman

Vite goes through the package installer instead of the registry and, rather than a version list, auto-detects the framework from vite.config, covering React, Vue and Svelte, SvelteKit included:

npx @frontman-ai/vite install
npm run dev
# Open http://localhost:5173/frontman

Three stacks, three different ports, three different install shapes. The Astro path resolves through an astro add command against a registry, while the other two invoke npm names directly, so any setup automation that spans more than one framework has to know which of the three it is looking at before it can run anything.

A WordPress library is a workspace, and WordPress is on no list

package.json declares 23 workspaces, and one of them is libs/frontman-wordpress. The supported stacks table lists Next.js App Router, Next.js Pages Router, Astro, Vite, React, Vue, Svelte and SvelteKit as available now, then Remix, Nuxt, SolidStart, Qwik and Phoenix LiveView as coming soon. WordPress appears in neither row, even though a library for it is wired into the monorepo and the build. The workspace list does explain how the rest is layered: libs/frontman-core and libs/frontman-protocol sit under libs/frontman-client, libs/frontman-preview-bridge, and per framework adapters for astro, nextjs and vite, alongside libs/bindings, libs/logs, libs/react-statestore and libs/experimental-rescript-webapi. So the WordPress question is a real gap rather than a naming coincidence. Whether that workspace is a shipped integration, a stub, or a port nobody has finished cannot be read off the table, and neither the workspace list nor the supported stacks row says which it is.

The licence has three different answers inside one checkout

package.json declares Apache-2.0. The comparison table in the README puts the project under Apache 2.0 / AGPL-3.0 in its open source row, without saying which of the two covers which part. The tree then carries LICENSE next to COMMERCIAL-LICENSE.md, AI-SUPPLEMENTARY-TERMS.md and TRADEMARK.md, and a pricing.md at the root. GitHub's own licence field for the repository comes back empty, so the project page resolves nothing either. Those files are four different instruments: a base licence, a commercial one, a set of extra terms aimed at AI usage, and a trademark policy, and a reader has to work out which layer governs a given file. Anyone planning to build on this, or to vendor one workspace out of it, should read all four instead of trusting the single field in package.json.

A development only tool sits next to a committed .env and a railway.json

The supported stacks section makes a strong claim: framework integrations run in development mode only, production builds strip Frontman out, and the deployed bundle is identical whether Frontman is installed or not. That claim is about build output and nothing in the tree checks it. What the tree does hold is the other kind of evidence. There is a .env file committed at the repository root, and the Makefile's own error text routes infrastructure targets through it, telling you to run op run --env-file=.env -- make with a target name. Next to that sit railway.json, an infra/ directory, .dockerignore and a .devcontainer/. A tool that strips itself out of production can still have a server side, but nothing says which components railway.json is meant to deploy. A committed .env at the root raises the other question the README leaves open: which values in it are placeholders and which are real.

The Makefile opens on help, and two target groups refuse to guess

Running make with no arguments prints help, because .DEFAULT_GOAL is help and the help text is split into seven sections: DEVELOPMENT, BUILD, SSL, WT, REL, E2E and UTIL. Two of those groups are guarded. Anything needing the DevPod server refuses to run when DEVPOD_SERVER is unset and points at the env file instead. Branch targets are friendlier: BRANCH is auto-detected from git branch --show-current and errors only if that detection comes back empty, in which case it asks for make with a target and BRANCH=feature-name. End to end tests carry their own gate, since run_e2e exits unless test/e2e/.env exists, telling you to copy test/e2e/.env.example and fill in values before sourcing it and running vitest inside test/e2e. The six development targets are dev, dev-client, dev-server, dev-nextjs, dev-nextjs-prebuilt and dev-marketing, which is the clearest statement of the split: client, server, two Next.js test sites and the marketing app.

Three major versions in 25 days, and four sets of agent instructions

Tags move in bursts: v5.0.0 on 4 September 2026, v5.1.0 on 8 September, v5.2.0 on 28 September. Code was pushed on 2 October 2026, so the working tree sits ahead of the newest tag again. The counters are 708 stars, 51 forks and 237 open issues, and that issue count is the one worth pausing on for a project whose pitch is that non technical teammates file small fixes that never reach a developer. Changes are recorded with changesets: .changeset/ sits next to CHANGELOG.md, so release notes are generated rather than written by hand. The repository also carries four separate conventions for telling a coding agent how to work in this codebase, CLAUDE.md, AGENTS.md, .cursorrules and agent_docs/, plus mise.toml and lefthook.yml for the toolchain. Which of the four wins when they disagree is not something the tree answers.

Editorial conclusion

Judgment: Frontman is a good fit for teams whose frontend fixes are small and frequent, and a poor fit for anyone who needs a verified production story from the docs. The context it gives an agent, live DOM plus computed CSS plus source maps, is the real contribution; everything around it, the manual proxy move, the dev only guarantee, the four license files, the WordPress workspace nobody documents, is unresolved in the repository. Before adopting it, read COMMERCIAL-LICENSE.md and AI-SUPPLEMENTARY-TERMS.md next to package.json, confirm the dev only claim against your own build output, and check the issue tracker, since 237 open entries against 51 forks is not a number this README explains.

Frequently asked questions

Official sources

1. frontman-ai/frontman on GitHub
2. Issues
3. Project website
4. README
5. Releases