Frontman: A Browser-Resident Agent That Edits Your Source Files
The AI agent that lives in your framework/browser
At a glance
- What is it?
- Frontman is an AI coding agent that runs inside your local dev server and edits source files from a click in the live DOM. It is aimed at small frontend fixes that normally stall in design QA, and its real constraint is that it only knows what your dev server can tell it.
- Who is it for?
- Adopt Frontman if your bottleneck is small visual fixes on a Next.js, Astro or Vite dev server and you want the diff to arrive through your existing review process. Do not adopt it if your edit requires backend logic, data model changes, or context outside the running app, because the agent's inputs are limited to what the framework middleware exposes: DOM tree, computed CSS, routes, server logs and source maps.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly ReScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The handoff cost Frontman Is Trying To Remove
The README frames the problem as handoff overhead: a designer or PM spots a spacing issue, a wrong label, or a mobile card that does not match desktop, and the fix waits for a developer to open an IDE. The change itself is small. The queue is not. Frontman's stated target is that category of work, described in the README as "small frontend changes that usually get stuck in design QA, product review, or internal tooling backlogs."
The audience is split deliberately. Product managers and designers are named as people who can fix copy, spacing, colors and layout without waiting. Frontend developers are named as people who want more context than a terminal-based tool gives, specifically because Frontman reads the rendered page rather than only the source. The third group is teams where the handoff costs more than the edit.
That framing has a consequence worth stating: Frontman is not positioned as a general coding agent. It is positioned narrowly, and the README's own comparison table puts it beside Cursor, GitHub Copilot and v0 as complementary rather than competing. If your backlog is mostly backend work, the browser-first premise buys you nothing.
Framework Middleware As An MCP Server
The mechanism is the part worth understanding before installing anything. According to the README, the framework integration "turns your local dev server into an MCP server that the AI agent queries." That is the whole architecture in one sentence, and it explains both what Frontman can do and where it stops.
The agent queries that server for two classes of context. Client-side context covers the DOM tree, computed CSS, screenshots and the element you selected. Server-side context covers routes, server logs, query timing and compiled modules. Source maps tie the rendered element back to the file that produced it. The README describes the result as knowing "the element's position in the component tree, its computed styles, and the server-side context."
Because the integration lives in the dev server, the data flow is local: your browser talks to a chat interface served at a path on your own dev server, the agent asks the MCP endpoint for context, and the edit lands in your source files with hot reload applied. Nothing in the README describes a hosted build step or a cloud copy of your application. What it does not say is where the model inference happens. That is a gap you should close before letting non-developers use it on a private codebase.
The choice to start from the browser and work backward to source is the design decision everything else follows from. It is also why the tool is framework-specific rather than editor-specific.
Install Commands For Next.js, Astro And Vite
Three integrations are documented, each with its own install path and its own entry URL.
Next.js uses a project-local installer, and the README flags one manual step for projects that keep code under src/:
npx @frontman-ai/nextjs install # If your project uses src/: mv proxy.ts src/proxy.ts npm run dev # Open http://localhost:3000/frontman
That mv command is the kind of detail that decides whether setup succeeds. The installer writes proxy.ts at the project root, and a src/ layout expects it elsewhere. The README states App Router and Pages Router are both supported, and that it is compatible with Turbopack.
Astro goes through Astro's own integration command:
npx astro add @frontman-ai/astro npm run dev # Open http://localhost:4321/frontman
The README states compatibility with Astro 5, 6 and 7 on Node.js 22.19 or newer, and says the integration understands Islands architecture, content collections and SSR or hybrid modes. Note the Node floor: 22.19 is a hard number, not a suggestion.
Vite covers React, Vue and Svelte, including SvelteKit:
npx @frontman-ai/vite install npm run dev # Open http://localhost:5173/frontman
The README says the Vite installer auto-detects your framework from vite.config. There is also an OpenClaw skill path for teams already running that agent, installed with openclaw skill install frontman-dev. The README does not publish a config key reference in the material available here, so treat the installers as the supported surface and check the per-framework docs pages for anything beyond them.
What The Browser-First Approach Cannot See
The limitation is structural, not a bug. Frontman's inputs are whatever the dev server middleware can expose: DOM tree, computed CSS, screenshots, element selection, routes, server logs, query timing, compiled modules and source maps. Anything outside that set is invisible to it.
So an edit that depends on production-only behaviour, an environment variable that differs locally, a database migration, a background job, or a third-party API response is not something this tool has context for. The README's own examples stay inside the boundary: copy changes, spacing, colors, layout, internal UI polish, and a button on an internal sub-page. Nothing in the material suggests the agent reasons about backend code.
There is a second, quieter constraint. The agent resolves a rendered element to a source file through source maps and the component tree. That resolution is only as good as the build's source map quality. A project with minified or stripped maps in the dev pipeline gives the agent less to work with, and the README does not describe a fallback for that case.
Finally, the tool assumes a running dev server. If your workflow is a static build pipeline or a remote preview environment, the premise does not apply. Frontman is a development-time tool, and the README never claims otherwise.
Cursor, Copilot And v0: Different Starting Points
The README's comparison table is the clearest statement of positioning, and it is worth taking at face value rather than as marketing. Cursor and GitHub Copilot start from source files in an IDE and do not see rendered output. v0 generates new code inside its own sandboxed preview. Frontman starts from the rendered page and edits your existing codebase.
That difference in starting point produces a real difference in failure modes. An IDE-based tool can reason across the whole repository, including backend services, tests and configuration, because it reads files. Frontman cannot, because its context comes from a running app. Conversely, an IDE-based tool has to be told which file owns a rendered element; Frontman resolves that from the DOM and source maps, which is precisely the step that stalls non-developers.
v0 is a different kind of alternative again: it produces new UI in a sandbox rather than modifying what you already have. If your problem is generating a starting point, v0 addresses it and Frontman does not. If your problem is that a shipped page has the wrong padding on mobile, the reverse is true.
The README states plainly that these tools are complementary and that many developers use Cursor or Copilot for backend work and general refactoring, then switch to Frontman for visual editing. That is a reasonable division, and it is also a warning against treating Frontman as a replacement for your editor.
Release Cadence, Licence Split And Upgrade Cost
The version history in the supplied material shows v4.0.0 on 2026-08-27, v5.0.0 on 2026-09-04 and v5.1.0 on 2026-09-08. Three releases in under two weeks, including two major bumps. That cadence tells you the project is moving quickly and that major-version upgrades are frequent enough to plan for. It also means the integration surface (the installer, the proxy file, the MCP endpoint) is the part most likely to change between majors, so pinning a version in CI is a practical precaution rather than a stylistic one.
The licence is the part that needs care. The repository metadata reports NOASSERTION, while the README badge and text state Apache 2.0 / AGPL-3.0. A dual licence with an AGPL option is not the same as a permissive licence. AGPL obligations attach to network use in ways Apache 2.0 does not, so if you serve a modified version of the covered code to users, the terms you are operating under depend on which side of the split applies to the component you modified. The README does not break down which parts fall under which licence. This is not legal advice: read the LICENSE file in the repository and get your own answer before shipping anything derived from it.
Maintenance cost beyond upgrades is not documented in the material here. There is no stated support policy, no compatibility matrix beyond the Astro version range and the Node 22.19 floor, and no deprecation timeline. Budget for reading release notes before each major bump.
Who Should Install It, And What To Check First
The case for adoption is narrow and clear. You run a Next.js, Astro or Vite dev server. Your recurring pain is small visual and copy fixes that sit in a queue. You want those changes to arrive as a diff in your normal review process rather than as a Slack message. Frontman is built for exactly that, and the README's three-step flow (developer installs once, anyone opens localhost/frontman, click and describe) is short enough to hand to a non-developer.
Do not install it expecting an agent that understands your backend, your data layer or your build configuration. The context it receives is bounded by the dev server middleware, and nothing in the material suggests otherwise. Teams with no dev-server workflow, or teams whose frontend changes are almost always structural rather than visual, will get little from it.
Three things to verify before a wider rollout. First, whether your project keeps code under src/, because the Next.js path requires moving proxy.ts and the README calls that out explicitly. Second, where model inference runs and what page context leaves your machine, since the README documents the local MCP context flow but not the inference endpoint. Third, the licence question above, particularly if you distribute or host a modified version.
If those three check out, the install is one command and the entry point is a URL on a server you already run. If any of them does not, the browser-first premise does not rescue you.
Editorial conclusion
Adopt Frontman if your bottleneck is small visual fixes on a Next.js, Astro or Vite dev server and you want the diff to arrive through your existing review process. Do not adopt it if your edit requires backend logic, data model changes, or context outside the running app, because the agent's inputs are limited to what the framework middleware exposes: DOM tree, computed CSS, routes, server logs and source maps. Before rolling it out to non-developers, verify the proxy placement on a src/ layout project, confirm your team is comfortable with an LLM provider receiving rendered page context, and check which of the two licences applies to your distribution model.
Community notes