awesomechecklists
llms.txtGitHub ↗
/

15 — Prompt Engineering and Versioning Checklist#

Review instructions, templates, prompt revisions, and evaluation gates used in model-integrated software. Treat prompt wording as a behavioral control and engineering artifact, not a guarantee of security or deterministic correctness. Protect trust boundaries and external actions with independent code-level authorization.

Scope: Frontend-specific. This file is one part of the 15_Prompt_Engineering_and_Versioning.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Scope and applicable jurisdictions / markets:
  • Prompt purpose / workflow / output contract:
  • Model / provider / snapshot / prompt revision:
  • Safety, evaluation, and release owners:
  • Reviewer / owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Copy this shared template into project-specific review records; leave the repository's checkboxes unchecked.
  2. Mark [x] only after checking versioned source, actual rendered messages, execution-boundary controls, reproducible evaluation results, deployment evidence, or an accountable risk decision. Keep failed checks, N/A reasons, and exceptions in project-specific notes/issues keyed by PROMPT ID, not in an evidence table here.
  3. Choose prompt strategies based on the target model and its current API. Clear role separation, examples, and formatting may improve output consistency but do not guarantee safety, confidentiality, or obedience.
  4. Review ## API Checks and ## Frontend Checks separately if those surfaces exist; document inapplicability outside the shared template.
  5. Re-run relevant evaluations when prompt text, model revision, retrieval, tools, parsing, policy, traffic, or user interface changes. Detailed RAG, agent orchestration, adversarial red-teaming, evaluation regression, and model-monitoring checks belong in the relevant dedicated AI domain checklists.

Frontend Checks#

  • PROMPT-113 Confirm user-facing descriptions accurately reflect what the current prompt-supported feature can and cannot do.
  • PROMPT-114 Show uncertainty, requests for missing context, and refusals clearly without implying the AI verified unsupported facts.
  • PROMPT-115 Distinguish model-generated content from user-authored text, authoritative source excerpts, and confirmed system actions.
  • PROMPT-116 Provide an accessible way to correct input, refine a request, retry, or escalate when prompt behavior is inadequate.
  • PROMPT-117 Ensure suggested prompts and examples do not imply capabilities or authorizations absent from the deployed API.
  • PROMPT-118 Check multilingual and localized prompt suggestions against supported model behavior and policy restrictions.
  • PROMPT-119 Test long, malformed, and mixed-script inputs against actual template and context size limits.
  • PROMPT-120 Provide understandable error or warning states when the input exceeds supported length or attachments are not processed.
  • PROMPT-121 Keep streaming content and intermediate drafts distinguishable from final verified actions or completed results.
  • PROMPT-122 Validate output formatting for lists, code, tables, citations, JSON-derived UI, and unexpected model responses.
  • PROMPT-123 Render generated markup safely and avoid allowing responses to inject executable HTML or scripts.
  • PROMPT-124 Confirm high-impact action previews and confirmation steps cannot be bypassed through prompt wording.
  • PROMPT-125 Ensure user-specific draft content and history are isolated across account switches, sessions, and browser storage.
  • PROMPT-126 Do not display internal prompt instructions, model credentials, or confidential debugging metadata in the client.
  • PROMPT-127 Test screen-reader announcements, keyboard interaction, and focus behavior for streaming answers and clarifications.
  • PROMPT-128 Check how UI behaves if a prompt revision changes tone, length, response structure, or allowed requests.
  • PROMPT-129 Validate that frontend feature flags map to approved server-side prompt versions and support safe rollback.
  • PROMPT-130 Collect appropriately consented feedback with prompt revision context without logging sensitive full user input unnecessarily.
  • PROMPT-131 Test user journeys with prompt-triggered refusals, model errors, timeouts, and tool failures on representative devices.
  • PROMPT-132 Confirm post-release UI monitoring can identify prompt-version-specific regressions and harmful user experiences.

Release gate#

  • The production prompt's intended task, trusted instructions, allowed inputs, output contract, limits, and accountable owners are documented.
  • Prompt templates safely handle variable inputs and untrusted content; model-generated tool calls are checked by independent permissions and schema validators.
  • A reviewed, identifiable prompt revision is tied to an approved model/configuration snapshot, relevant schemas, and the release artifact.
  • Representative held-out and adversarial evaluations meet predefined task-quality, policy, and format thresholds, with severe failures documented.
  • The new prompt is compared against the currently approved baseline for critical regressions, false refusals, task completion, latency, and resource cost.
  • API and frontend integration tests cover prompt-version-specific behavior, unsafe output handling, and useful recovery states where applicable.
  • Rollout, monitoring, incident escalation, prompt rollback, and documented change authorization are ready for the intended release.
  • Material residual privacy, security, quality, or user-harm risks have explicit owner, mitigation, retest deadline, and authorized release disposition.

Domain-specific approval rule: Block release when a prompt change can bypass required authorization, misroute sensitive content, break critical output contracts, or introduce significant unaccepted quality or safety regressions. No amount of instruction wording substitutes for enforced permission boundaries, input/output validation, or meaningful evaluation.

Trusted references and scope#

These primary or authoritative sources inform the verification checks. Apply vendor-specific suggestions only to models and platforms where they have been tested; they are not universal guarantees of reliable or safe model behavior.

Applicability: OpenAI's November 2026 prompt guidance prefers reviewed, code-managed prompts and notes deprecation of its reusable prompt-object API; check the official migration and deadline before relying on that feature. Prompt advice differs by model generation and vendor. OWASP string delimiters and text filters are defense-in-depth, not prompt-injection prevention guarantees. Use controlled benign and adversarial tests and code-enforced tool permission checks. This file does not replace governance, model selection, RAG, AI red-team, or full regression-evaluation reviews.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: prompt versions, formatting, instructions, refusals, and injection resistance; include browser and client behavior where applicable.
  • Cross-stack: promptfoo.
  • Python: DeepEval + pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: promptfoo + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: promptfoo + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.