Describe the process you follow when starting a new prompt engineering project.

I start from the outcome, not the prompt: understand the task and its users, define how success will be measured, collect real test cases, then write a simple first prompt and improve it in measured steps before building it into the product with monitoring.

1. Understand the problem

• What job does the output do, for whom, and what happens when it is wrong? A typo-fixer and a medical triage assistant need very different care.
• What inputs will arrive, in what volume, and from whom (trusted staff or the public)?
• Is a language model the right tool? Some tasks are better done by rules, search or a database query.

2. Define success criteria Measurable targets: accuracy on a labelled set, required fields present, format valid, latency and cost limits, safety requirements. Agree them with the people who own the outcome.

3. Gather data and examples

• Real or realistic inputs, including messy and edge cases.
• Expected outputs written or approved by domain experts.
• Adversarial cases: attempts to break rules, inject instructions or extract data. Split them into examples that may go into the prompt and a separate test set.

4. Choose the model and setup Start with a capable model to learn what's possible, then try smaller, cheaper ones once you have tests that show whether quality holds. Decide whether retrieval, tools or structured outputs are needed.

5. Write a simple baseline prompt Clear task, context, output format. Run it on the test set and record the scores. Avoid adding techniques before you know what fails.

6. Analyse failures and iterate Read the failures and group them: missing information, misunderstood instruction, format errors, invented facts. Fix the cause: add context, clarify an instruction, add a targeted example, split the task into steps. Change one thing at a time, re-run all tests, and keep a versioned history of prompts and scores.

7. Review with stakeholders Domain experts review samples of outputs, especially borderline ones; their feedback often reveals criteria that weren't written down.

8. Harden for production

• Templates with variables instead of string concatenation.
• Defences against prompt injection, input limits, output validation, fallbacks for errors and timeouts.
• Prompt caching for long, stable prefixes to cut cost and latency.
• Pin the model version.

9. Launch and monitor Log inputs, outputs, cost and latency (respecting privacy), collect user feedback, sample outputs for review, and turn new failures into test cases.

10. Maintain Re-run the evaluation before any model upgrade or prompt change, and revisit the prompt when the product or its users change. Document what each part of the prompt is for, so the next person knows what is safe to change.