When people first hear the word "prompt engineering," it sounds like it simply means writing better instructions.

Prompt Engineering Foundations

But after learning how LLMs work, it becomes clear that prompt engineering is more than that.

A prompt is not just a question we ask the model. It is the way we guide the model's behavior.

It tells the model:

• what task to perform
• what context to use
• what role to take
• what format to return
• what rules to follow
• what to avoid
• how carefully it should reason
• how the output should be used

A weak prompt gives the model too much freedom. A strong prompt gives the model direction.

In this blog, I'm documenting the core prompt engineering techniques I learned, including zero-shot prompting, few-shot prompting, role prompting, constraints, structured output, Chain-of-Thought style prompting, self-consistency, prompt chaining, and prompt debugging.

What Prompt Engineering Actually Means

Prompt engineering is the process of designing instructions that help an LLM produce a more useful, accurate, and controlled response.

A simple prompt can work for simple tasks. For example:

Summarize this paragraph.

But when the task becomes more specific, the prompt also needs to become more specific. For example:

Summarize this paragraph for a beginner.
Keep it under 5 bullet points.
Avoid technical jargon.
Do not add information that is not present in the paragraph.

The second prompt is stronger because it gives the model more direction.

It controls:

That is the real purpose of prompt engineering. Not just asking. Guiding.

1. Zero-Shot Prompting

Zero-shot prompting means asking the model to perform a task without giving examples.

Example:

Explain tokenization in simple terms.

Here, we are only giving the instruction. We are not showing the model any sample input or sample output.

Zero-shot prompting works well when the task is common or simple. Examples:

• Summarize this text.
• Translate this sentence.
• Explain this concept.
• Classify this message as positive, negative, or neutral.
• Rewrite this message politely.

But zero-shot prompts should not be vague.

A weak zero-shot prompt:

Explain AI.

This is too broad.

A better zero-shot prompt:

Explain AI to a beginner web developer.
Keep it under 300 words.
Use simple examples.
Avoid advanced math.

This is still zero-shot because there are no examples, but it is much clearer.

So zero-shot does not mean short. It means instruction without examples.

2. Few-Shot Prompting

Few-shot prompting means giving the model a few examples so it can understand the pattern we want.

Example:

Convert casual messages into polite professional replies.

Example 1:
Input: Send me the file.
Output: Could you please send me the file?

Example 2:
Input: Call me now.
Output: Could you please call me when you are free?

Now convert:
Input: Check this issue.

The model understands the style from the examples.

Few-shot prompting is useful when:

• tone matters
• format matters
• the pattern is custom
• zero-shot output is inconsistent
• labels or categories are tricky

For example, if we want the model to classify support tickets into custom categories, few-shot examples can help.

Example 1:
Input: I cannot log in to my account.
Category: Authentication Issue

Example 2:
Input: My payment was deducted twice.
Category: Billing Issue

Example 3:
Input: The page keeps loading forever.
Category: Performance Issue

Now the model has a pattern to follow.

But bad examples can confuse the model. If examples are inconsistent, too long, or unrelated, the model may copy the wrong behavior.

So few-shot prompting is powerful, but the examples must be clear and close to the actual task.

3. Role Prompting and Personas

Role prompting means telling the model what role or perspective it should take.

Example:

You are a senior React developer.
Review this component for bugs, readability, and performance issues.

The role changes how the model approaches the task. Without a role, the model may give a generic answer. With a role, the model answers from a specific viewpoint.

Useful roles include:

You are a technical recruiter.
You are a senior frontend engineer.
You are an ATS resume reviewer.
You are a strict JSON extraction assistant.
You are a beginner-friendly JavaScript mentor.
You are a security reviewer.

But role alone is not enough.

Weak prompt:

You are an HR expert. What is our company notice period?

This is still weak because the model does not know the company policy.

Better prompt:

You are an HR assistant.

Answer the employee question using only the provided company policy.

Policy:
[insert policy here]

Question:
What is the notice period?

Rules:
- Use only the policy text.
- Do not guess.
- If the answer is not mentioned, say "not mentioned in the provided policy."

Role gives perspective. Context gives information. Rules control the answer.

A good prompt usually needs more than just role prompting.

4. Constraints

Constraints are rules that control the model's output. They tell the model what boundaries it should follow.

Examples:

Keep the answer under 100 words.
Use simple language.
Return only JSON.
Use only the provided context.
Do not include extra explanation.
Mention only skills found in the resume.

Constraints are important because LLMs often try to be helpful by adding more than we asked for. That can be useful in casual chat, but in applications it can create problems.

For example, if we are building a job description parser, we do not want the model to randomly add extra fields or guess missing values.

A strong constrained prompt:

Extract job details from the job description.

Rules:
- Use only information present in the job description.
- Do not guess missing values.
- Use null if a field is missing.
- Return valid JSON only.
- Do not add extra fields.

Constraints reduce unwanted behavior. They make the output more predictable.

5. Negative Prompting

Negative prompting is a specific type of constraint. It tells the model what not to do.

Examples:

Do not guess.
Do not use outside knowledge.
Do not add extra fields.
Do not include markdown.
Do not make the tone too formal.
Do not rewrite the whole resume.

General constraints can say what to do. Negative prompts say what to avoid.

Both are useful together. For example:

Use only the provided context.
Do not guess.
If the answer is not present, say "not mentioned in the provided context."

This is stronger than simply saying:

Do not hallucinate.

"Do not hallucinate" is weak because it does not tell the model what to do when information is missing. A better prompt gives both the boundary and the fallback.

Use only the provided context.
If the information is missing, return null.
Do not guess.

Negative prompting works best when it is specific.

Weak:

Do not make it bad.

Better:

Avoid generic advice.
Do not use hype words.
Do not make it sound too corporate.
Keep it short and natural.

6. Structured Output Like JSON

Structured output means asking the model to return data in a fixed format. This is important when the output will be used by code.

For example, if we are extracting job details from a job description, a paragraph is not ideal.

Bad output for an app:

The role is Frontend Developer. The job requires React, TypeScript, and Redux. The location is Bangalore.

Better output:

{
  "role": "Frontend Developer",
  "experience": null,
  "location": "Bangalore",
  "workMode": null,
  "skills": ["React", "TypeScript", "Redux"]
}

JSON is easier to parse, validate, store, and display in a frontend.

A good structured output prompt should include:

• exact schema
• field names
• data types if needed
• missing value rule
• no extra fields rule
• valid JSON only rule

Example:

Extract job details from the job description.

Return valid JSON only using this schema:

{
  "role": "",
  "experience": "",
  "location": "",
  "workMode": "",
  "skills": []
}

Rules:
- Use only information present in the job description.
- Use null if a field is missing.
- Use an empty array if no skills are mentioned.
- Do not guess.
- Do not add extra fields.
- Do not include markdown or explanation.

Structured output is not just about clean formatting. It makes LLM responses usable in real applications.

7. Chain-of-Thought Style Prompting

Chain-of-Thought prompting is usually discussed as asking the model to reason step by step. But in production, we usually do not need the model to show every internal reasoning step.

What we actually want is better reasoning quality and a clear final answer.

A production-friendly version is:

Think carefully before answering.
Return only the final answer and 2 short reasons.

This is better than:

Show your full reasoning step by step.

Because users usually do not need a long reasoning dump. They need the result.

Chain-of-Thought style prompting is useful for tasks like:

• debugging
• comparison
• ranking
• planning
• decision-making
• root-cause analysis
• complex classification

Example:

Compare these two candidates for a React Developer role.

Think carefully based on:
- React experience
- project relevance
- API integration
- TypeScript exposure
- missing requirements

Return only:
1. Best match
2. 3 reasons
3. Concerns

Here, we are encouraging careful reasoning, but we are controlling the output.

The key idea:

Chain-of-Thought style prompting is not mainly about showing long reasoning. It is about improving reasoning quality for multi-step tasks.

8. Self-Consistency Technique

Self-consistency is used to improve reliability in reasoning-heavy tasks.

Instead of trusting one quick answer, we ask the model to check the problem from multiple angles or reasoning paths, then choose the most consistent answer.

Example:

Evaluate this resume against the job description from multiple angles:

1. Required skills match
2. React project relevance
3. Experience level
4. Missing requirements
5. Recruiter screening risk

Then return:
- Match score
- Strongest reasons
- Biggest gaps
- Final recommendation

This is useful when one answer may be unreliable.

Use self-consistency for:

• resume-job matching
• debugging
• root-cause analysis
• logic problems
• important decisions
• classification with edge cases
• RAG failure analysis

But self-consistency does not fully prevent hallucination. If the context is wrong, outdated, or missing, multiple reasoning paths can still produce the wrong answer.

So for factual tasks, self-consistency should be combined with:

• correct context
• retrieval checks
• low randomness
• source grounding
• validation

Self-consistency improves reasoning reliability. It does not replace grounding.

9. Prompt Chaining Across Multiple Calls

Prompt chaining means breaking one big task into multiple smaller LLM calls. The output of one call becomes the input for the next call.

Instead of asking the model to do everything at once:

Read this resume, compare it with the job description, find gaps, rewrite bullets, generate a cover letter, and return JSON.

We can split it into smaller steps.

Example: Resume matching app

This is easier to control. One huge prompt can become messy. The model may miss details, mix tasks, or return inconsistent output.

Prompt chaining helps with:

• better accuracy
• cleaner outputs
• easier validation
• easier debugging
• better control over complex workflows

Prompt chaining and structured output often work together. Each step can return structured JSON, and the next step can use that JSON as input.

Step 1:
Extract job requirements.

Step 2:
Extract resume details.

Step 3:
Compare both structured outputs.

Step 4:
Generate final recommendation.

This makes the workflow more reliable than doing everything in one large prompt.

10. Common Prompt Mistakes and Fixes

Prompt engineering is not only about writing prompts. It is also about debugging bad outputs.

Here are some common mistakes.

Mistake 1: Prompt is too vague

Weak prompt:

Review my resume.

Better:

You are a technical recruiter reviewing a resume for React Developer roles.

Check:
- ATS friendliness
- React relevance
- skills section
- project impact
- missing keywords
- clarity of experience bullets

Return section-wise feedback.

Mistake 2: No context is provided

Weak prompt:

What is our company leave policy?

The model may guess because no policy is provided.

Better:

Answer using only the provided company policy.

Policy:
[paste policy]

Question:
What is the sick leave policy?

If the answer is not mentioned, say "not mentioned in the provided policy."

Mistake 3: Asking for JSON but not giving schema

Weak prompt:

Give output in JSON.

Better:

Return valid JSON only using this schema:

{
  "role": "",
  "experience": "",
  "location": "",
  "skills": []
}

Do not add extra fields.
Use null if a field is missing.

Mistake 4: Using only negative instructions

Weak prompt:

Do not hallucinate.

Better:

Use only the provided context.
If the answer is missing, say "not mentioned in the provided context."
Do not guess.

Mistake 5: Giving too many tasks in one prompt

Weak prompt:

Extract, compare, rewrite, score, summarize, and generate a cover letter.

Better:

Break the workflow into multiple calls:
1. Extract data
2. Compare
3. Score
4. Generate suggestions
5. Create final output

This is where prompt chaining helps.

Mistake 6: Not checking the actual failure

When output is bad, beginners often rewrite the prompt randomly.

But bad output can happen for different reasons:

• wrong context
• wrong retrieval
• unclear task
• missing constraint
• bad examples
• high randomness
• wrong format
• model limitation

So the first question should be:

What exactly failed?

If the model gives the wrong fact, check context and retrieval first. If the format is wrong, improve schema and validation. If the tone is wrong, add tone constraints or few-shot examples. If the answer is too random, check temperature and top-p.

Prompt debugging means identifying the failure type before changing the prompt.

11. Final Mental Model

A good prompt usually has multiple parts.

Example:

You are a senior technical recruiter.          ← role

Review this resume for a React Developer role. ← task

Use the resume and job description below.       ← context

Do not guess. Do not add fake experience.       ← constraints / negative prompting

Follow this example format.                     ← few-shot pattern if needed

Return:
{
  "matchScore": "",
  "strengths": [],
  "gaps": [],
  "suggestions": []
}                                                ← structured output

All prompting techniques are not separate tricks. They are different tools for controlling the model.

Prompt engineering is not about writing a magical sentence. It is about designing the interaction between your application and the model.

A strong prompt reduces confusion, limits unwanted behavior, improves consistency, and makes the output easier to use in real applications.

That is why prompt engineering is one of the first practical skills to learn when building GenAI applications.