Prompt engineering is the deliberate composition, evaluation, and refinement of prompts for reliable, predictable language-model outputs. Unlike casual prompting, it treats a prompt as a shared interface: instructions, context, constraints, inputs, and output requirements are specified so others can review, test, and maintain them. It changes the text at the model interface, not the model’s weights or training data. section 1.2 section 1.7
A reusable prompt makes its contract explicit:
- Task: state what the model must do and who will use the result. section 1.3
- Context and inputs: supply the facts needed for the task and mark what constitutes the input. section 1.7
- Constraints and output: specify limits, required content, and a format that can be checked against acceptance criteria. section 1.3 section 1.2
Pull-request orientation prompt
Task: Summarize the pull request for reviewers before they read the diff. Input: Authentication middleware now delegates session validation to a new SessionValidator class instead of parsing sessions itself. Constraints: Use only the supplied change description; do not infer test results or effects not stated. Output: A short change summary followed by a list of points reviewers should verify. Check the result for accurate scope, the requested format, and unsupported claims. This contract is more reviewable than “Summarize this pull request.” section 1.2 section 1.3
Work in a cycle: draft the contract, test it on representative inputs, compare outputs with acceptance criteria, revise observed failures, and preserve the prompt’s owner and change history. Diagnose vague or unusable output against the task, supplied facts, constraints, and output shape before changing wording at random. Precision costs some up-front effort but can reduce downstream editing; an API migration notice, for example, needs operational facts and required actions rather than a merely plausible generic summary. section 1.7 section 3.1.1 section 3.4.2
