Glossary
A quick reference for the terms you'll see throughout SpecForge — written for humans, not just developers.
Spec
A spec (short for specification) is a short plan for a feature or change you want to build. Think of it like a contract between you and your AI: it describes what to build, how it should work, and what done looks like.
Example: A spec for "Google login" would list: set up OAuth credentials, add a login button, store the user session, redirect after login. Your AI reads this and follows it step by step.
Done Checklist
Every spec has a done checklist — a list of things that must be true before the feature is considered finished. It removes ambiguity: instead of "kind of working", you know exactly which boxes are checked and which aren't.
Drift
Drift happens when the code you built no longer matches the spec you agreed on. This is normal — requirements change, shortcuts get taken, ideas evolve. SpecForge detects drift and tells you exactly what diverged from the original plan.
Why it matters: Without drift detection, you might think a feature is done when critical parts are missing or changed.
MCP Server
An MCP server is a plugin that extends your AI tool (like Claude, Cursor, or Windsurf) with new capabilities. SpecForge runs as an MCP server locally on your machine — your AI can call its tools to create specs, validate code, detect drift, and more.
Analogy: Think of it like a browser extension, but for your AI coding assistant.
SDD (Spec Driven Development)
SDD is a development approach where every feature starts with a clear spec before any code is written. The spec becomes the single source of truth — your AI follows it, and you validate against it when done.
Contrast with: Ad-hoc development, where you describe what you want in chat and hope the AI figures it out correctly.
Project
In SpecForge, a project is a folder on your computer that you've initialized with SpecForge. Each project gets a unique ID and stores all its specs, decisions, and metrics locally — no cloud required.
Stream
SpecForge organizes its 59 tools into 8 streams (A through H). Each stream groups tools that do similar things: planning, analysis, design, delivery, etc. You don't need to know all 59 — just the stream relevant to what you're doing.
Validation
Validation is when SpecForge reads your code and checks it against a spec's done checklist. It tells you which items are complete, which are missing, and what changed from the original plan.
When to use it: After you (or your AI) think a feature is done.
Acceptance Criteria
Acceptance criteria are the specific conditions that must be true for a spec to be considered done. They're the items on the done checklist. Each criterion is concrete and testable — not "login should work" but "user is redirected to /dashboard after successful login."
Init / Initialize
Initializing a project means pointing SpecForge at your project folder so it can scan your codebase, detect your language and framework, and set up local storage for your specs. It takes a few seconds and only needs to be done once per project.
Pattern
A pattern is a recurring solution that SpecForge has learned from your project. Over time, SpecForge can recognize common approaches in your codebase and suggest them when creating new specs — so your AI builds consistently.
Tech Debt
Tech debt refers to work that was deferred or shortcuts that were taken during development. In SpecForge, tech debt items are tracked separately in a spec's progress file — they don't block a spec from being "done", but they're recorded so nothing gets forgotten.
Have a term you'd like added? Leave a comment below or reach us on npm.