TL,DR: I made a TUI application to help you improve your prompts https://github.com/pr0z4k/promptsmith-cli.

"2001: A Space Odyssey" doesn't begin with spaceships.

It all begins with a tool.

The famous opening sequence isn't about technology. It's about the moment humanity discovers that an ordinary object can fundamentally change how problems are solved. A bone becomes a tool. Everything after that follows naturally. Fast forward a few million years and we're standing in front of another tool. Large Language Models, GenAI, copilots, assistants... you name it.

Some people are excited. Some people are terrified. Some are still arguing on the internet that "real engineers don't use AI," as if refusing to learn a new tool has ever worked particularly well throughout history, ask the french folk and the mechanical loom weavers period.

Personally, I think we're asking the wrong question.

The question isn't whether AI will replace engineers. The question is whether engineers will learn to use AI well.

Prompt engineering is simply becoming another engineering skill.

Just like version control. Just like virtualization. Just like containers. Just like cloud computing.

You don't have to love it. But pretending it isn't happening feels remarkably similar to insisting Git was a fad, and we know how that story ends :).

Motivation

After using ChatGPT, Claude, Gemini, Copilot, Mistral, and a growing collection of local language models, majority of the times it was the same pattern

When an AI produced a poor answer, the model usually wasn't the problem. The prompt was.

We humans are wonderfully inconsistent communicators. We forget context. We skip assumptions. We mix requirements with examples. We change objectives halfway through a sentence.

Then we blame the model for misunderstanding us.

PromptSmith exists because improving the prompt is often significantly cheaper than repeatedly asking an expensive LLM to guess what we actually meant.

What PromptSmith does

PromptSmith is not another AI assistant.

It doesn't replace/compete ChatGPT, Claude, Gemini, Mistral, Z.ai, etc. It doesn't manage prompt libraries. It doesn't require cloud accounts.

Its entire purpose is surprisingly small.

Before your prompt reaches an LLM, PromptSmith asks one simple question:

Can this prompt be better?

Specifically it can:

• Analyze prompt quality and score it from 0 to 100
• Detect ambiguous wording
• Identify missing context
• Highlight weak instructions
• Suggest deterministic improvements
• Optionally refine the prompt using a local Small Language Model (SLM)
• Allow teams/friends to build, customize and share prompt templates

What it intentionally does not do:

• Replace your favorite AI, if any
• Store prompts in the cloud
• Force a single prompting methodology
• Pretend there is one "correct" way to communicate with AI

Why another CLI?

Because that's already where many of us spend our day, and let's face it... CLI is retrocool.

PromptSmith is envisioned to disappear into an existing engineering workflow.

Write a prompt. Run PromptSmith. Review the suggestions. Copy the recommended version into ChatGPT, Claude, Gemini, Copilot, Mistral, or whichever model marketing departments renamed this week.

No browser extensions.

No dashboards.

No subscriptions.

Just another tool in the toolbox.

Architecture

One of the biggest misconceptions about PromptSmith is that it simply asks another AI to improve your prompt.

That would be rather wasteful.

Instead, every prompt follows a very tiny pipeline designed to improve quality while (trying to) minimizing unnecessary token consumption... tokens are expensive these days.

User Prompt
      │
      ▼
Deterministic Analysis
      │
      ▼
Prompt Score (0-100)
      │
      ▼
Rules Engine
      │
      ▼
(Optional - but highly enforced)
Local Small Language Model
      │
      ▼
Improved Prompt
      │
      ▼
Your Preferred AI

The deterministic analysis happens first because deterministic software is fast, predictable, and free.

Only after the obvious improvements have been identified does an optional local Small Language Model join the process.

The SLM isn't replacing the rules.

It's augmenting them.

Local first

One design decision never changed throughout this journey.

Your prompts belong to you.

PromptSmith runs locally.

It supports GGUF models through llama.cpp, with Microsoft's Phi-4 Instruct serving as the recommended default. You're free to use any compatible model that fits your hardware and workflow.

No telemetry. No cloud dependency. No subscriptions. No mystery API requests.

Your prompt only leaves your machine when you decide to send it to an external LLM.

For people handling proprietary information, that isn't just convenient. It's often a requirement.

Not prescriptive by design

This may be my favorite feature, even though it isn't really a feature at all.

PromptSmith doesn't claim to know what a perfect prompt looks like.

The built-in scoring rules are simply a starting point.

Don't like them? Change them.

Need additional checks? Add them.

Does your team have its own prompt standards? Turn them into templates.

PromptSmith isn't built around the idea that one engineer discovered the "correct" prompting methodology.

Quite the opposite.

Every team communicates differently.

Infrastructure engineers write differently from software developers. Security analysts ask different questions than technical writers. Architects think differently from project managers.

PromptSmith embraces that diversity instead of fighting it.

The templates are intentionally editable.

Create your own. Improve existing ones.

Share them with your team. And if possible, share them back to the project.

Version them alongside your code.

Knowledge shouldn't remain trapped inside one engineer's notebook.

Teaching, not replacing

PromptSmith goal isn't to depend on it forever.

Quite the opposite.

After enough iterations, you naturally begin writing better prompts.

You provide more context. You define clearer constraints. You explain success criteria. You stop assuming the model can read your mind.

PromptSmith quietly becomes less necessary because you've learned something.

That feels like success. Vanishing to the background and gallivanting to the sunset.

Open source because tools should stay tools

PromptSmith is released under the MIT License.

No feature gates. No "Pro" subscription. No credits. No monthly reminders that your payment failed because your credit card expired while you were trying to debug production.

Just an open source CLI built because I wanted one, couldn't find one, and apparently writing another terminal application seemed like the reasonable response.

Lessons learned

Building PromptSmith taught me a few things.

First, prompt quality often matters more than model size.

Second, deterministic rules catch an impressive amount of low-hanging fruit without spending a single token.

Third, local Small Language Models work remarkably well when they're augmenting deterministic analysis instead of replacing it.

Finally, prompt engineering shouldn't become tribal knowledge.

It should be documented.

Version controlled. Reviewed. Shared.

Just like good code.

Conclusion

Every technological shift creates two predictable camps.

One insists everything is changing. The other insists nothing is changing.

Reality usually settles somewhere in between.

LLMs are not replacing engineers.

They're becoming another tool that good engineers learn to use effectively.

PromptSmith isn't trying to build the future of AI.

It's trying to help you ask better questions today.

Sometimes that's enough.

Code

Repository:

https://github.com/pr0z4k/promptsmith-cli

Contributions, bug reports, feature requests, and new prompt templates are always welcome.

The internet already contains enough people arguing about AI. I'd rather build tools that help people use it better.