PromptForge is an open-source TypeScript toolkit for building production-ready AI prompts. Define prompts with type-safe schemas, validate inputs before expensive LLM calls, compose reusable prompt blocks, and compile prompts for multiple AI providers. Built for developers who want maintainable, scalable, and reliable prompt engineering workflows. MIT licensed and developer-first.
No reviews yetBe the first to leave a review for PromptForge
Maker
📌
While building AI applications, I realized prompts were becoming part of the codebase—but we were still managing them as plain strings.
We already use TypeScript for type safety, Zod for validation, and reusable components across our applications.
I wanted to bring those same engineering principles to prompt engineering.
That's how PromptForge started.
Report
honestly the type-safe approach sounds great for catching errors early. one thing that would be really useful is a built-in token counter so you can see exactly how much each compiled prompt will cost before hitting the API, would save a lot of debugging time
Report
Maker
@emrep5vj Thanks, Emre! That's a fantastic suggestion. A built-in token estimator (with cost estimation across different providers/models) is definitely something I've been thinking about. Being able to catch token overflows and estimate costs before making an API call would make the development workflow much smoother. Really appreciate the idea!
Report
the type-safe schema approach is honestly really smart, catches so many dumb mistakes before they hit the API. appreciate that you kept it MIT and didn't overcomplicate the API either.
Report
Maker
@irmak2070596 Thank you, Irmak! That was exactly the goal—to make prompt engineering safer without adding unnecessary complexity. I'm really glad you appreciated the type-safe schema approach and the decision to keep it MIT licensed. Your feedback means a lot!
Report
A built-in version control system for prompts would be a really nice addition, something like git-style diffs so you can track changes, compare prompt versions, and roll back when a tweak hurts performance. Pairing that with prompt A/B testing against real eval datasets would round out the whole workflow nicely.
Report
Maker
@sudenurouou Thanks for the thoughtful feedback, Sudenur! I love the idea of git-style versioning for prompts. Being able to diff, compare, roll back, and pair that with A/B testing against eval datasets would make prompt engineering much more reproducible and data-driven. Definitely adding this to my roadmap. Thanks for sharing!
honestly the type-safe approach sounds great for catching errors early. one thing that would be really useful is a built-in token counter so you can see exactly how much each compiled prompt will cost before hitting the API, would save a lot of debugging time
@emrep5vj Thanks, Emre! That's a fantastic suggestion. A built-in token estimator (with cost estimation across different providers/models) is definitely something I've been thinking about. Being able to catch token overflows and estimate costs before making an API call would make the development workflow much smoother. Really appreciate the idea!
the type-safe schema approach is honestly really smart, catches so many dumb mistakes before they hit the API. appreciate that you kept it MIT and didn't overcomplicate the API either.
@irmak2070596 Thank you, Irmak! That was exactly the goal—to make prompt engineering safer without adding unnecessary complexity. I'm really glad you appreciated the type-safe schema approach and the decision to keep it MIT licensed. Your feedback means a lot!
A built-in version control system for prompts would be a really nice addition, something like git-style diffs so you can track changes, compare prompt versions, and roll back when a tweak hurts performance. Pairing that with prompt A/B testing against real eval datasets would round out the whole workflow nicely.
@sudenurouou Thanks for the thoughtful feedback, Sudenur! I love the idea of git-style versioning for prompts. Being able to diff, compare, roll back, and pair that with A/B testing against eval datasets would make prompt engineering much more reproducible and data-driven. Definitely adding this to my roadmap. Thanks for sharing!