Hello, I'm Shrijith Venkatramana. I'm building git-lrc, an AI code reviewer that runs on every commit. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.
We have excellent tooling for source code.
Git tracks it. Package managers organize it. Compilers validate it. Test frameworks catch regressions. CI tells us when a change breaks something.
Then we build an AI application and put the most important part of the system in a 400-line Python string.
prompt = """
You are a senior software engineer...
IMPORTANT:
- Be precise
- Don't hallucinate
- Review security issues
...
"""
Soon there are 30 such prompts.
Some are duplicated. Some have slightly different versions of the same instruction. Nobody knows which one is canonical. Changing one prompt requires hunting through the codebase. And testing whether the new version is actually better becomes a manual exercise.
This is why prompt management is becoming its own category of developer tooling.
There are already several projects attacking different parts of this problem. Some focus on organizing prompts as files, some on composition, some on testing and evaluation, and some on integrating prompts directly into GitHub workflows.
Here are five worth knowing about.
1. Prompty — Put Prompts in Proper Files
The simplest problem to solve is also the most common:
Stop burying prompts inside application code.
Prompty from Microsoft provides a structured .prompty format for representing prompts as standalone artifacts.
Instead of:
prompt = """
You are an expert code reviewer.
...
"""
you can have something like:
prompts/
└── code-review.prompty
with Markdown containing the human-readable prompt and YAML frontmatter describing metadata and inputs.
For example:
---
name: code-review
description: Review a code diff
inputs:
diff:
type: string
model:
configuration:
type: openai
model: gpt-4o
---
You are an expert software engineer.
Review the following diff for:
- correctness
- security
- maintainability
<diff>
{{diff}}
</diff>
The immediate benefit is surprisingly large.
The prompt becomes:
- independently versionable
- readable in Git
- reusable
- configurable
- separable from application code
You can now review a prompt change as a normal Git diff.
When Prompty makes sense
Prompty is particularly attractive if your main problem is:
"We have prompts scattered throughout our application and need a standard format for managing them."
It is a good first step toward treating prompts as software artifacts.
2. PromptKit — Compose Prompts From Components
Once you have 50 prompts in a repository, another problem appears.
Suppose every prompt contains:
You are an experienced software engineer.
Be precise.
Do not invent facts.
Only make claims supported by the supplied code.
You don't want to copy that into 50 files.
You want reusable components.
PromptKit explores this model.
Instead of thinking of a prompt as one giant document:
Prompt
you can think of it as an assembly of components:
┌── Persona
│
Task ───────────────┼── Protocol
│
├── Format
│
└── Taxonomy
For example:
components/
├── personas/
│ └── senior-engineer
├── protocols/
│ ├── don't-hallucinate
│ └── security-review
└── formats/
└── code-review
tasks/
└── review-security
The security-review prompt can then be composed from those pieces.
Conceptually:
name: review-security
persona: senior-engineer
protocols:
- don't-hallucinate
- security-review
format: code-review
The library resolves those dependencies into the final prompt sent to the model.
This is where prompt management starts becoming interesting.
You're no longer merely storing prompts.
You're building prompts from reusable source components.
When PromptKit makes sense
PromptKit is interesting if your problem is:
"We have a growing prompt library and don't want to copy the same instructions everywhere."
It also introduces ideas such as dependencies, contracts and structured composition that become important as prompt repositories grow.
3. Promptfoo — Test Your Prompts Like Code
There is a fundamental problem with prompts that doesn't exist to the same degree with ordinary deterministic code:
A successful execution tells you almost nothing about whether the prompt is good.
This prompt:
Review this code for security vulnerabilities.
will execute successfully.
So will:
Review this code for security vulnerabilities.
Only report vulnerabilities that have a concrete exploit path.
Do not speculate.
Explain the affected code and remediation.
But which one performs better?
You need evaluations.
Promptfoo focuses heavily on this side of the problem.
You define prompts, test cases, model providers and assertions.
A simplified test might look like:
tests:
- description: detects SQL injection
vars:
code: |
db.query("SELECT * FROM users WHERE id=" + id)
assert:
- type: contains
value: SQL injection
- description: doesn't invent vulnerabilities
vars:
code: |
const user = await db.users.findById(id)
assert:
- type: not-contains
value: SQL injection
You can initialize a project with:
npx promptfoo@latest init
and run evaluations with:
npx promptfoo@latest eval
Then inspect the results with:
npx promptfoo@latest view
The interesting part is that Promptfoo allows you to compare different prompts and models against the same test suite.
You can therefore turn:
"I think this prompt is better"
into:
Prompt A → 82% evaluation score
Prompt B → 91% evaluation score
It can also run evaluations in CI, making prompt changes part of the normal software-development workflow.
When Promptfoo makes sense
Promptfoo is particularly useful when your problem is:
"We change prompts frequently and need to know whether we're introducing regressions."
It is less about organizing the source files and more about measuring what those prompts actually do.
4. GitHub .prompt.yaml — Store Prompts Alongside Your Code
GitHub has also moved toward treating prompts as repository artifacts.
With GitHub Models, prompts can be stored in a repository using .prompt.yml or .prompt.yaml files.
A simplified example:
name: explain-code
description: Explain a code snippet
model:
api: chat
parameters:
temperature: 0.2
messages:
- role: system
content: |
You are an expert software engineer.
Explain code precisely and concisely.
- role: user
content: |
Explain this code:
{{code}}
The important idea here isn't the particular YAML syntax.
It's the workflow:
prompt
│
▼
Git repository
│
├── pull request
├── review
├── history
├── branches
└── CI
Your prompt becomes a first-class part of the repository.
That means a prompt change can go through the same process as a code change:
Developer changes prompt
↓
Git diff
↓
Pull request
↓
Review
↓
Tests / evaluation
↓
Merge
This is particularly attractive for teams that already live inside GitHub and don't want another prompt-management system.
When .prompt.yaml makes sense
It makes sense if your primary requirement is:
"I want prompts version-controlled and integrated with the same GitHub workflow as the rest of my application."
5. OpenAI Prompt Management — Manage Prompts Outside Application Code
A different approach is to move prompt management into the model platform itself.
OpenAI's API provides prompt management through reusable, versioned prompts that can be referenced from API requests rather than embedding the complete prompt in application code.
The conceptual workflow becomes:
Application
│
│ prompt ID + variables
▼
Prompt registry
│
▼
Versioned prompt
│
▼
OpenAI model
This can be useful when prompts are changing frequently and you want to decouple prompt iteration from application deployments.
For example, application code can conceptually do:
response = client.responses.create(
prompt={
"id": "pmpt_...",
"version": "3",
"variables": {
"code": source_code
}
}
)
The application doesn't need to contain the complete prompt.
This introduces a different trade-off from the Git-based approaches.
With repository-based prompt management:
Git repository
↓
prompt source
↓
application
With platform-managed prompts:
application ──────► prompt registry
│
▼
model
The latter can make experimentation and centralized prompt operations easier, especially when prompts are managed by people who aren't modifying application code directly.
How These Tools Fit Together
These projects aren't necessarily competitors.
They address different layers of the problem:
| Tool | Primary problem |
|---|---|
| Prompty | How should prompts be represented as files? |
| PromptKit | How should large prompts be composed from reusable components? |
| Promptfoo | How do we test and evaluate prompts? |
GitHub .prompt.yaml |
How do we keep prompts in the GitHub development workflow? |
| OpenAI Prompt Management | How do we centrally manage/version prompts used by an application? |
You can visualize the overall space like this:
PROMPT ENGINEERING
│
┌───────────────┼────────────────┐
│ │ │
Storage Composition Testing
│ │ │
Prompty PromptKit Promptfoo
│
│
Workflow
│
GitHub prompts
│
│
Runtime / Registry
│
OpenAI Prompt Management
And there is still a lot of room for tooling.
A mature prompt-development stack could eventually look more like a compiler toolchain:
prompt source
│
▼
parser
│
▼
dependency graph
│
▼
composition
│
▼
validation
│
▼
compiler
│
▼
evaluation suite
│
▼
model runtime
At that point, prompts have:
- source files
- imports
- reusable modules
- dependencies
- versions
- tests
- evaluation data
- build artifacts
- CI checks
That is a very different world from putting a multiline string in app.py.
Conclusion
Prompt management is still a young category, and there isn't one universally accepted abstraction yet.
Some tools treat a prompt as a structured document. Others treat it as a composable program. Others focus on testing. Others integrate it into an existing model or Git platform.
That fragmentation is probably healthy.
The underlying problem is real: as AI applications become larger, prompts are becoming software artifacts, and software artifacts need engineering infrastructure.
If you're building an AI application today, a reasonable progression is:
Small project
→ prompt files
Growing project
→ structured prompt format
Many prompts
→ composition + reuse
Frequent changes
→ evaluation tests
Large team
→ Git + CI + versioning
The interesting question is where this ends.
Do prompts eventually need something analogous to a programming language—imports, types, dependency graphs, compilation and static analysis—or will Markdown/YAML plus good testing remain enough?
*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.
git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*
Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.
HexmosTech
/
git-lrc
Free, Micro AI Code Reviews That Run on Git Commit
| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |
git-lrc
Free, Micro AI Code Reviews That Run on Commit
GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.
git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.
In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen
At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…
Top comments (0)