Developer-first prompt engineering for reliable AI outputs: prompt anatomy, grounding, few-shot design, decomposition, and validation patterns that reduce hallucinations across the software development lifecycle.
This repository is the foundation layer for working developers who want prompts that are precise, testable, and production-usable. The focus is not on clever wording. The focus is on prompt structure that reduces ambiguity, constrains unsupported claims, and gives models a repeatable path to produce useful results.
┌────────────────────────────────────────────────────────┐
│ Reliable Prompt Anatomy │
│ │
│ Role -> Context -> Task -> Examples -> Constraints │
│ -> Output Format -> Validation │
│ │
└───────────────────────┬────────────────────────────────┘
│
▼
┌───────────────────────────────────────────┐
│ Model behavior becomes more constrained │
│ - fewer invented facts │
│ - clearer scoping │
│ - more verifiable outputs │
│ - easier prompt iteration │
└───────────────────────────────────────────┘
By the end of this repository, you should be able to:
- structure prompts so the model has less room to invent unsupported details
- separate role, context, task, constraints, and validation into a repeatable workflow
- apply prompt patterns across planning, coding, debugging, review, and documentation tasks
- prepare for the workflow and evaluation repositories that follow this one
This repository works best if you already:
- use LLMs in developer workflows or want to start doing so
- understand the basics of software delivery, debugging, and documentation work
- want more reliable behavior instead of creative but unstable outputs
After this repository, continue with:
- cursor-ai-development-workflows for repo-based AI-assisted development flows
- llm-evals-and-anti-hallucination for measurement and release-gate thinking
Most weak prompts fail in predictable ways:
- The role is vague, so the model improvises the standard of quality.
- The context is incomplete, so the model fills gaps with guesses.
- The task is underspecified, so the output drifts.
- The output format is loose, so downstream use becomes fragile.
- There is no validation clause, so the model never checks itself.
This repository gives you patterns to fix those failure modes systematically.
Use this as the default prompt skeleton for developer workflows.
| Component | Purpose | Hallucination Reduction Effect |
|---|---|---|
| Role | Defines the model's operating stance | Reduces behavioral drift |
| Context | Supplies bounded facts and codebase reality | Reduces unsupported assumptions |
| Task | States the exact job to do | Reduces scope creep |
| Examples | Shows what "good" looks like | Reduces formatting and reasoning variance |
| Output Format | Forces structure | Reduces ambiguous results |
| Constraints | States what not to do | Reduces fabricated APIs, files, claims |
| Validation Criteria | Forces a final check | Reduces silent failure |
| File | Description |
|---|---|
examples/01_prompt_anatomy.md |
Breakdown of the base prompt shape with a developer workflow example |
examples/02_grounded_code_generation.md |
How to ask for code without inviting invented implementation details |
examples/03_few_shot_patterns.md |
Few-shot prompting patterns for reviews, triage, and structured engineering output |
examples/04_prompt_chaining_for_developers.md |
How to split complex development tasks into safer prompt stages |
templates/base-prompt-template.md |
Reusable master template with placeholders |
checklists/anti-hallucination-checklist.md |
Review checklist for shipping prompts safely |
| SDLC Stage | Prompt Goal | Prompt Behavior |
|---|---|---|
| Discovery | Understand codebase reality | Ask for evidence, files, dependencies |
| Planning | Produce an execution plan | Separate facts from assumptions |
| Implementation | Generate or edit code | Restrict changes to known files and APIs |
| Debugging | Diagnose the root cause | Require hypotheses tied to evidence |
| Testing | Produce verification assets | Require explicit assertions and expected outcomes |
| Review | Find risks and regressions | Prefer concrete findings over summaries |
| Documentation | Explain real changes | Ground docs in existing code or diff |
The common themes across current vendor guidance are consistent:
- Be explicit about instructions and response format.
- Add relevant context instead of assuming the model knows it.
- Use few-shot examples when consistency matters.
- Break hard tasks into steps or chained prompts.
- Evaluate prompts empirically instead of trusting intuition.
For developers, that translates into a practical rule:
If the model could plausibly invent a detail, your prompt should either provide that detail, forbid invention, or define the fallback behavior when the detail is missing.
- Start every serious prompt with a bounded role and explicit task.
- Prefer "use only the provided code/context" over broad open-ended prompting.
- Ask the model to state missing information instead of inferring it.
- Require assumptions to be labeled as assumptions.
- Request evidence-backed reasoning for debugging and code review tasks.
- For code generation, require compatibility with the current file structure and APIs.
- Add a validation step that checks output against constraints before finalizing.
- Treat prompt changes like code changes: version them and evaluate them.
- OpenAI prompt engineering guidance: roles, reusable prompts, few-shot, context, evals
- Anthropic prompt engineering overview: define success criteria and test empirically
- Google prompt design strategies: constraints, formatting, chaining, self-critique, grounding
- Promptfoo anti-hallucination guidance: evals, rubrics, prompt comparison, regression testing
Dhiraj Singh
This repository is shared publicly for learning and reference. It is made available for everyone through VAIU Research Lab. For reuse, redistribution, adaptation, or collaboration, contact Dhiraj Singh / VAIU Research Lab.