DraftForge

Start Your Documentation from Review Stage

DraftForge is a self-hosted documentation agent. Give it a requirement and your product’s existing knowledge (legacy docs, source code, a style guide) and it produces a structured first draft.

Reviewers get a readiness score so they know exactly where to focus. Writers stop starting from a blank page and start from something worth editing.

The problem with documentation today

Software teams have gotten good at shipping fast. Documentation hasn’t kept up. When a new feature is ready, a writer gets handed a ticket with SME inputs. Writers spend the first hours just gathering the right information, such as what the feature does, how it behaves, what the existing product already says about related concepts, what terms the team actually uses.

Chat assistants and IDE tools can help in the moment. Ask Cursor to write a paragraph, and you’ll get readable text. But it doesn’t know your product’s established terminology, nor does it know which claims are supported by your actual codebase. When this essential context runs thin, it invents details. Moreover, every session starts afresh with no memory of past choices, compromising overall accuracy of the output.

The result is documentation that moves slowly, reads differently due to varying terminology across writers and costs multiple review cycles to get it right.

What DraftForge does differently

DraftForge builds a knowledge base from your product’s existing material, such as legacy documentation, source code, Confluence pages, style guides, glossaries and whatever else your team has written down. When a requirement comes in, it retrieves the most relevant passages per section, composes a grounded draft, and attaches citations so reviewers can check every claim. By design, DraftForge is:

• Grounded, not generated. It does not write from nothing. It writes from what you already know and it is honest when that isn’t enough, flagging gaps rather than filling them with invented prose.
• Your voice, not a generic one. Legacy documentation teaches DraftForge your product’s established patterns, what you call things, how you explain concepts, how your docs are structured. The style guide enforces preferred terms, avoided words, sentence length and voice, and those rules are checked after every draft.
• A score you can act on. Readiness is a number from 0 to 100 weighted toward grounding. A high score means the draft is well-supported and coverage is solid. A low score means gather more context or tighten the requirement before sending to review.
• AI-ready Documentation. Because DraftForge writes in clean, consistent sections with explicit terminology, the output is ready not just for human readers but for the AI tools that will increasingly consume your docs, chat assistants, AI agents and retrieval systems that depend on well-structured source material.
• Versioned and auditable. Every draft is saved. Every human edit creates a new version. There is an audit log. You know who touched what and when.

With DraftForge, the result is a review-ready draft that sounds like your product, cites its sources, and tells you exactly how ready it is before a human touch it. All of this in just minutes.

How it works

• Ingest. Upload files, pull a folder, paste text, or connect a source like Confluence. Each document is chunked, embedded, and indexed with legacy, code, requirement, style, or glossary that controls how it is weighted during retrieval.
• Generate. Choose a document type: API reference, user guide, or release notes. DraftForge plans the sections, retrieves the right context for each one using hybrid search, and writes using a local
• open-source model or your own API key. Every section gets citations. Every gap gets a flag.
• Review. The readiness score breaks down grounding, coverage, style conformance, and structure. Reviewers see exactly where the draft is strong and where it needs work. Edit in the UI, save a new version, and export when it is ready.

Nothing is final without writer’s approval.

Runs on your network

DraftForge is self-hosted documentation system: the vector index, the drafts, the audit log, and everything stays inside your environment.

By default, it uses a local model for both generation and embeddings. No data leaves your network unless you explicitly configure a cloud model with your own API key. For teams that cannot use external networks at all, the offline composer produces extractive grounded drafts without any model.

Cloud providers are an opt-in choice, not the default. An ambient API key is never used silently.

Who it is for

• Technical writing teams that ship multiple doc types per quarter and need consistency across authors.
• Platform and product teams that already have a documentation corpus and want to stop recreating it from scratch with every feature.
• Engineering-led teams without dedicated writers who need structured, accurate first drafts their engineers can hand off.
• Compliance-conscious organizations that need self-hosted AI, audit trails, and control over which models touch their content.

If you occasionally ask Cursor to explain a function and write a README, use Cursor for that. DraftForge is for teams running documentation as a process, not as an afterthought.

Cursor, ChatGPT, or DraftForge?

Cursor and chat assistants are excellent at helping one person write faster in the moment. They are not built to maintain product voice across a team, cite claims against an indexed corpus, or produce
scored, versioned outputs that move through a review process.

Whereas DraftForge is a documentation system, not a generative writing assistant. It focuses on context-aware, content creation architecture that helps documentation teams start their journey from review stage, at an organizational scale.

Many teams use both. Developers use Cursor in the IDE. Writers use DraftForge to produce the first draft that actually enters the review queue.