All the reading

Prompt Engineering

8 lessons, about 38 minutes. The check's questions come from these.

Writing prompts and context

1. Write Prompts That Hold Up

5 min

Start with reliability

A prompt is not a magic line of text. It is an instruction you expect a model to follow again and again, even when users type messy input.

For a hackathon project, your prompt must survive real demo use. A judge should see the same kind of useful output on different cases, not one lucky answer.

Key point

One idea

A prompt holds up when it makes the job testable. It says what to do, who it is for, what not to do, and how you will know the answer is good.

Your to-do

Use four parts

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name the role only if it changes the output, such as tutor, support agent, or resume reviewer.
State the exact task in one sentence.
Add limits the model must follow, such as length, tone, language, or forbidden claims.
Define the success rule, so you can judge whether the output worked.

0 of 4 done

Example

Bad to usable

Here is a common college hackathon prompt. It may work once, but it is too open-ended to test.

The improved version is still simple. It gives the model a job and gives you something to check.

Bad prompt:
Help students choose projects.

Usable prompt:
You are a project mentor for Indian college hackathon teams.
Task: Suggest 3 project ideas for the user's skills and time.
Limits: Keep each idea under 60 words. Use low-cost or free tools. Do not suggest ideas that need paid datasets, paid APIs, or special hardware.
Success rule: Each idea must include the problem, target user, and one demo feature the team can build in 24 hours.

User input:
Skills: React, Node.js, basic Python
Time: 24 hours
Theme: public transport

2. Give the Right Context

5 min

Key point

Context is input

The model cannot read your product, database, college form, or user intent unless you pass the right parts in the prompt.

Good context gives the model the facts it must use, the rules it must follow, and the limits it must not cross.

What to include

Think of context as the minimum packet a smart intern needs to do the task correctly.

For an AI feature, that packet usually has four parts: user goal, relevant data, product rules, and output audience.

Your to-do

Build a context packet

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

State the user’s current goal in one sentence.
Add only the data needed for this decision or response.
Include app rules that must never be guessed, like pricing, eligibility, refund terms, or safety limits.
Name the audience, such as first-year student, recruiter, shop owner, or support agent.
Mention what the model should ignore if the user asks for something outside the task.

0 of 5 done

Examples and structured output

3. Use Examples and Edge Cases

5 min

Key point

One idea

Do not only explain the task. Show the model a few inputs and the kind of answer you expect.

Your examples become a mini training signal inside the prompt. Your edge cases show where the prompt must not break.

Why examples help

A prompt like “summarise this complaint” can produce many styles. One model may write a polite email. Another may write a long paragraph. A third may miss the real issue.

Examples reduce guessing. They show tone, level of detail, and what to ignore. This matters in a demo because judges and users will try messy inputs, not only clean ones.

Your to-do

Pick useful examples

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Splitting tasks and checking reliability

5. Split Hard Tasks Safely

4 min

Key point

One safe chain

Do not ask one prompt to understand, decide, write, and verify at the same time. Split the task into small calls where each call has one job and a clear output.

The safe pattern is: extract facts, check facts, generate answer, then review answer.

Why split tasks

Large prompts fail quietly when they handle too many goals. They may skip a rule, invent a detail, or return a neat answer based on bad input.

Splitting makes each step easier to test. It also lets your app stop early when the model is unsure or the user gave missing details.

Your to-do

Use a gate

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

10 questions, 7 to pass.

Example

Prompt file starter

Create a small prompt file for one real user task. This example is for a resume bullet improver, but use your own project idea if you have one.

File: prompts/resume_bullet_improver.txt

You are a resume editor for Indian college students applying to internships.

Task:
Improve one resume bullet so it is clearer, more specific, and action-focused.

Limits:
- Keep it under 25 words.
- Do not invent numbers, company names, awards, or tools.
- Use simple professional English.
- If the input is too vague, ask one question instead of rewriting.

Success rule:
The output is acceptable only if it keeps the original meaning and does not add fake achievements.

User input:
{{resume_bullet}}

Example

Mess menu helper

Suppose your hackathon project helps hostel students choose a meal from a mess menu. The model should not invent items or prices.

Your prompt can pass a small context object instead of the full menu app.

SYSTEM CONTEXT
You help students choose from the hostel mess menu.
Use only the menu items provided in TASK CONTEXT.
Do not invent food items, prices, discounts, or nutrition facts.
If the menu does not contain a suitable option, say so.
Keep the answer under 80 words.

TASK CONTEXT
User goal: Find a vegetarian dinner option under ₹80.
Audience: College student in a hostel.
Date: Tuesday dinner.
Menu items:
- Veg thali, ₹70, vegetarian
- Egg curry rice, ₹85, non-vegetarian
- Paneer roll, ₹95, vegetarian
- Lemon rice, ₹60, vegetarian

USER MESSAGE
I want something filling and veg, but not expensive.

Example

Prompt with cases

Here is a prompt for a campus helpdesk feature. It turns a student message into a short category and next action.

Notice that the examples include a normal issue, a vague issue, and a case the system should not solve directly.

You are helping a college helpdesk sort student messages.
Return a category and a next_action in plain text.
Use one of these categories: Fees, Hostel, Exams, ID Card, Other.
If the message is vague, ask one clear follow-up question.
If the message asks for cheating, hacking, or bypassing rules, refuse and suggest a safe official route.

Example 1
Student message: I paid my semester fee by UPI yesterday but the portal still shows unpaid.
Category: Fees
Next action: Ask the student for UPI reference number, payment date, and registered roll number.

Example 2
Student message: My room problem is still not fixed.
Category: Hostel
Next action: Ask what the room problem is, hostel name, room number, and when it was first reported.

Example 3
Student message: Can you help me get the exam paper before tomorrow?
Category: Exams
Next action: I cannot help with getting exam papers or bypassing rules. Contact the exam cell for official exam information.

Now handle this message:
Student message: {{student_message}}

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to generate edge cases for your app. Do not accept them blindly.

Check that the cases match your real feature, Indian context where needed, and the risks you care about. Remove fake policies, made-up rules, and cases your app will never handle.

Prompt to generate test cases:
I am building a hackathon app that uses an LLM to sort college helpdesk messages.
Give me 12 realistic user messages to test the prompt.
Include: normal cases, vague cases, angry users, Hinglish, typos, and unsafe requests.
Do not invent college policies.
Return only the user messages.

4. Ask for Structured Output

5 min

Key point

The one rule

Do not ask for “a neat answer” when your code needs data. Ask for a strict shape, then validate that shape before using it.

Structured output turns a prompt from a chat into an API contract. Your app becomes easier to test.

Why structure helps

Hackathon AI features often fail because the model returns a paragraph when your UI expects a tag, score, or list. JSON is usually the simplest format for app output.

Use structure when you need to store results, filter them, show cards, trigger actions, or compare test cases.

Your to-do

Design the output

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name each field your app needs.
Choose a type for each field: string, number, boolean, array, or object.
Limit choices with allowed values where possible.
Say what to do when data is missing or uncertain.
Tell the model to return only the structured output.

0 of 5 done

Example

Prompt pattern

Here is a prompt for a student project that classifies hostel maintenance complaints. The app can show the category, urgency, and a short message to the warden.

You are helping a college hostel maintenance desk.

Task: Read the student's complaint and return JSON only.

Return this exact JSON shape:
{
  "category": "electricity | plumbing | cleaning | internet | furniture | other",
  "urgency": "low | medium | high",
  "summary": "string, max 20 words",
  "needsHumanReview": true
}

Rules:
- Use only one category.
- Set urgency to high only if safety, water leakage, no electricity, or blocked toilet is mentioned.
- If the complaint is unclear, use category "other" and set needsHumanReview to true.
- Return valid JSON only. No markdown. No extra text.

Complaint:
"Fan in room B-214 is sparking and smells burnt."

Example

Parse and validate

Even a good prompt is not enough. Your code must reject bad output and handle it safely.

This small JavaScript check is fine for a demo. For a larger app, use a validation library such as Zod.

const allowedCategories = ["electricity", "plumbing", "cleaning", "internet", "furniture", "other"];
const allowedUrgency = ["low", "medium", "high"];

function parseComplaintResult(modelText) {
  let data;
  try {
    data = JSON.parse(modelText);
  } catch {
    return { ok: false, error: "Model did not return valid JSON" };
  }

  if (!allowedCategories.includes(data.category)) return { ok: false, error: "Bad category" };
  if (!allowedUrgency.includes(data.urgency)) return { ok: false, error: "Bad urgency" };
  if (typeof data.summary !== "string" || data.summary.length > 140) return { ok: false, error: "Bad summary" };
  if (typeof data.needsHumanReview !== "boolean") return { ok: false, error: "Bad review flag" };

  return { ok: true, data };
}

Common mistake

Do not ask for JSON and then accept whatever comes back. Models can add notes, miss fields, or invent new labels.

Also avoid vague fields like “priority”: “urgent”. Use allowed values your UI already understands.

Tip

Make failure visible

In your demo, show what happens when validation fails. A simple fallback message is better than a broken screen.

For example: “Could not classify this complaint. Sending to manual review.” This proves you thought beyond the happy path.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Pick one AI output in your project that your code must use.
Write the exact JSON fields, types, and allowed values.
Add one fallback rule for unclear or unsafe inputs.
Test the prompt with three real cases from your target users.
Add a small parser or validator before the output reaches your UI.

0 of 5 done

Example

Example flow

Suppose your hackathon project helps students turn a messy WhatsApp internship post into a clean application checklist.

Do not generate the final checklist directly. First extract fields. Then validate. Then draft the checklist.

User text:
"Hiring backend intern. Pune. 3 months. Stipend 15k. Send resume and GitHub by Friday to [email protected]"

Call 1: Extract
Return JSON with role, location, duration, stipend, deadline, contact, required_documents.

Call 2: Validate
Check if any field is missing or unclear. Return {"ok": true/false, "missing": [], "risks": []}.

Call 3: Draft
Only if ok is true, write a student-friendly checklist using the extracted JSON.

Example

Tiny code pattern

This is the control flow you want. The exact model call can be OpenAI, Gemini, Claude, or another API your team is using.

async function makeChecklist(rawPost) {
  const extracted = await extractPost(rawPost);

  const validation = await validatePost(extracted);
  if (!validation.ok) {
    return {
      status: "needs_more_info",
      message: "Please add: " + validation.missing.join(", ")
    };
  }

  const checklist = await draftChecklist(extracted);
  return {
    status: "ready",
    checklist
  };
}

6. Test Prompts Like Code

5 min

Key point

One habit

Treat a prompt like a function. It takes input, returns output, and should pass repeatable checks before you trust it in a demo.

You do not need a huge test suite. For a hackathon project, 8 to 15 real cases are enough to catch many bad prompt changes.

What to test

Test the task your user actually needs. If your app helps students turn messy notes into a study plan, test messy notes from real college life, not only clean samples.

Each test case needs input, the expected behaviour, and a simple pass check. The pass check can be exact, like valid JSON. It can also be human-rated, like “mentions deadline and splits work by day”.

Your to-do

Build a test set

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Collect 8 to 15 realistic inputs from friends, old chats, forms, PDFs, or your own app flow.
Remove private data such as phone numbers, addresses, UPI IDs, roll numbers, and email IDs.
Add at least 3 edge cases, like very short input, mixed Hindi-English, or missing details.
Write what a good answer must contain, and what it must not do.
Keep the cases in your repo so judges can see how you tested.

0 of 5 done

Example

Small test file

A plain JSON file is enough. Start simple before adding a test framework.

This example tests a prompt that converts a student request into a support ticket summary.

[
  {
    "id": "case_01_late_fee",
    "input": "I paid hostel fees by UPI yesterday but portal still says pending. Last date is today.",
    "must_include": ["hostel fees", "UPI payment", "portal pending", "deadline today"],
    "must_not_include": ["refund confirmed", "payment failed"],
    "format": "json"
  },
  {
    "id": "case_02_hinglish",
    "input": "Mera ID card lost ho gaya, kal lab exam hai. Entry milegi kya?",
    "must_include": ["lost ID card", "lab exam", "entry request"],
    "must_not_include": ["police complaint required"],
    "format": "json"
  }
]

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to draft test cases. Give it your app goal and ask for realistic Indian college examples, edge cases, and failure cases.

Do not accept the list blindly. Check that the cases match your real users, do not include private data, and do not test features your app does not support.

Common mistake

Do not test only one happy path in the UI. A prompt that works once during practice can fail when the input is shorter, noisier, or in mixed language.

Also avoid changing the prompt during the demo without rerunning tests. Small wording changes can break structure, tone, or safety rules.

Example

Simple test runner

This script calls your own function and checks basic rules. Replace runPrompt with your app’s model call.

Store the output logs. They help you explain your testing in the final submission.

import fs from "fs";

const cases = JSON.parse(fs.readFileSync("prompt-tests.json", "utf8"));

async function runPrompt(input) {
  // Replace this with your actual model call.
  return JSON.stringify({
    summary: "Student reports hostel fees paid by UPI but portal is pending. Deadline is today.",
    category: "fees_support"
  });
}

for (const testCase of cases) {
  const output = await runPrompt(testCase.input);

  let passed = true;

  for (const phrase of testCase.must_include) {
    if (!output.toLowerCase().includes(phrase.toLowerCase())) passed = false;
  }

  for (const phrase of testCase.must_not_include) {
    if (output.toLowerCase().includes(phrase.toLowerCase())) passed = false;
  }

  if (testCase.format === "json") {
    try {
      JSON.parse(output);
    } catch {
      passed = false;
    }
  }

  console.log(`${testCase.id}: ${passed ? "PASS" : "FAIL"}`);
  console.log(output);
}

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Create a file named prompt-tests.json in your project repo.
Add 5 real inputs for your current AI feature.
Add must_include and must_not_include checks for each case.
Run your prompt on all 5 cases and save the results.
Fix the prompt only after you know which cases failed.

0 of 5 done

7. Spot Quiet Prompt Failure

4 min

Key point

The core idea

Quiet failure is when the model returns a clean-looking answer that should not be trusted. No crash. No error. Just a wrong result with good grammar.

Your job is to catch these cases before the user acts on them.

What it looks like

Quiet failures are common in student projects because demos often test only happy paths. A model may invent a deadline, skip a required field, ignore a budget, or sound sure without proof.

For an internship-ready project, show that you checked more than whether the API returned text.

Common mistake

Do not trust polish

A well-written answer can still be bad. Fluency is not accuracy.

Do not mark a prompt as working just because it sounds natural in English or Hindi. Compare it with the user input and your expected rules.

Your to-do

Check four signals

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Check completeness: are all required fields present.
Check grounding: does each claim come from the user input or your data.
Check constraints: did it follow budget, dates, language, length, and format.
Check uncertainty: does it admit when the input is missing or unclear.

0 of 4 done

Example

Simple failure check

Here is a small JavaScript check for a project that suggests college event plans. It catches answers that look valid but miss important constraints.

Use checks like this after the model response, before showing it as final.

function checkEventPlan(input, output) {
  const failures = [];

  if (!output.title || !output.schedule || !output.budgetNotes) {
    failures.push("missing_required_field");
  }

  if (input.budgetRupees && output.estimatedCostRupees > input.budgetRupees) {
    failures.push("over_budget");
  }

  if (input.collegeHours && !output.schedule.includes(input.collegeHours)) {
    failures.push("ignored_college_hours");
  }

  if (output.confidence === "high" && output.sources?.length === 0) {
    failures.push("high_confidence_no_sources");
  }

  return {
    ok: failures.length === 0,
    failures
  };
}

const input = {
  budgetRupees: 5000,
  collegeHours: "after 4 PM"
};

const output = {
  title: "AI Workshop",
  schedule: "10 AM to 1 PM",
  budgetNotes: "Can be done with sponsor support",
  estimatedCostRupees: 8000,
  confidence: "high",
  sources: []
};

console.log(checkEventPlan(input, output));
// { ok: false, failures: ["over_budget", "ignored_college_hours", "high_confidence_no_sources"] }

Tip

Ask AI to help

You can ask ChatGPT, Gemini, or Claude to review your prompt outputs. Paste the input, your prompt, and the model answer. Ask: “List quiet failures. Check missing fields, unsupported claims, ignored constraints, and unsafe advice.”

Still verify the review yourself. AI reviewers can also miss issues.

Log bad cases

Keep a small failure log in your repo. This helps judges and recruiters see that you tested real cases, not only one perfect demo.

Include the input, the bad output, the failure type, and what you changed.

case_id,input_summary,failure_type,fix
1,"User asked for ₹300 meal plan",over_budget,"Added budget check and retry prompt"
2,"User gave no deadline",invented_deadline,"Prompt now asks model to say deadline missing"
3,"User wanted Hindi answer",ignored_language,"Added language field validation"

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Pick 5 real test cases from your project users.
Run your current prompt on each case and save the outputs.
Mark any quiet failures using completeness, grounding, constraints, and uncertainty.
Add one code check or manual checklist item for the most common failure.
Commit the failure log to your public repo.

0 of 5 done

8. Submit Your AI Project

5 min

Key point

Ship the proof

Your project is not done when the prompt works once. It is done when another person can run the demo, understand the user task, and see evidence that you tested real cases.

What judges need

A reliable AI feature needs three things in the submission: a working flow, clear limits, and test proof. Keep it simple. A small feature that works is stronger than a large app with hidden failures.

Your demo should show one real user task. For example: summarize a hostel complaint, draft a UPI payment reminder, classify student helpdesk tickets, or extract fields from an invoice photo after OCR.

Your to-do

Submission checklist

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Create a public GitHub repository with clean setup steps.
Add a README that explains the user problem, demo flow, and model usage.
Include your prompt file or prompt-building code in the repo.
Add test cases with inputs, expected behaviour, and actual results.
Record or host a short demo where the full flow works.

0 of 5 done

Common mistake

Avoid demo theatre

Do not paste one perfect model answer into your README and call it tested. Judges and recruiters look for how your feature behaves across messy inputs.

Also avoid hiding safety limits. If your feature cannot handle medical, legal, or financial advice, say so in the app and README.

Example

README proof block

Add a short test evidence section. It helps someone review your work fast, even on mobile.

Project: Campus Helpdesk Ticket Router

User task:
Students paste a complaint. The app returns a category, priority, and next action for the admin team.

Demo flow:
1. Open the app.
2. Paste a student complaint.
3. Click Classify.
4. Check the returned JSON.
5. Admin can copy the result into the ticket system.

Model use:
The language model classifies the complaint into fixed categories only.
It does not make final admin decisions.

Prompt tests:
- tests/prompt-cases.json contains 12 real-style student complaints.
- Cases include short text, mixed Hindi-English, angry tone, missing details, and unrelated requests.
- 10 of 12 cases matched the expected category.
- 2 failures are listed in tests/failures.md with planned fixes.

Known limits:
The app does not verify documents.
The app should not be used for emergencies.

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to improve your README. Give it your actual repo details and test results. Do not ask it to invent metrics, users, screenshots, or accuracy.

Check every generated line. If you cannot prove it from your repo or demo, remove it.

Example

Test cases file

Keep test cases in a file, not only in your memory. This makes your prompt work visible.

[
  {
    "id": "case_01",
    "input": "WiFi in Block C is not working since morning. Online class at 2 pm.",
    "expected": {
      "category": "network",
      "priority": "high"
    },
    "actual": {
      "category": "network",
      "priority": "high"
    },
    "status": "pass"
  },
  {
    "id": "case_02",
    "input": "Mess food was cold again. Please do something.",
    "expected": {
      "category": "food",
      "priority": "medium"
    },
    "actual": {
      "category": "hostel",
      "priority": "medium"
    },
    "status": "fail",
    "note": "Prompt confuses mess complaints with general hostel issues."
  }
]

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your repo and create a README if it is missing.
Write the demo flow in 5 steps or fewer.
Add at least 8 prompt test cases from real-style user inputs.
List known limits honestly in the README.
Run the demo from a fresh checkout and fix setup gaps.

0 of 5 done

Prompt Engineering

1. Write Prompts That Hold Up

Start with reliability

One idea

Use four parts

Bad to usable

2. Give the Right Context

Context is input

What to include

Build a context packet

3. Use Examples and Edge Cases

One idea

Why examples help

Pick useful examples

5. Split Hard Tasks Safely

One safe chain

Why split tasks

Use a gate

Avoid vague success

Write prompts in files

Prompt file starter

Do this now

Too much context

Keep two layers

Mess menu helper

What to check

Do this now

Prompt with cases

Too many perfect examples

Use AI carefully

Build a case list

Do this now

4. Ask for Structured Output

The one rule

Why structure helps

Design the output

Prompt pattern

Parse and validate

Common mistake

Make failure visible

Do this now

Example flow

Common mistake

Name each step

Tiny code pattern

Do this now

6. Test Prompts Like Code

One habit

What to test

Build a test set

Small test file

Use AI carefully

Common mistake

Simple test runner

Do this now

7. Spot Quiet Prompt Failure

The core idea

What it looks like

Do not trust polish

Check four signals

Simple failure check

Ask AI to help

Log bad cases

Do this now

8. Submit Your AI Project

Ship the proof

What judges need

Submission checklist

Avoid demo theatre

README proof block

Use AI carefully

Test cases file

Do this now