Checklist Generation Prompt from Retrieved Context

This prompt is designed for operations, compliance, and engineering teams who need to convert dense procedural documents into actionable, verifiable checklists. It takes retrieved context from standard operating procedures, runbooks, or policy documents and produces a structured checklist where every item is atomic, testable, and traceable to a source passage. Use this when downstream systems or human reviewers require clear acceptance criteria and evidence grounding for each checklist step.

The ideal input is a set of retrieved passages that contain explicit procedural instructions—numbered steps, conditional logic, or mandatory actions. The prompt works best when the source material describes a repeatable process with clear success and failure states. For example, a cloud operations runbook for database failover, a compliance team's evidence collection procedure, or a manufacturing line's quality control steps are all strong candidates. The prompt expects a [CONTEXT] variable containing the retrieved passages and an optional [OUTPUT_SCHEMA] to enforce a specific JSON structure for integration with ticketing systems or automated execution engines.

Do not use this prompt for creative brainstorming lists, subjective quality rubrics, or tasks where the source material lacks explicit procedural instructions. If your documents contain only general guidance, aspirational policies, or narrative descriptions without discrete actions, the model will hallucinate checklist items that sound plausible but cannot be traced to source evidence. In those cases, consider a structured extraction prompt instead. For high-stakes domains like healthcare or aviation, always route the generated checklist through a human reviewer and run the output through an eval that checks item atomicity, source grounding, and false positive rate before any item reaches a production system.

This template is the core instruction set for generating a checklist from a set of retrieved documents. It is designed to be used within a RAG system where the [CONTEXT] placeholder is populated by your retrieval step. The prompt forces the model to act as a strict analyst, extracting only actionable items that are explicitly supported by the provided text. It requires each item to have a clear acceptance criterion and a direct source quote, making the output auditable and ready for operational use.

codeCopy
You are a precise technical analyst. Your task is to generate a verifiable, actionable checklist from the provided context only.

Generate a checklist based on the following rules:
- Each item must be a single, atomic action or verification step.
- Each item must include a binary, verifiable 'Acceptance Criteria'.
- Each item must include a direct quote from the [CONTEXT] as 'Source Evidence'. If no evidence exists, do not create the item.
- Group items under logical 'Phase' headings (e.g., Pre-flight Checks, Execution, Validation).
- Do not infer, assume, or add steps not explicitly mentioned in the context.
- If the context is insufficient to generate any checklist items, state 'No verifiable checklist items could be generated from the provided context.'

[CONTEXT]:

Adaptation Notes:

• [CONTEXT]: Replace this with the raw text retrieved from your vector store, knowledge base, or search index. Ensure the context is pre-processed to remove irrelevant chunks before insertion.
• Domain Tuning: For regulated industries, add a [CONSTRAINTS] block specifying regulatory standards (e.g., "All steps must align with SOC 2 Type II controls") or a [RISK_LEVEL] flag to trigger mandatory human review language in the output.
• Output Schema: For direct API consumption, append an [OUTPUT_SCHEMA] block with a strict JSON schema to replace the default markdown structure. This ensures the checklist can be parsed by downstream automation tools.

Before integrating this prompt into production, run it against a golden dataset of procedures and their known correct checklists. Evaluate the output for item atomicity (one action per item), completeness (are all source steps covered?), and false positives (are any items hallucinated?). A common failure mode is the model merging two distinct steps into one checklist item; your eval should flag this. Always log the prompt version, the retrieved context, and the generated checklist for traceability and debugging.

This prompt is designed to be called as part of a RAG pipeline where source documents have already been retrieved and chunked. The application layer should assemble the [CONTEXT] placeholder by concatenating the top-k retrieved passages with their source identifiers, then inject the [DOMAIN] and [PURPOSE] variables from the user's request or a configuration object. Do not pass raw, unranked retrieval results directly—pre-filter for relevance and deduplicate overlapping chunks before populating the context window. The prompt expects each source passage to be prefixed with a unique reference ID (e.g., [DOC-3]) that will be used in the output citations.

After the model returns a response, parse the output against the expected schema: an array of checklist items, each with item, acceptance_criteria, source_refs, and confidence fields. Implement a validation layer that checks for item atomicity (each item must describe a single verifiable action), source grounding (every source_refs entry must match a reference ID present in the input context), and completeness (the checklist should cover all major procedural steps mentioned in the source material). If validation fails, use a retry loop with a maximum of two additional attempts, appending the specific validation errors to the prompt as [PREVIOUS_ERRORS] so the model can self-correct. Log all validation failures and retries for observability.

For high-stakes domains like compliance, clinical, or safety procedures, route the generated checklist to a human review queue before it reaches end users. The review interface should display each checklist item alongside its source citations and the original context passages, allowing a reviewer to confirm, edit, or reject items. Track reviewer actions to build a feedback dataset for future prompt improvements. Avoid using this prompt for open-ended brainstorming where no source documents exist—it will hallucinate plausible-sounding but ungrounded checklist items. For those cases, use a different workflow that explicitly labels output as speculative rather than evidence-backed.