eve Software Factory

The eve Software Factory (Foreman) is an open-source Vercel template that deploys an AI-powered development pipeline, turning GitHub and Linear tasks into reviewed draft pull requests with humans making the final judgment calls.

What is the eve Software Factory?

The eve Software Factory is a deployment template built on the eve agent framework, created by Vercel Labs. It accepts tasks from GitHub issues, GitHub pull requests, and Linear issues, then moves each task through four AI agent stations — Classifier, Analyst, Implementer, and Reviewer — and outputs a reviewed draft pull request linked to the original task. The template runs on Vercel and uses Vercel Connect to integrate GitHub and Linear connectors out of the box.

Key Features

• Four-agent pipeline — Each station is an independent agent with its own instructions, sandbox, and tools: the Classifier triages task type, priority, and complexity; the Analyst writes a plan with acceptance criteria; the Implementer executes in its own sandbox and verifies with your repository's checks; and the Reviewer independently judges the diff with evidence.
• Factory brain — Persistent notes about your repository are stored between runs, so every new run starts from accumulated context (documented at ask-foreman.dev/docs/memory).
• Multiple task entry points — Label an issue factory, @mention Foreman on an issue or PR (for owners, members, and collaborators), delegate via Linear Agent Sessions, hand a task through the local dev TUI, or trigger on red CI.
• Automated CI fix handling — When a factory PR's CI fails, Foreman diagnoses the failure and pushes fixes only to branches it owns, using the FACTORY_BRANCH_PREFIX (default factory/) to avoid touching your branches.
• PR orientation comments — When someone opens a pull request on the target repo, Foreman posts a single orienting comment with a summary, not a full review.
• One-click Vercel deploy — The deploy flow automatically configures the GitHub connector, Linear connector, Vercel Blob store, and prompts for FACTORY_REPO and FACTORY_LABEL environment variables.
• Environment-driven configuration — Besides the two required variables, optional variables include FACTORY_SETUP_COMMAND (runs once at build time to install dependencies), FACTORY_BRANCH_PREFIX, and FACTORY_BOT_NAME (resolved from the GitHub App slug when unset).
• MIT licensed with full pipeline and memory documentation at ask-foreman.dev/docs.

Who is it for?

• Engineering teams that want AI agents to triage, plan, implement, and review tasks while keeping humans on final merge decisions.
• Open-source maintainers who want to automatically generate reviewed draft PRs for issues labeled with a specific label, reducing triage overhead.
• Vercel users who rely on Vercel Connect to wire GitHub and Linear without writing webhook or auth infrastructure.
• Developers who prefer a local workflow — the dev TUI lets you hand a task to the factory locally, and any GitHub changes wait for your approval.

What can you do with the eve Software Factory?

• Maintainers: label an issue factory to trigger the pipeline automatically; Foreman posts progress as stations complete and ends with a draft PR linked to the issue.
• Developers: @mention Foreman on an issue or PR to start an interactive session that reports progress and delivers a draft PR.
• Linear users: run Linear Agent Sessions to execute the same pipeline and see progress updates back in Linear.
• Local testers: run the TUI with pnpm dev after linking and pulling environment variables, and watch the four stations fire in order on a real task.

How does the eve Software Factory work?

The pipeline starts when a task arrives (e.g., an issue labeled factory). The Classifier first triages the task — type, priority, complexity, and whether it's actionable; if not, it asks the requester instead of building the wrong thing. The Analyst then turns the task into a plan with acceptance criteria against a live checkout of the repository. The Implementer executes the plan in a sandbox, verifies with your repo's own checks, and pushes a branch. Finally, the Reviewer independently examines the real diff with evidence for each verdict. Between runs, the factory brain persists notes about the repository so future runs start with that context.

FAQ

What does the FACTORY_REPO environment variable do?

FACTORY_REPO names the GitHub repository the factory works on, in owner/repo format. The deployment clones this repo up front to prewarm station sandboxes, and the connected GitHub App must have access to it; otherwise the deploy fails with a Cannot access error.

How do I start the factory on an issue?

Label the issue with FACTORY_LABEL (default factory). You can also @mention Foreman on an issue or PR (if you're an owner, member, or collaborator), or use Linear Agent Sessions. Each trigger runs the same four-station pipeline and ends in a draft PR.

What happens if CI fails on a factory PR?

Foreman automatically diagnoses the failure and pushes a fix to its own branches only — those matching FACTORY_BRANCH_PREFIX (default factory/). It never pushes directly to your branches, so you keep control.

Do I need to set up connectors manually?

No. The Vercel deploy flow creates the GitHub connector, Linear connector, and Vercel Blob store for you. You only need to provide FACTORY_REPO and optionally FACTORY_LABEL, and ensure the GitHub App has access to the repository.