# eve Software Factory Template: Foreman Puts Four Agents on Your GitHub Issues > Foreman is a Vercel template that turns labeled GitHub issues and Linear tasks into reviewed draft pull requests through four separate agents. It is opinionated, deploy-first, and not a general-purpose CI runner. **vercel-labs/eve-software-factory-template** — Meet Foreman, an eve Software Factory. - Repository: https://github.com/vercel-labs/eve-software-factory-template - Website: https://vercel.com/templates/eve/eve-software-factory - Stars: 1,143 · Forks: 73 - Language: TypeScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/vercel-labs-eve-software-factory-template ## What Foreman Actually Automates, and What It Refuses To The template's README describes Foreman as an "eve software factory that puts AI agents on every stage of the development loop and keeps people on the judgment calls." Read that second clause as a design constraint rather than marketing. The pipeline ends with a draft pull request on your repository; a human reviews it, marks it ready, and merges. Nothing in the README claims the agents merge code, and the local development path is described as untrusted, so changes to GitHub wait for your approval. The audience is a team that already routes work through GitHub issues or Linear and wants the first pass of implementation done before a person opens the editor. It is not for someone who wants an autonomous committer, and it is not a replacement for CI. The README's own framing is that people stay on the judgment calls, which means the review step is load-bearing, not decorative. ## The Four Stations and Why the Reviewer Is Walled Off The pipeline is four agents, each with its own instructions, sandbox, and tools. The Classifier triages a task by type, priority, and complexity, and decides whether it is actionable at all. When it is not, Foreman asks the requester instead of building the wrong thing. The Analyst turns an actionable task into a plan with acceptance criteria, working from a live checkout of your repository. The Implementer executes that plan in its own sandbox, verifies with your repository's own checks, and pushes a branch. The Reviewer then judges everything against the real diff, with evidence for each verdict. The isolation detail matters more than the four-step naming. The README states that the Reviewer sees only the pushed branch, never the Implementer's reasoning. That is a deliberate attempt to avoid a reviewer that rubber-stamps a plan it watched being written. Whether it holds up in practice depends on how much of the Implementer's intent leaks into the commit messages and diff, which the README does not address. Between runs, Foreman keeps what the README calls a factory brain: notes about your repository that every run starts from. The pipeline and memory pages are linked at ask-foreman.dev/docs, so the exact note format is documented outside this repository rather than in it. ## How Work Arrives at the Factory There are several entry points, and they differ in how much trust they assume. Labeling an issue `factory` runs the pipeline on its own, posts progress as stations complete, and ends with a draft PR linked to the issue. The label is configurable through FACTORY_LABEL and defaults to `factory`. Mentioning the bot on an issue or a pull request starts an interactive session, but the README limits who can trigger it: mentions from repository owners, members, and collaborators. That is an access control decision baked into the trigger path rather than a setting you can loosen from the environment table. Linear Agent Sessions run the same pipeline and report progress back in Linear. A local TUI accepts a task on your machine, with GitHub changes held for approval. A red CI run on a factory PR causes Foreman to diagnose the failure and push a fix, but only to its own branches, never yours; FACTORY_BRANCH_PREFIX (default `factory/`) is what marks those branches. Finally, when someone opens a pull request, Foreman posts one orienting comment for reviewers, described as a summary and not a review. ## Deploying It and Running a First Task The template is built for the Vercel deploy flow, which provisions the GitHub connector, the Linear connector, a Vercel Blob store, and prompts for FACTORY_REPO and FACTORY_LABEL. Two conditions must hold before the first deployment finishes: FACTORY_REPO must name a real repository in owner/repo format, and the GitHub App behind the connector you select must be installed with access to that repository. The deploy clones FACTORY_REPO up front to prewarm the station sandboxes, so an unreachable repository fails the deploy with a Cannot access error. The repository ships a .env.example that documents the variables. The required pair is the repository and the two connector UIDs: ```bash GITHUB_CONNECTOR=github/foreman-agent LINEAR_CONNECTOR=linear/foreman-agent FACTORY_REPO=acme/widgets ``` Optional overrides all have defaults, and the setup command is the one worth setting for a JavaScript repository, because it runs inside the station sandboxes' clone once per template build so sessions start with dependencies installed: ```bash # FACTORY_SETUP_COMMAND="pnpm install" # FACTORY_LABEL="factory" # FACTORY_BRANCH_PREFIX="factory/" # FACTORY_BOT_NAME="" ``` For local work, the README gives a three-command sequence that links the project you deployed, pulls its environment, and starts the TUI: ```bash vercel link vercel env pull pnpm dev ``` After that, hand the agent a task in the TUI, such as the README's own example about a password reset email arriving twice, and watch the four stations fire in order, ending in a draft PR on FACTORY_REPO. Local runs are treated as untrusted, so GitHub changes wait for your approval. The package manifest pins Node to 24.x and exposes the usual script set: `eve build`, `eve dev`, `eve start`, `eve eval`, plus `pnpm run validate`, which chains `ultracite check`, `tsc`, and `eve info`. ## Where the Template Pushes Back The hard dependency on a reachable GitHub repository at build time is the first real constraint. You cannot deploy the factory against a repository your GitHub App cannot see, and the failure is a deployment error rather than a runtime warning. Teams that separate deployment credentials from repository access will hit this immediately. The second constraint is platform gravity. The deploy flow is the documented path, and the connector UIDs come from Vercel Connect; the .env.example notes that manual setup means creating them with `vercel connect create` and pasting the UIDs. There is no documented self-hosted deployment in the README. If your organization requires the agent runtime to sit inside your own network, this template does not describe how to get there. The third is the branch restriction on automated fixes. Foreman only pushes CI fixes to branches carrying the factory prefix, which is a sensible safety boundary but also means it will not rescue a red build on a human's branch. And the Reviewer's independence is asserted structurally, not measured: the README does not publish an evaluation of how often the Reviewer catches a bad implementation, though the repository does contain an evals/ directory and an `eve eval` script. ## Compared With Wiring Your Own Agent Into CI The obvious alternative is assembling the same loop yourself: a GitHub Action or a small service that calls a model API, checks out the repository, runs tests, and opens a PR. That approach gives you control over the runtime, the network boundary, and the trigger rules, and it costs you the four-station separation, the factory brain, and the Linear integration, all of which you would have to design and maintain. The difference in approach is where the state lives. A hand-rolled action is typically stateless per run, with the repository as the only memory. Foreman carries notes about your repository between runs and starts each run from them, which is the part that is genuinely hard to reproduce and also the part with the least documentation inside this repository. If your tasks are one-off and unrelated, that memory buys you little. If they cluster around the same modules, it is the reason to pick this over a script. ## Licence, Maintenance, and What Upgrades Cost The template is MIT licensed, and package.json repeats that identifier, so you can fork and modify it. The practical licence question is not the template's code but the connectors and model calls it depends on: those are governed by the terms of the services behind GITHUB_CONNECTOR, LINEAR_CONNECTOR, and the underlying eve runtime, none of which the repository's LICENSE file covers. That is a question for whoever owns your vendor agreements, not something this repository answers. The last push to the default branch was on 2026-08-20, roughly a month before this writing, and the repository is not archived. There are no retrieved releases, so there is no versioned upgrade path to follow: the template is consumed by cloning it through the deploy flow, and upgrades mean pulling changes from upstream into your copy. The dependency list is narrow (eve, ai, zod, @vercel/blob, @vercel/connect, and the GitHub tools extension), which keeps the surface small, but the eve runtime is pinned to a caret range at ^0.39.3, and a pre-1.0 dependency can move under you between installs. ## Conclusion Adopt it if your team already lives in GitHub issues or Linear, wants a draft PR rather than a merge, and is comfortable running the pipeline on Vercel with a GitHub App that has access to the target repository. Do not adopt it if you need a self-hosted runner with no platform dependency, or if you expect the agents to merge on their own: every path ends at a draft PR a person marks ready. Before you deploy, verify that FACTORY_REPO names a real owner/repo and that the GitHub App behind GITHUB_CONNECTOR is installed on it, because the template clones that repository during the build and fails with Cannot access otherwise. ## FAQ ### What is the eve Software Factory template? It is a Vercel template that deploys Foreman, an eve software factory. Foreman takes tasks from GitHub and Linear, moves each through four agent stations, and delivers a reviewed draft pull request on your repository for a person to mark ready and merge. ### How do I install or deploy the eve Software Factory template? The documented path is the Deploy with Vercel button, which provisions the GitHub connector, Linear connector, and Vercel Blob store, and prompts for FACTORY_REPO and FACTORY_LABEL. The deployment clones FACTORY_REPO to prewarm the station sandboxes, so the GitHub App behind the connector must already have access to that repository. ### How do I hand an issue to Foreman? Label the issue `factory`, which is the default value of FACTORY_LABEL. The pipeline then runs on its own, posts progress as stations complete, and ends with a draft PR linked to the issue. You can also @mention the bot on an issue or PR from a repository owner, member, or collaborator account. ## Sources - [Issues](https://github.com/vercel-labs/eve-software-factory-template/issues) - [License: MIT](https://github.com/vercel-labs/eve-software-factory-template/blob/main/LICENSE) - [Project website](https://vercel.com/templates/eve/eve-software-factory) - [README](https://github.com/vercel-labs/eve-software-factory-template/blob/main/README.md) - [vercel-labs/eve-software-factory-template on GitHub](https://github.com/vercel-labs/eve-software-factory-template) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vercel-labs-eve-software-factory-template