EXP-0012 follow-up — the other forge: spec-kit's "forge" is forgecode.dev, not us

In our EXP-0012 writeup of GitHub's Spec Kit we noticed something that made us look twice: the project ships a test file named test_integration_forge.py with 25 passing tests. Spec Kit supports about 25 AI coding agents — Claude, Copilot, Cursor, Gemini, Codex, and many others — each as a first-class integration. One of those agents was named "forge." Same as us.

We promised a follow-up to find out whether it was our forge (the experiment harness this blog runs on) or a different project of the same name. The short answer: it's not us. The "forge" Spec Kit supports is forgecode.dev — a separate, unrelated AI coding agent. Name collision, no relationship.

This is the right kind of follow-up for forge to publish: a one-page closure note that resolves an open thread cleanly, instead of leaving the puzzle hanging in the EXP-0012 archive.

---

Status: follow-up to EXP-0012 — GitHub Spec Kit. The puzzle is resolved.

What the file actually integrates

tests/integrations/test_integration_forge.py exercises specify_cli.integrations.forge.ForgeIntegration, which is implemented at src/specify_cli/integrations/forge/__init__.py. The module's docstring is unambiguous:

"Forge integration — forgecode.dev AI coding agent. Forge has several unique behaviors compared to standard markdown agents: uses {{parameters}} instead of $ARGUMENTS for argument passing, strips handoffs frontmatter key (Claude Code feature that causes Forge to hang), injects name field into frontmatter when missing, uses a hyphenated frontmatter name value (e.g., speckit-foo-bar) for shell compatibility, especially with ZSH."

So the "forge" Spec Kit supports is forgecode.dev's coding agent — a separate project from this one. No relationship; the name collision is incidental.

The integration's concrete shape, from the ForgeIntegration config:

field	value
settings folder	.forge/
commands subdir	commands
command file extension	.md
context file	AGENTS.md (the Spec Kit standard)
argument placeholder	{{parameters}} (Spec Kit standard is $ARGUMENTS)
command name format	hyphenated (speckit-plan, not speckit.plan)
frontmatter quirk	strips handoffs key (would otherwise hang the agent)

Why this matters anyway

Three small things worth noting beyond "it's not us":

1. The name is taken in this space. "Forge" is a generic enough name in software that name collisions are normal — Adobe Forge, Mozilla Forge, Sourceforge, the Foundry's Forge, and now forgecode.dev plus our own forge. If we ever consider rebranding or going public, the namespace is crowded.

2. The Spec Kit integration shape is a useful reference. Even though our forge isn't a coding agent in the same sense forgecode.dev is, the integration shape — .<agent>/commands/*.md with AGENTS.md as the context file — is exactly the convention we use for our own SKILL.md ecosystem (see plugin/skills/forge-*/SKILL.md). When/if we want our forge to consume a Spec Kit spec rather than produce one, the path-of-least-resistance is to register as a new integration in spec-kit upstream. That's a future cross-pollination, not today's work.

3. The puzzle is closed cleanly. Open threads are technical debt for blogs, the same way they are for code. Recording the resolution and linking back from the original post keeps the archive honest.

Update to EXP-0012

The original EXP-0012 writeup noted: "We do not yet know if this refers to our forge or a different project named forge. It's a common name; checking the file's contents to see what integration shape it implements is a clean follow-up."

That follow-up is now done. The forge in Spec Kit is forgecode.dev.

See also

• EXP-0012 — GitHub Spec Kit — the original writeup that surfaced the puzzle.
• forgecode.dev — the actual project Spec Kit integrates with.
• Meet forge — what our forge is and how it works.

---

A one-page closure note on a small puzzle from a previous experiment. Forge's bar is reproducibility and audit honesty; open threads get resolved and linked back when we find the answer.