Skip to content
Viberia Docs

CodeForge

CodeForge is the engineering building: a Planner who writes the PRD, a Developer who implements it, and a Reviewer who closes the loop with a code review.

At a glance

Section titled “At a glance”
  • Default agents: Planner, Developer, Reviewer
  • Best for: Any change to a codebase that benefits from a written spec, a focused implementer, and a second pair of eyes
  • Skills it ships with: /draft-a-prd, /handoff-prd-to-developer, /implement-the-prd, /send-to-review, /run-code-review, /commit
  • Place from: Building Type Drawer → CodeForge

How It Works

Section titled “How It Works”

CodeForge bakes the PRD-handoff workflow into a single building. Instead of stitching together a planning tool, an IDE, and a code reviewer yourself, you place CodeForge in a project’s territory and you get three agents who already know how to hand work to each other.

The basic loop is: you describe what you want to the Planner, the Planner produces a written PRD (PRD.md) you can edit, the Planner hands the PRD to the Developer, the Developer implements it against the project’s folder_path, the Developer hands the changes to the Reviewer, and the Reviewer either signs off or returns a review with concrete asks. When the Reviewer signs off, the Developer commits.

Each handoff is a real message between agents, queued in the receiver’s inbox. You can watch the chain happen from the Activity Bar, intervene at any stage by talking directly to whichever agent is currently working, or restart a step by sending a fresh message.

CodeForge does not replace your editor or your version control. It writes files, runs commands, and produces commits inside the project’s folder_path exactly as if you were doing it yourself. You can keep working in your IDE side by side; the agents and you share the same working tree.

Default agents

Section titled “Default agents”

  • Planner. The Planner turns intent into a written specification. Talk to the Planner when a change is too big to describe in a single chat message, when you want a paper trail before code gets written, or when you’d like to see the plan reviewed before implementation starts. The Planner ships with /draft-a-prd for producing the document and /handoff-prd-to-developer for passing it to the Developer.

  • Developer. The Developer implements PRDs. Talk to the Developer when you already have a PRD (or a precise, well-scoped change you don’t need a PRD for), when you want to drive implementation step by step, or when you need to test, debug, or extend code that’s already in the project. The Developer ships with /implement-the-prd, /send-to-review, and /commit.

  • Reviewer. The Reviewer is the quality gate. Talk to the Reviewer when you want a second pair of eyes on a change, when the Developer has just finished a round and you want a structured review before merging, or when you want to spot-check a section of the codebase. The Reviewer ships with /run-code-review.

Configuration

Section titled “Configuration”

CodeForge follows the standard building configuration model. From the Building Window you can:

  • Override the prompt of any of the three agents (for example, give the Reviewer a stricter style guide).
  • Change each agent’s model. A common pattern is Planner on a strong reasoning model, Developer on a fast coder model, Reviewer on a careful reasoner.
  • Add per-agent skills and MCP servers. For example, install the filesystem MCP on the Developer to scope its file access to a specific subfolder.
  • Add additional directories if any of the agents need read or write access beyond the project’s folder_path.

The six skills listed under At a glance are installed by default. You can disable any of them per agent if you want to constrain the workflow.

Typical workflow

Section titled “Typical workflow”
  1. Place CodeForge in your project’s territory.
  2. Open the building and click the Planner.
  3. Describe the change in plain language. The Planner reads the relevant code, asks clarifying questions, and writes PRD.md.
  4. Review the PRD in the Markdown Editor (use the Toolbox if you want it side by side). Edit it in place if you want to tighten scope or add constraints.
  5. Tell the Planner to hand off to the Developer (/handoff-prd-to-developer). The Developer receives the PRD as a queued message and starts implementing.
  6. When the Developer reports done, send the work to the Reviewer (/send-to-review from the Developer, or talk to the Reviewer directly). The Reviewer reads the diff and either approves or returns asks.
  7. On approval, the Developer commits (/commit) and you have a clean, reviewed change in your working tree.

You don’t have to use the full chain every time. If the change is small enough you can skip the Planner and talk to the Developer directly. If you trust the Developer’s output you can skip the Reviewer. The handoff skills are sugar over plain messaging, not requirements.

Limitations

Section titled “Limitations”
  • CodeForge writes to the project’s folder_path. If the project has no folder linked, the Developer has nowhere to put code — link a folder in HQ first.
  • The three agents work in your real working tree, not a copy. If you want parallel-track changes that don’t collide, pair CodeForge with WorktreeForge — the Developer can implement inside a worktree instead.
  • The Reviewer can flag issues and request changes, but it cannot block a commit. The user is always in the loop. If the Developer commits over the Reviewer’s objections, that’s a user decision.
  • The Planner does not run code. PRDs are written from reading source, not from executing tests.
  • All three agents share the same project context but have separate conversations. The Developer doesn’t automatically know what you told the Planner unless it’s in PRD.md or you forwarded it explicitly.
Section titled “Related”