Forge vs Cursor rules
Short answer. These are not competing products. Cursor rules are .mdc files that inject standing context into one editor's agent. Forge is a binary that runs a spec-driven workflow across 24 agents and fails the run when a gate opens. Most teams that use Cursor should keep their rules and add Forge, not choose.
What each one actually is
Cursor rules live in .cursor/rules/ as .mdc files — markdown with a small frontmatter block that controls when each rule applies: always, on a glob match, or on request. They are a context mechanism. They tell Cursor's agent "this codebase uses X, never do Y", and they are excellent at that job.
Maistik Forge is a single static Go binary that configures the agents you already run — Cursor among them — to follow one spec-driven workflow, and enforces the controls narration cannot be trusted with.
Feature comparison
| Cursor rules | Maistik Forge | |
|---|---|---|
| Scope | The Cursor editor | 24 agents plus a generic adapter |
| What it is | Context injected into a prompt | Workflow renderer plus a runtime |
| Artifact | .cursor/rules/*.mdc | .forge/ — specs, changes, timeline, config |
| Workflow | None. Rules do not have phases | Nine-phase spine |
| Can fail a run | No | Yes — four enforced controls |
| Spend ceiling | — | Spend budget |
| Audit record | — | Append-only attributed timeline |
| Team sharing | Committed to the repo | Committed to the repo |
| Cost | Included with Cursor | Paid annual licence |
Why do people compare them at all?
Because both answer the same first question — how do I stop the agent doing the wrong thing? — and rules are the answer everybody reaches for first. They are right there, they are free, and they work.
Where rules run out is not quality, it is category. A rule is a sentence in a prompt. It can say "always run the test suite before claiming a task is done." It cannot check whether the suite ran. When the agent reports success on a suite it skipped, the rule was followed as far as any prompt can be followed, and the claim is still false.
That gap is the entire reason Forge ships a runtime. Its Sensors do not ask the model anything. forge verify runs the project's real test and lint command and returns an exit code. forge secscan walks the files. The spend budget reads persisted counters. None of it is narratable, because none of it is a sentence.
Do they conflict if I use both?
No, and the combination is the one we would actually recommend for a Cursor team. They write to different places and do different jobs:
- Rules carry standing house style — conventions, forbidden patterns, the things that are true of every task in this repo.
- Forge carries the workflow and the bounds — what phase this change is in, what the spec says, whether verification passed, what it has cost so far.
Forge's Cursor adapter renders its command surface into the format Cursor expects, so the slash commands appear alongside your existing rules rather than replacing them. If you prefer, Forge also speaks MCP, letting the agent query the harness directly for what it is currently allowed to do.
What if I use more than one agent?
Then rules stop being portable, and that is usually the moment Forge starts paying for itself. .cursor/rules mean nothing to Claude Code, Codex or Gemini CLI — each has its own instruction format, and keeping four hand-written copies in sync is how they silently drift apart.
Forge renders one workflow into 24 dedicated adapters plus a generic one, from a single source under .forge/. Change the workflow once and every agent gets the update in the format it actually expects.
Questions people actually ask
Does Forge replace my .cursor/rules files?
No. Forge does not read, rewrite or delete them. It renders its own command surface into the location Cursor expects for agent instructions, and your rules keep doing what they already do. Standing house style and workflow enforcement are different jobs, and most teams want both.
Does Forge work inside the Cursor editor?
Yes. Cursor is one of the 24 agents Forge ships a dedicated adapter for, so the Forge slash commands appear in Cursor and drive the same workflow they drive anywhere else. The forge binary itself is a terminal program, so gates can also run from hooks or CI.
Can Cursor rules stop an agent deleting a directory?
Not reliably. A rule is instruction text the model may follow, and a model under pressure can narrate around instruction text. Forge's guardrails gate is the control designed for this failure class — the one enforced control that stands in front of an action rather than grading it afterwards.
Is Forge worth it if Cursor is my only agent?
It depends on what a bad run costs you. If you want better context and nothing more, rules are free and sufficient. If a run can spend real money, touch a hot path, or has to be defensible to somebody who was not watching, the enforcement layer is what you are buying.
Where does my code go?
Nowhere new. Forge has no model of its own and never enters the inference loop, so whatever Cursor already sends to its provider continues under that provider's terms, unchanged. Forge itself sends anonymous usage and error telemetry (command name, version, OS/arch, a random install ID — never your code or your AI conversations), and FORGE_NO_TELEMETRY=1 turns it off. See Telemetry.
Next steps
- Supported agents — the full adapter list, Cursor included.
- The enforcement doctrine — what enforces versus what advises.
- Harness as MCP — let the agent ask the harness directly.
- Forge vs GitHub Spec Kit — the closest real comparison.
- Pricing — what a licence costs and what it covers.