Technical Documentation RAG Answer Prompt

This prompt is designed for developer-facing documentation Q&A systems. Use it when you need an LLM to answer user questions by synthesizing information strictly from retrieved technical documents like API references, SDK guides, and changelogs. The prompt instructs the model to produce version-aware answers, include code snippets grounded in the source, flag deprecated features, and explicitly state the platform or version scope of its answer. It is ideal for product, engineering, and DevOps teams integrating a Q&A copilot into a developer portal, CLI tool, or internal knowledge base.

The prompt requires a RAG pipeline that retrieves relevant chunks from a curated documentation corpus. The model is instructed to refuse to answer if the provided context is insufficient, rather than hallucinating an API method or configuration parameter. This makes it suitable for high-stakes developer surfaces where a wrong code example or outdated endpoint can break a user's production system. The prompt also enforces a structured output format, making it easy to parse the answer, code blocks, and source citations for rendering in a UI or returning via an API.

Do not use this prompt for general-purpose coding assistance, conversational chat without retrieved context, or legal/medical/financial document Q&A. It is not designed to reason over multiple conflicting sources or to provide architectural advice beyond what is explicitly stated in the documentation. If your use case involves answering questions from a mix of internal wikis, code repositories, and live system logs, you will need a more sophisticated multi-source RAG architecture with conflict resolution and evidence ranking before this prompt can be applied safely.

This prompt template is designed for developer-facing Q&A systems that answer questions from technical documentation. It enforces version-scoped answers, requires inline source citations, and explicitly checks for deprecated or stale content. Replace every square-bracket placeholder with values supplied by your application at runtime. The prompt assumes retrieved chunks are already deduplicated and ranked before insertion into [CONTEXT].

textCopy
You are a technical documentation assistant. Your job is to answer developer questions using ONLY the provided documentation context. You must not use your own knowledge of APIs, libraries, or versions unless explicitly confirmed by the context.

## CONTEXT
[CONTEXT]

## QUESTION
[INPUT]

## CONSTRAINTS
- Answer ONLY from the provided context. If the context does not contain enough information to answer, state that clearly and do not guess.
- Every factual claim must include an inline citation in the format `[source: chunk_id]` where chunk_id matches the `[chunk_id]` marker in the context.
- If the context includes version or platform information, scope your answer to that version and platform. Do not generalize across versions.
- If the context contains deprecation notices, breaking-change warnings, or end-of-life dates, surface them prominently at the start of the answer.
- Code examples must be copied verbatim from the context when available. If you adapt an example, mark it as adapted and explain the change.
- If multiple context chunks conflict (e.g., different versions, contradictory statements), describe the conflict rather than choosing one side silently.
- Do not fabricate parameter names, endpoint paths, error codes, or configuration keys that are not present in the context.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "answer": "string (the full answer with inline citations)",
  "version_scope": "string or null (the version or version range this answer applies to)",
  "deprecation_warnings": ["string (any deprecation or breaking-change notices found)"],
  "confidence": "high|medium|low (based on context completeness and consistency)",
  "missing_information": ["string (topics the question raised but the context did not cover)"],
  "source_chunks_used": ["chunk_id (list of chunk IDs actually cited in the answer)"]
}

To adapt this prompt, replace [CONTEXT] with your retrieved and ranked documentation chunks, each prefixed with a unique [chunk_id] marker. Replace [INPUT] with the user's question. If your documentation system tracks version metadata, inject it into the context preamble so the model can scope its answer. For high-stakes deployments, add a [RISK_LEVEL] field that triggers additional refusal behavior when the context is thin or contradictory. Wire the JSON output into a post-processing validator that checks every chunk_id in source_chunks_used against the actual retrieved set to catch hallucinated citations before the answer reaches the user.

The Technical Documentation RAG Answer Prompt is designed to be the final synthesis step in a retrieval-augmented generation pipeline. In production, the prompt should never receive raw user input directly. Instead, the application layer must first handle query rewriting, retrieval, and evidence ranking before assembling the prompt with the [RETRIEVED_CHUNKS], [USER_QUESTION], [DOCUMENTATION_VERSION], and [PLATFORM_SCOPE] placeholders populated. The model choice matters here: use a model with strong instruction-following and long-context handling (such as Claude 3.5 Sonnet or GPT-4o) because the prompt requires the model to track version metadata, enforce quote limits, and abstain when evidence is insufficient—all while synthesizing code snippets and API references accurately.

Validation must happen at two layers. First, validate the model's raw output against the expected schema before it reaches the user. At minimum, check that the answer field is present and non-empty, that any code_snippets are syntactically valid for the target language (run a parser, not a regex), and that every citation object contains a non-null source_url, section_reference, and version_tag. Second, run a post-generation factual verification step: extract each factual claim from the answer, match it against the retrieved chunks, and flag any unsupported statement. For high-stakes documentation (security advisories, breaking-change notices, deprecation timelines), route flagged outputs to a human review queue before publishing. Log every prompt version, model version, retrieval set hash, and validation result for auditability.

Retry logic should be conservative. If the output fails schema validation, retry once with the same prompt plus the validation error message appended as a [REPAIR_INSTRUCTION]. If the model abstains (returns answerable: false), do not retry—instead, surface the abstention_reason and suggested_retrieval_queries to the user or trigger a secondary retrieval pass with expanded queries. Common failure modes include the model ignoring version constraints and recommending deprecated APIs, synthesizing code that mixes incompatible versions, or fabricating parameter names not present in the retrieved chunks. Mitigate these by including explicit negative examples in the prompt's [EXAMPLES] section showing deprecated API handling and version-mismatch rejections. Wire the prompt into your application with a timeout of 30-60 seconds given the long context, and cache the prompt prefix (system instructions and static portions) to reduce latency and cost on repeated calls.