# 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](/getting-started) and the [Introduction](/guide/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.

::: info 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](/harness/overview).
:::

```mermaid
flowchart TD
    M["Spec-driven workflow"] --> H["Enforced harness"]
    M --> G["Governance & review"]
    M --> K["Memory & knowledge"]
    M --> V["Visibility & collaboration"]
    M --> A["Adoption & migration"]
    H --> H1["guardrails · breaker · budget · timeline"]
    G --> G1["trigger-rules · adversarial review"]
    K --> K1["Engram · knowledge graph · skills"]
    V --> V1["dashboard · attribution"]
    A --> A1["import Spec-Kit / OpenSpec"]
```

## 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](/concepts/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](/guide/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](/features/quality)

**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](/concepts/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.

::: warning 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](/harness/overview)
:::

**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](/harness/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](/harness/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](/harness/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](/harness/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](/harness/live-agent-hooks)

## 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](/features/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](/features/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](/concepts/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](/features/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](/features/skills)

## 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](/features/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](/features/docsite)

**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](/features/vscode-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](/features/team)

## 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](/features/migration)

## Next steps

- [Command reference](/guide/commands) — every feature as a CLI and `/forge.*` slash command.
- [Components](/guide/components) — the building blocks the engine assembles.
- [The workflow](/guide/workflow) — the spine, foundation phases, and adaptive depth in practice.
- [Enforcement doctrine](/harness/overview) — where the methodology stops advising and starts enforcing.