Module 2 · Prompt Engineering for Practitioners

Last updated: April 29, 2026

Most “ChatGPT tips” content on LinkedIn is garbage. The real skill isn’t tricks — it’s structured thinking about input, examples, output format, and evaluation. By the end of this module, you’ll prompt like an engineer, not a hobbyist.

The 5 prompt structures that matter

1. Zero-shot

You give an instruction with no examples. Works for tasks the model has clearly seen during training:

Translate to French: "I love security."

Use when: simple, well-known transformations.

2. Few-shot

You include 2-5 input/output example pairs before the actual query. Dramatically boosts performance on classification, structured extraction, custom formats:

Classify CVE severity:

Input: "Remote code execution in Apache, public exploit"
Output: CRITICAL

Input: "Information disclosure on /admin endpoint"
Output: MEDIUM

Input: "Outdated jQuery version"
Output: LOW

Input: "{user_cve}"
Output:

3. Chain-of-thought (CoT)

Tell the model to “think step by step.” Boosts reasoning accuracy on math, logic, and multi-step problems:

Q: A company has 5,000 servers. 12% are misconfigured.
   Of those, 30% expose admin panels. How many servers expose admin panels?
A: Let me think step by step.
   Total servers: 5,000
   Misconfigured: 12% × 5,000 = 600
   Of misconfigured exposing admin: 30% × 600 = 180
   Answer: 180

4. Role + task + format

Set context, define task, specify output format. The professional pattern:

You are a senior cybersecurity analyst writing for a CTO.

Task: Summarise the following CVE in three sentences.

Format:
- Sentence 1: What the vulnerability is
- Sentence 2: What an attacker can do
- Sentence 3: Recommended action

CVE description: {raw_cve_text}

5. Constrained output (JSON mode)

Most modern APIs let you force JSON output that conforms to a schema. This eliminates parsing fragility:

{
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "Extract from CVE..."}],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "cve_triage",
      "schema": {
        "type": "object",
        "properties": {
          "severity": {"type": "string", "enum": ["LOW","MEDIUM","HIGH","CRITICAL"]},
          "affected_systems": {"type": "array", "items": {"type": "string"}},
          "exploit_available": {"type": "boolean"}
        },
        "required": ["severity","affected_systems","exploit_available"]
      }
    }
  }
}

Tool use / Function calling

Modern LLMs can decide when to call your code (search, DB, API) instead of guessing an answer. You define functions; the model decides when to invoke them:

tools = [
  {
    "type": "function",
    "function": {
      "name": "search_internal_docs",
      "description": "Search RingSafe Academy modules by keyword",
      "parameters": {
        "type": "object",
        "properties": {
          "query": {"type": "string"}
        }
      }
    }
  }
]

The model returns: “Call search_internal_docs with query=’SSRF'”. Your code executes and feeds the result back. The model continues from there. This is the foundation of every production AI agent.

Temperature, top-p — the knobs that matter

• Temperature 0: Deterministic. Same input = same output. Use for: data extraction, classification, code generation, anything structured.
• Temperature 0.3-0.5: Slight variability. Use for: customer-facing chat where strict determinism feels robotic.
• Temperature 0.7-1.0: Creative. Use for: brainstorming, marketing copy variants, character generation. Almost never for production.
• Top-p 0.9: Sample only from tokens whose cumulative probability ≥ 0.9. Don’t touch unless you have a specific reason.

Default temperature for most APIs is 1.0. This is wrong for most production use cases. Set it to 0 unless you actively want variation.

The 10 mistakes I see weekly in code review

1. Search-query-style prompts. “Tell me about SSRF” → rambling answer. “You are a security trainer. Explain SSRF in 3 paragraphs targeted at a junior pentester. Cover: what it is, the trust-boundary failure, mitigations.” → useful.
2. No examples in the prompt. If you want a specific output style, show 2-3 examples. Few-shot is free accuracy.
3. Asking the model to be its own grader. “Rate your answer 1-10.” It always gives 8-9. LLMs can’t reliably self-score.
4. No JSON schema. Asking the model to “return JSON” without structured-output mode. It will sometimes return JSON-with-prose-around-it. Your parser breaks.
5. Ignoring the system message. System messages have higher priority than user messages. Set role/rules there, not in user content.
6. Mixing instruction styles. Don’t put both “be friendly” and “be terse” in the same prompt. Pick one.
7. Token bloat. Including 5,000-token system prompts on every call. Cache them via Anthropic prompt caching or OpenAI batching.
8. Not measuring. Shipping a prompt without an eval set is shipping vibes. Build a 20-case golden dataset before production.
9. Treating temperature=1 as default. For data tasks, this introduces silent drift run-to-run. Use 0.
10. Hardcoding prompts in code. Prompts change. Externalise to a YAML/JSON file, version-control them, log which version generated which output.

Eval harnesses — the missing piece

If you can’t measure prompt quality, every change is a guess. The minimum viable eval:

1. Write 20-50 input cases with expected outputs (your “golden dataset”)
2. Run prompt against each, compare with expected
3. Report pass-rate, regression count, average tokens
4. Run before every prompt change

Tools: promptfoo (open source), Braintrust, LangSmith. Even a 50-line Python script using pytest works fine for starting out.

Your project for Module 2

Build a CVE triage prompt that takes raw NVD CVE text and outputs structured JSON:

{
  "severity": "CRITICAL|HIGH|MEDIUM|LOW",
  "affected_systems": ["Apache HTTPD 2.4.x", "..."],
  "exploit_maturity": "in-the-wild|public-poc|theoretical",
  "recommended_mitigation": "Upgrade to 2.4.62 or apply patch X"
}

Test it on 20 real CVEs from the last 30 days (NVD has a free API). Measure: how many produce valid JSON, how many match human triage. Iterate until 18/20 are correct. That’s a real, evaluatable prompt — not vibes.

Summary

• Zero-shot for simple, few-shot for structured, CoT for reasoning, JSON-mode for production parsing.
• Default temperature should be 0 for data tasks.
• Tool use lets the LLM decide when to call your code — foundation of agents.
• System messages set rules; user messages provide content.
• Without an eval set, you’re shipping vibes. Build 20-50 test cases before any production prompt.
• Externalise prompts to versioned files. Treat them like code.