Software factory
- GitHub
- Linear
Foreman, a software factory that takes tasks from GitHub and Linear, runs each through classifier, analyst, implementer, and reviewer stations, and delivers a reviewed draft pull request on your repository.
- GitHub
- Linear
agent/agent.tstypescriptimport { defineAgent } from "eve";
import { MODELS } from "./lib/models.js";
/**
* Root agent runtime configuration.
*
* @remarks
* Sets the model and the session budget for Foreman, the software factory
* orchestrator; the rest of the agent's surface (channels, connections,
* extensions, tools, skills, subagents) is discovered from the filesystem
* under `agent/`. Conversation history is compacted once it reaches 75% of
* the context window. The per-session output token limit caps runaway
* sessions while leaving room for the pipeline: the four stations draw from
* the root session's remaining quota, and an implementation run needs far
* more than a chat reply.
*/
export default defineAgent({
compaction: { thresholdPercent: 0.75 },
limits: {
maxOutputTokensPerSession: 100_000,
},
model: MODELS.orchestrator,
});
eve Software Factory Template
Meet Foreman, an eve software factory that puts AI agents on every stage of the development loop and keeps people on the judgment calls.
Foreman takes tasks from GitHub and Linear, moves each one through four stations, and delivers a reviewed draft pull request on your repository. You review, mark ready, and merge.
How it works
- Classifier triages the task: type, priority, complexity, actionable or not. When the task isn't actionable, Foreman asks the requester instead of building the wrong thing.
- Analyst turns it into a plan with acceptance criteria, working from a live checkout of your repository.
- Implementer executes the plan in its own sandbox, verifies with your repo's own checks, and pushes a branch.
- Reviewer independently judges everything against the real diff, with evidence for each verdict.
Each station is its own agent with its own instructions, sandbox, and tools. The Reviewer sees only the pushed branch, never the Implementer's reasoning. Between runs, Foreman keeps a factory brain: notes about your repository that every run starts from. See the pipeline and factory memory for the full picture.
How work arrives
- Label an issue
factory. The pipeline runs on its own, posts progress as stations complete, and ends with a draft PR linked to the issue. - @mention it on an issue or PR. Mentions from repo owners, members, and collaborators start an interactive session.
- Delegate in Linear. Linear Agent Sessions run the same pipeline and report progress back in Linear.
- The dev TUI. Hand it a task locally. Changes to GitHub wait for your approval.
- Red CI on a factory PR. Foreman diagnoses the failure and pushes a fix to its own branches, never yours.
- Someone opens a pull request. Foreman posts one orienting comment for reviewers: a summary, not a review.
Deploy
The Vercel deploy flow sets up everything: the GitHub connector, Linear connector, Vercel Blob store, and a prompt for the FACTORY_REPO and FACTORY_LABEL environment variables.
Configuration (see .env.example):
Local development
Link the project you deployed (or a fresh one), pull its environment, and start the TUI:
Hand the agent a task ("users report the password reset email arrives twice, fix it") and watch the four stations fire in order, ending in a draft PR on FACTORY_REPO. Local runs are treated as untrusted, so changes to GitHub wait for your approval in the TUI.