Prompt Engineering Best Practices

Invoke when creating, reviewing, or improving prompts for LLMs. Ensures consistency, accuracy, and reliability across all prompt types.

The Six Pillars

1. Role Prompting

Define who the model is and what expertise it brings.

Template

You are a [role] with [X] years of experience in [domain].
Your specialty is [specific area].
You communicate in [tone] and prioritize [values].

Good

You are a senior QA automation engineer with 8 years of experience in web and mobile testing.
Your specialty is designing maintainable test frameworks with Playwright and Appium.
You communicate directly and prioritize test reliability over coverage quantity.

Bad

You are a QA engineer.

Anti-Patterns

2. Context & Constraints

Provide the model with boundaries before the task.

## Context
- Tech stack: Python 3.11, FastAPI, PostgreSQL, pytest
- Team size: 5 developers, 1 QA
- CI/CD: GitHub Actions with 10-minute timeout

## Constraints
- Max 50 lines per function
- Use `async`/`await` for I/O
- No external dependencies beyond `requirements.txt`

3. Chain-of-Thought (CoT)

For reasoning tasks, instruct the model to think step by step before answering.

Zero-Shot CoT

Before answering, think step by step:
1. Identify the problem type
2. Break it into sub-problems
3. Solve each sub-problem
4. Verify the solution against constraints
5. Provide the final answer

Few-Shot CoT

Q: A store has 15 apples. They sell 7, then receive 12 more. How many apples?
Let's think step by step.
Step 1: Start with 15 apples.
Step 2: Subtract 7 sold: 15 - 7 = 8.
Step 3: Add 12 received: 8 + 12 = 20.
Answer: 20 apples.

Q: A test suite has 120 tests. 30% are flaky. After fixing 60% of flaky tests, how many flaky remain?
Let's think step by step.

4. Few-Shot Prompting

Provide input/output pairs to teach the model the desired format.

Template

## Example 1
Input: [user input]
Output:

[desired output]

## Example 2
Input: [user input]
Output:

[desired output]

## Task
Input: [actual user input]
Output:

Few-Shot with Reasoning

## Example 1 — Test Case Generation
Requirement: "Users can log in with email and password."
Reasoning: This is a happy-path authentication test. Need valid credentials, login action, and dashboard assertion.
Output:
| ID | Scenario | Steps | Expected |
|----|----------|-------|----------|
| TC-01 | Valid login | 1. Enter email 2. Enter password 3. Click Login | Dashboard loads |

## Example 2 — Edge Case
Requirement: "Users can log in with email and password."
Reasoning: This tests the boundary of empty password field, which should trigger validation before API call.
Output:
| ID | Scenario | Steps | Expected |
|----|----------|-------|----------|
| TC-02 | Empty password | 1. Enter email 2. Leave password blank 3. Click Login | Inline validation error "Password is required" |

5. Self-Consistency

Generate multiple reasoning paths and select the most consistent answer.

Generate 3 independent answers to this question.
For each answer, show your reasoning.
Then vote: which answer appears most frequently and is best supported?
Provide the consensus answer as the final output.

6. Output Structuring

Use delimiters, schemas, and formats to guarantee consistent output.

## Output Format
Respond ONLY in the following markdown structure:

### Analysis
[Brief analysis in 1-2 sentences]

### Recommendation
[Clear recommendation]

### Rationale
[3 bullet points max]

### Confidence
[High / Medium / Low] with brief justification

JSON Mode

Respond with valid JSON only, no markdown, no explanations:
{
  "test_cases": [
    {
      "id": "string",
      "scenario": "string",
      "steps": ["string"],
      "expected": "string",
      "priority": "High|Medium|Low"
    }
  ],
  "risks": ["string"],
  "automation_candidates": ["string"]
}

Prompt Quality Checklist

• Role is specific (not generic "assistant")
• Context and constraints are explicit
• Task is broken into clear steps (CoT for complex tasks)
• Few-shot examples cover happy path + edge cases
• Output format is defined with delimiters
• Anti-patterns or "what NOT to do" are stated
• Length is under 1000 lines (prefer 300-500)
• No ambiguous terms ("good", "best", "appropriate")

Common Anti-Patterns