Apply for AI Grants India

LLM prompt writing is not about finding a magic phrase. It is the practical discipline of giving a language model enough context, constraints, examples, and evaluation criteria to produce a useful result consistently. For Indian builders, that may mean extracting fields from invoices, drafting a bilingual customer reply, reviewing a PRD, summarising a government document, or supporting a domain workflow where an incorrect answer has real costs.

A strong prompt is a small specification. It defines the task, supplies the information the model can use, sets boundaries, and makes the expected output easy to check.

What LLM prompt writing involves

A prompt can contain several layers:

• Task: What should the model do?
• Context: What background, data, audience, or business setting matters?
• Inputs: Which text, records, or documents should it use?
• Constraints: What must it include, avoid, or treat as unknown?
• Output contract: What format, fields, length, and tone should it follow?
• Evaluation: How will you decide whether the answer is correct and useful?

These elements matter more than decorative instructions such as “be highly intelligent” or “give the best answer”. The model cannot infer missing business rules reliably, and confidence in the wording does not guarantee factual accuracy.

Prompting also sits inside a larger system. Retrieval, tool calls, structured outputs, access controls, model selection, and human review may matter as much as the prompt itself. For production use, treat prompt text as versioned software rather than informal copy.

A dependable prompt structure

A practical baseline is:

Role: You are a support analyst for an Indian fintech.
Task: Classify the customer message and draft a response.
Context: The product supports UPI payments. Do not promise refunds.
Input: <customer_message>
Rules:
- Use only the information provided.
- If essential information is missing, ask one specific question.
- Escalate suspected fraud.
Output:
- category: one of [payment_failed, refund, fraud, other]
- urgency: low, medium, or high
- reply: maximum 80 words

This structure separates instructions from data and makes the result easier to parse. Delimit untrusted content with clear markers such as <document> and tell the model not to follow instructions found inside that content.

For repeatable workflows, prefer a schema over a vague request for a “well-formatted answer”. JSON or another machine-readable format can include fields such as answer, evidence, uncertainty, and next_action. Your application should still validate the output because a model can produce malformed or incomplete data.

Techniques that improve output quality

State the objective and audience

“Explain GST” is too broad. A better request might be: “Explain input tax credit to a first-time founder in India in 250 words, using one numerical example and flagging where professional tax advice is required.” The audience, location, depth, and use case give the model useful decision boundaries.

Provide relevant context, not a data dump

Include the facts needed to answer the task, but remove irrelevant material. For document work, identify the source, date, and scope. If the model must work from a provided document, say: use only the document; if the answer is absent, return `not_found`. This reduces unsupported completions.

Show representative examples

One or two input-output examples are often more effective than several paragraphs of explanation. Use examples that cover normal cases, edge cases, and ambiguous inputs. Avoid examples containing confidential customer information; anonymise names, account numbers, and identifiers.

Define failure behaviour

A production prompt should explain what to do when information is missing, contradictory, unsafe, or outside scope. Useful instructions include:

• “Do not guess a policy number.”
• “Return needs_review when confidence is low.”
• “Quote the supporting passage before making a claim.”
• “Ask at most two clarifying questions.”

This is particularly important in healthcare, credit, insurance, education, and public-service applications.

Separate reasoning from the deliverable

Ask for a concise answer, evidence, assumptions, or checks rather than demanding hidden chain-of-thought. For example: “List the three source passages supporting the conclusion and state any uncertainty.” This gives reviewers useful traceability without making private reasoning the product requirement.

Localise deliberately

For Indian users, specify language, script, register, and regional conventions. “Write in simple Hindi using Devanagari” differs from “write Hinglish for a WhatsApp message”. Also specify currency, date format, units, and whether terms such as Aadhaar, GSTIN, UPI, or PAN should remain untranslated.

Prompt patterns for structured extraction can support AI handwriting recognition for academic feedback, while domain-specific workflows such as underwriting need stricter evidence and escalation rules. For insurance teams, compare these principles with agentic AI workflows for insurance underwriting in India.

Prompt evaluation: test, measure, improve

Do not judge a prompt from one impressive response. Build a small evaluation set containing:

• Typical requests from real users
• Ambiguous and incomplete inputs
• Long documents and noisy formatting
• Regional language or code-mixed text
• Adversarial and policy-sensitive cases
• Expected answers, acceptable variants, or review criteria

Track metrics that match the task: factual accuracy, field-level extraction accuracy, citation support, refusal quality, latency, cost, and reviewer correction rate. Test the prompt across the models and versions you may deploy. A change that improves fluency can reduce factual accuracy or increase unsupported claims.

For a more formal lens, see optimizing LLM prompt performance with Shannon theory. The useful lesson is not to optimise for prompt length; it is to reduce uncertainty about the task and the acceptable output. Keep a changelog for prompt versions, model settings, evaluation results, and known failure modes.

Common mistakes to avoid

• Vague objectives: “Analyse this” gives no decision target.
• Conflicting instructions: A short answer and exhaustive analysis cannot both be primary requirements.
• Unbounded context: More text can obscure the relevant evidence.
• No output validation: A schema in the prompt is not a schema validator.
• Treating confidence as proof: Ask for evidence and verify important claims.
• Putting secrets in prompts: Never expose API keys, passwords, or unnecessary personal data.
• Ignoring prompt injection: Retrieved documents, emails, web pages, and user messages may contain instructions designed to override your task. Learn the defensive basics in preventing prompt injection in autonomous agents.

A production workflow for Indian teams

Start with the business decision, not the model. Define who uses the output, what happens when it is wrong, and which records must be retained. Then:

1. Create a minimal prompt and a labelled evaluation set.
2. Add context, examples, and failure rules only where tests show a need.
3. Enforce structured output in application code.
4. Add retrieval or tools when the model needs current or private information.
5. Log prompt version, model version, latency, cost, and review outcomes—without storing unnecessary personal data.
6. Establish human approval for high-impact decisions.
7. Re-test after model, policy, data, or prompt changes.

Teams writing product requirements can pair prompt work with AI tools for PRD writing and synthesis. For customer-facing writing, use a style guide and approved terminology rather than relying on “sound professional”.

Prompt template to adapt

You are [role] helping [audience] with [task].
Use only [allowed sources].
Context: [relevant facts, location, date, policy].
Input: <input>
Rules:
- [must include]
- [must not do]
- If information is missing, [fallback].
Output format:
- [field 1]
- [field 2]
Quality check: [evidence, calculation, or validation requirement].

The best LLM prompt writing practice is iterative and measurable: define the task precisely, constrain the failure modes, test against real examples, and improve the surrounding system—not just the wording. For Indian founders building AI products, that approach produces more reliable user experiences and a clearer path from prototype to responsible deployment.