Features

This page is a dense, link-heavy catalog for people who already know Forge's basics and want to jump straight to a specific feature. If that's not you yet, Getting Started and the Introduction are the friendlier on-ramps — come back here once the vocabulary feels familiar.

Forge is a single Go binary that configures the AI coding agents you already run to follow one spec-driven workflow — and enforces the handful of controls that narration cannot be trusted with. Most of what Forge does is configuration: it renders injected instruction text the agent's model executes. A small, named set of controls does more than advise — it checks deterministic evidence and returns a non-zero exit. That split is the through-line of everything below.

The one distinction to hold in your head

Forge features come in two shapes. Guides are feedforward — they steer a run before it happens, and they can be narrated around. Sensors are feedback — they read persisted counters or live Git evidence after the fact and refuse to bless a run that went wrong. Governance, memory, and the methodology are Guides. The four enforced controls and the timeline are Sensors. See the enforcement doctrine.

Spec-driven workflow

The spine is the product. Every feature hangs off one ordered sequence of phases, and how much of it a change walks is decided, not guessed.

Spec-driven development inverts the usual relationship: code serves specifications, not the other way around. The spec is the artifact you maintain — intent, contract, and implementation kept in separate, separable layers — and code is its expression in one language and framework. That separability is what makes a pivot a systematic regeneration instead of a manual rewrite. → Methodology

The SDD spine plus adaptive depth threads those layers through one canonical order — explore → propose → specify → clarify → plan → tasks → implement → verify → archive. Every change is a subset of this spine, never a different one: a typo fast-forwards to implement → verify, a bounded feature runs the Standard path, and a hot-path or 400-line change runs the full spine. The ordering never changes — only how much of it a given change traverses. → The workflow

Quality gates score your artifacts before you build against them. forge analyze reads the whole spec surface — spec, design, tasks, constitution, and the foundation baselines — runs seven detection passes, and returns a reproducible 100-point score across completeness, consistency, testability, and clarity. It is read-only: it prints findings and proposes remediation, but never edits an artifact on its own, and a constitution conflict is always CRITICAL and caps the score. → Quality gates

Drift and reconcile keep .forge/specs/ honest against the code. forge drift classifies every divergence deterministically into Ghost (code with no spec), Phantom (spec with no code), or Mutated (both disagree); the /forge.reconcile agent skill resolves conflicts one at a time through severity-ordered passes and runs automatically after any spec-modifying command. A constitution violation is the one conflict that cannot be deferred. → Drift and reconcile

The enforced harness

This is where Forge stops advising. Four controls check evidence the tool can verify on its own and refuse to bless a run that has gone off the rails — each returns a non-zero exit regardless of what the agent says it did.

What "enforced" means here

A control earns enforcement only when the failure mode is runaway, irreversible, or unbounded and it is deterministically checkable from persisted per-change state or live Git — with no model judgment inside the gate. Everything else stays advisory on purpose. → Enforcement doctrine

The guardrails gate bounds dangerous actions — the irreversible command, the leaked secret. It layers a secrets deny-list and a destructive-action PreToolUse hook (forge guardrails-gate, which exits 2 to block rm -rf /, sudo rm, git reset --hard, git rebase, and hard force-push) in front of an action, and forge secscan after files land — a static scan for secrets, PII, and prompt-injection that returns non-zero while any unwaived finding remains. Only a human waives, never the agent. → Guardrails

The verify circuit-breaker bounds iterations. forge verify --change <c> tracks consecutive verify failures for a change; at the threshold (default 3) it prints CIRCUIT OPEN and returns non-zero, converting a "retry forever" loop into a bounded one that ends in a human decision. A passing verify resets the streak, and the state is persisted to disk so it survives context compaction. → Circuit-breaker

The spend budget bounds cost. forge budget record adds reported spend to a per-change ledger and returns non-zero with BUDGET EXCEEDED when a configured ceiling on tokens, dollars, or tool calls is strictly crossed. Forge is not inside the inference loop, so whoever holds the numbers reports them; Forge owns the ceiling. → Spend budget

The session timeline is the Sensor side made durable — a single append-only, attributed record of everything that happened to a change. The breaker and the budget emit into it automatically, so verify verdicts, breaker transitions, and every spend record land on one auditable timeline stamped with the git identity that ran them. → Session timeline

Connecting a live agent is the last mile: the gates only work when something feeds them. Because the per-change commands auto-resolve the single active change when --change is omitted, a host hook can call forge trace record or forge budget record blind — feed the timeline and tool-call budget everywhere, then turn on token/dollar enforcement once your host can report the numbers. → Connect a live agent

Governance and review

Depth is decided before a change runs; delivery is bounded after. One side is advisory triage, the other is an enforced gate — and knowing which is which is the whole point.

Change governance is Forge's deterministic triage contract: injected text the orchestrator reads and applies to every change, classifying it into Trivial, Standard, or Substantial (first match wins) to decide how much of the spine runs and how heavy review must be. It fires no steps and blocks nothing on its own — the discipline comes from consistent application, and it is refreshed into every adapter's context file idempotently with forge sync. → Change governance

Adversarial review is the enforced delivery gate governance routes into. Lens selection is risk-tiered (0 lenses low, 1 focus lens standard, the full 4R set high); severe findings pass through a read-only refuter batch — or two independent blind judges under Judgment Day — and only introduced, behavior-activated, or worsened findings with concrete evidence may block. A finished review produces a content-bound receipt, and forge review validate --gate <gate> re-derives live Git evidence and returns non-zero until that same receipt validates. → Adversarial review

Memory and knowledge

A spec-driven workflow only pays off if intent survives the next context compaction. Forge makes context accumulate instead of evaporate — and none of it gates a change, it only makes the model better informed.

Persistent memory is backed by Engram, a spec-memory store Forge wires into your agents and exposes through forge memory and forge recall. It stores distilled observations — decisions, bug fixes, conventions — grouped into sessions, and the SDD phases save what they learn and recall what's relevant as a side effect of doing the work. Because the store lives under .engram/ in your tree, sharing it with the team is just committing files to Git. → Persistent memory

The knowledge graph turns the web of relationships across your specs and code into a persistent, queryable structure. Forge doesn't build graphs itself — codebase memory is delegated to a provider (graphify or graphiti, set under memory.codebase) that extracts nodes and edges, detects communities, and writes a git-ignored HTML explorer, a GraphRAG JSON export, and a report. forge recall then queries the graph so an agent reasons over structure instead of re-deriving it every session — and verify can treat the code graph as supporting evidence. → Knowledge graph

The skills registry treats skills — reusable capability files subagents load by path — as first-class project assets. The design is index-first: forge skill-registry refresh catalogs what's installed into .forge/skill-registry.md (name, description, exact path — never the content), the delegator passes exact SKILL.md paths so an author's intent survives the delegation intact, and forge skill-discover suggests what else might help without ever auto-installing. → Skills registry

Visibility and collaboration

Because .forge/ is git-committed, Forge is a team tool by default — and everything it tracks is renderable and attributed.

The spec-viewer dashboard turns everything under .forge/ into a browsable, self-contained HTML site — spec inventory, the 100-point score, per-change cards with the task rollup, spend budget, breaker state, and the attributed timeline. It is generated in pure Go with no Node, no network, and no external assets; forge docs serve previews locally and forge docs build --publish emits a Pages-ready site. The same state renders read-only inside the interactive TUI, so browser and terminal never disagree. → Spec-viewer dashboard

The documentation site generator hosts two families under one noun: forge docsite install/dev/build scaffold and run a live generator toolchain inside .forge/ itself, so you can browse specs, changes, and decisions as a real site while you work; forge docsite publish is the client-facing counterpart, building a real VitePress (or Docusaurus, Starlight, Mintlify, MkDocs) site straight from .forge/specs/ and .forge/changes/ — capabilities, active work, and release history — with the operational fields the dashboard shows (spend, breaker, session events) deliberately left off. No agent and no hand-written staging tree required. → Documentation site generator

The VS Code Agent Plugin packages forge's skills, subagent templates, MCP server, and hooks into one self-contained bundle following the Agent Plugins schema — forge plugin build writes it for VS Code's "Chat: Install Plugin From Source", forge plugin install writes it straight to VS Code Copilot's auto-discovery location and registers it in settings.json. It exists because VS Code Copilot's subagent delivery deliberately does not go through the generic per-agent live-injection path every other adapter uses. → VS Code Agent Plugin

Team collaboration rides on the committed .forge/ directory: teammates share specs, changes, config, and memory by pushing and pulling, with config.yaml shared and config.local.yaml gitignored per-machine. Every timeline event is stamped with the git identity that ran it — resolved through FORGE_ACTOR, then git config, then USER — so a verify verdict, a breaker trip, or a spend record always belongs to someone, and each change shows a deduplicated contributor rollup. → Team collaboration

Adoption and migration

Coming from another spec tool is a supported path, not a rewrite.

The migration importer brings an existing Spec-Kit or OpenSpec project into the unified .forge/ layout non-destructively — the source is never modified, .forge/ is snapshotted before any write, and existing target files are skipped unless you pass --force. forge import specify maps a Spec-Kit tree (branding/ → design/) and forge import openspec is a near 1:1 rename; both strip regenerable site/ and scripts/ noise by default, and --dry-run prints the full plan while writing zero bytes. → Migration importer

Next steps

• Command reference — every feature as a CLI and /forge.* slash command.
• Components — the building blocks the engine assembles.
• The workflow — the spine, foundation phases, and adaptive depth in practice.
• Enforcement doctrine — where the methodology stops advising and starts enforcing.