← Back to Docs
Feature Factory

Plan as a graph, build with any agent

What is the Feature Factory?

The Feature Factory turns a feature request into a task graph grounded in your actual code, dispatches the independent pieces to AI coding agents you already use, and gates the whole run behind two human approvals. VibeCop computes which tasks genuinely depend on each other from real import paths and file footprints — so agents parallelize where it is safe and serialize where it is not.

Two state machines drive everything. A run moves through a human graph review before any agent starts, and every node's progress is driven by GitHub facts — a pull request opening, merging, or closing — never by an agent's claim of success.

Feature: graph_review (G1) → running → done | cancelled Node: planned → ready → claimed → building → review → done | blocked | cancelled

How does graph-based planning work?

Each task declares an expected footprint — the files and modules it should touch. VibeCop derives an edge between two tasks when their footprints overlap or an import path in the code graph connects them; disjoint tasks run in parallel. Ambiguity always becomes a sequential edge rather than a guess, and cyclic graphs are rejected before anything is written.

Runs are deliberately bounded: at most 12 nodes per feature and 3 active runs per organization. If a graph is wrong, cancel the run and start a new one — there is no silent mid-flight re-planning.

How do I start a run?

Runs are created from your agent's cockpit over MCP — there is no dashboard create button. Drop the client kit into your repository, mint an MCP token in VibeCop Settings, then have any connected agent call the feature_start tool with a title and the task list. The run appears on the dashboard in graph review, waiting for your approval.

npx -y @maiife-ai-pub/vibecop kit --org <org> --project <project-id>

The kit writes vendor-neutral files — AGENTS.md with the canonical rules, plus ready-made MCP configs for Claude Code, Cursor, and Codex. No agent is privileged over another; the same five cockpit tools behave identically everywhere:

ToolPurpose
feature_startCreate a run: title + tasks with expected footprints and acceptance anchors.
feature_statusFull run view — every node's state, the edges, PR and issue numbers.
node_claimClaim a ready node. Returns the branch to use and a 60-minute lease.
node_reportReport the branch is pushed and the PR is open — the only self-reported status.
gate_approveApprove the graph (G1) — or cancel the run entirely.

What are the G1 and G2 gates?

G1 is graph approval: the task DAG — jobs, footprints, acceptance anchors, dependencies — is reviewed and approved on the dashboard or via gate_approve before any agent may start building. G2 is the merge itself: a human merges every node's pull request after reading its review. VibeCop never auto-merges, by design.

G1 is a review checkpoint, not a human-presence requirement. An agent operating autonomously with authority over the run reviews the graph and calls gate_approve itself rather than waiting for a person. G2 is the gate that always stays human — code reaches your default branch only because someone merged it.

Approving G1 marks the root nodes ready and mirrors the run to GitHub as one tracking issue per node with vibecop:node:* state labels. VibeCop's database stays canonical — if the mirror lags, only the labels are behind, never the truth.

What does the Feature Graph screen show?

The Features section of the dashboard lists every run with its status and live node-state counts, and each run opens into a live DAG colored by node state. Selecting a node shows its full contract — job, adapter, expected files, acceptance anchors, and links to its GitHub issue and pull request — while an activity strip surfaces whatever agents are working right now.

The screen is also where the kill switch lives: cancelling a run stops dispatch immediately, cancels every open node, and revokes outstanding claims. It asks for confirmation — it is irreversible.

How do my agents build nodes?

Any MCP-capable agent on your machine claims a ready node, builds on the branch the claim returns, opens one pull request per node, and reports the branch pushed. Claims are sixty-minute leases, not locks — an agent that goes silent loses the node back to the ready pool. Merging the PR completes the node and unlocks its dependents automatically.

Agents never merge and cannot self-report completion — a node's move to review, done, or blocked comes only from GitHub's webhook facts. Each node PR also gets a normal VibeCop review run, so the same detectors that guard your regular pull requests guard agent-written code too.

How does a run end?

A run settles automatically once every node has reached a terminal state — merged, blocked, or cancelled. Merging every node finishes the run as done; any other ending closes it out rather than leaving it open forever. Each finished run records why it ended, shown as a chip on the Features screen.

EndingWhat happened
DoneEvery node's pull request was merged.
PRS CLOSEDThe node pull requests were closed without merging, so the run settled.
BY OPERATORSomeone used the kill switch on the run.
TTLThe run sat idle past the inactivity window and was swept automatically.

Closing a node's pull request without merging blocks that node, and blocks any dependent still waiting on it — there is no point handing out work that cannot integrate. Dependents already being built are left alone. Reopen the pull request and the node returns to review, provided the run itself has not already settled.

Open the MCP installer
Related docs