PR Description to Release Note Extraction Prompt Template

This prompt is designed for technical writers and engineering leads who need to convert raw pull request descriptions into polished, user-facing release notes. The core job is to translate developer-centric technical prose into structured summaries that categorize changes by impact, link to relevant issues, and distinguish breaking changes from additive features. You should use this prompt when you have a completed, merged PR with a non-trivial description and need a consistent, review-ready release note entry that can be published in a changelog or release announcement.

The ideal workflow assumes you have access to the full PR body, the PR title, linked issue references, and merge metadata such as the target branch and associated milestone. The prompt works best when the PR description follows a template that includes a motivation section, a description of changes, and a testing plan. Do not use this prompt for PRs that are still in draft, contain only trivial changes like typo fixes, or lack sufficient context to determine user impact. It is also not a replacement for a full changelog aggregation pipeline; it produces one entry at a time and should be paired with deduplication and categorization logic when processing multiple PRs for a single release.

Before integrating this prompt into a production pipeline, define your output schema and evaluation criteria. The prompt should produce a structured object with fields for the change category, a user-facing summary, any migration or upgrade notes, and linked issues. High-risk workflows—such as release notes for security patches or database migrations—require human review of the extracted entry before publication. Validate that the output correctly classifies breaking changes, does not omit referenced issues, and preserves the intended tone for your audience. Start by running the prompt against a golden set of PRs with known-good release notes to calibrate your eval thresholds.

This prompt template is designed to be copied directly into your AI harness, whether you're using an API call, a prompt management platform, or a local evaluation runner. It takes a raw pull request description as its primary input and produces a structured release note entry suitable for publication in a changelog or release announcement. The template uses square-bracket placeholders for all dynamic components—input text, output format requirements, behavioral constraints, and few-shot examples—so you can adapt it without rewriting the core instruction logic.

textCopy
You are a technical writer converting pull request descriptions into structured, user-facing release notes.

## INPUT
[PR_DESCRIPTION]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
- "summary": A one-sentence summary of the change for end users.
- "impact": One of "breaking", "feature", "fix", "improvement", "deprecation", or "security".
- "affected_components": An array of strings naming the services, APIs, or modules affected.
- "migration_notes": A string with migration steps if the change is breaking or deprecating; otherwise null.
- "linked_issues": An array of issue or ticket references found in the description.
- "contributors": An array of contributor names or handles extracted from the description.
- "confidence": One of "high", "medium", or "low" indicating how clearly the description maps to the output.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Classify the change impact based on the description's language, not the PR title alone.
2. If the description mentions breaking changes, deprecations, or migration steps, set "impact" accordingly and populate "migration_notes".
3. Extract all referenced issue numbers, ticket IDs, or links into "linked_issues".
4. Extract contributor names from "Co-authored-by" lines, @mentions, or explicit credit sections.
5. If the description is vague, contradictory, or missing key details, set "confidence" to "low" and note what's missing in a "review_notes" field.
6. Do not invent details not present in the PR description.

To adapt this template for your workflow, replace each placeholder with concrete values. For [PR_DESCRIPTION], inject the raw markdown or plain text of the pull request body. For [CONSTRAINTS], add domain-specific rules such as character limits, forbidden terms, or required regulatory language. For [EXAMPLES], provide 2–4 few-shot demonstrations showing a PR description paired with the expected JSON output. This is especially important for calibrating the impact classification and confidence scoring to match your team's conventions. If your release process requires additional fields—such as release_version, backport_targets, or QA_signoff—extend the output schema rather than relying on the model to infer them. Always validate the output against your schema before publishing, and route low-confidence results for human review.

This prompt is designed to run as a post-merge step in a CI/CD pipeline or as part of a release management bot. The primary input is the raw PR description body, which you should extract from your source control API (GitHub, GitLab, Bitbucket) along with merge metadata: PR number, author, merged timestamp, target branch, and associated issue references. Do not pass the entire PR object—strip it down to the description text and a structured [CONTEXT] block containing the metadata fields the prompt expects. This keeps the prompt focused and reduces token waste.

Wire the prompt into an application harness that handles the full lifecycle. First, validate the input: ensure the PR description is non-empty and meets a minimum length threshold (e.g., 50 characters) before calling the model. After receiving the model's JSON output, run a schema validator against your expected [OUTPUT_SCHEMA] to catch missing required fields, malformed enums (like impact values outside the allowed set), or empty release note summaries. If validation fails, implement a single retry with the validation error message appended to the prompt as additional [CONSTRAINTS]—do not retry more than once without human intervention. Log every prompt version, input hash, raw output, and validation result for auditability. For high-severity releases or regulated environments, route the extracted release note to a human review queue before publication, and include the PR link and diff in the review payload so the reviewer can verify accuracy against the actual code change.

Choose a model with strong JSON mode and instruction-following capabilities. This prompt benefits from low temperature settings (0.1–0.3) to produce consistent, deterministic output. If your release notes require cross-referencing with an internal knowledge base—for example, to link to existing migration guides or known issue trackers—add a retrieval step before the prompt call and inject the retrieved context into the [CONTEXT] block. Do not use this prompt for PRs labeled no-release-note or internal-only; filter those out in the harness before invocation. The most common production failure mode is the model summarizing implementation details instead of user-facing impact—mitigate this by including a strong negative example in [EXAMPLES] showing an implementation-heavy summary being rejected.