A prompt engineering lifecycle treats a prompt as a maintained engineering artifact, not a one-time instruction. The working loop is design, test, iterate, and manage: produce a draft, gather evidence against acceptance criteria, revise observed failures, and preserve ownership and change history. These activities repeat rather than follow a one-way sequence. section 1.1 section 1.7
For a prompt used in a system, carry that loop through seven operational phases:
- Draft and test: specify the task, context, constraints, input boundaries, and expected output; then check responses against defined criteria. section 1.1 section 11.8
- Approve and deploy: review the tested version before putting it into use. section 11.8
- Observe and improve: use test results, user feedback, and production regressions to identify the next change. Send each improvement back through draft, test, approval, and promotion; do not edit the live prompt directly. section 11.3.8
- Retire: end the lifecycle when the prompt is no longer maintained for use. section 11.8
Incident-severity prompt
Suppose a prompt classifies incident reports by severity. Its acceptance criteria include classifying database timeouts as critical regardless of report language. A test set of 20 reports exposes failures; a targeted revision fixes the criterion, and a rerun classifies all 20 correctly. The final version enters a prompt library with a changelog, test-set note, and rationale. When a new severity tier arrives months later, that record supports a focused update instead of a rewrite. section 1.5
For a significant rewrite, branch a separate version and test it without risking the current production prompt. For a high-traffic behavior change, compare it on a fraction of traffic before full promotion. The lifecycle works with config files as well as more mature prompt-management tools; it does not require a particular deployment or telemetry stack. section 11.3.8 section 11.3 section 11.7
