Release Note Stakeholder Approval Workflow Prompt

This prompt is for release managers who need to transform a raw draft into a structured approval package that different reviewers can act on. It assumes you already have a draft release note generated from commits, PRs, or diffs. The prompt produces a review request document with role-specific summaries, risk highlights, and explicit approval criteria. Use this when your release process requires documented sign-off from engineering, product, security, and support before publication.

The prompt structures a single review package that routes to multiple stakeholders simultaneously. Each stakeholder receives a filtered view of the release: engineering sees technical accuracy and deployment risk, product sees feature completeness and user-facing impact, security sees vulnerability disclosures and dependency changes, and support sees known issues and customer communication needs. The output includes per-role approval checkboxes, a consolidated risk register, and a comment incorporation log so you can track feedback across review rounds.

Do not use this prompt to generate the release note itself. Pair it with the Commit Diff to Release Note Prompt Template or Release Note Draft from Merged PRs Prompt Template for the initial draft. This prompt is also not suitable for single-approver workflows where a lightweight review request would suffice. If your release process lacks formal sign-off gates, the structured approval package will add overhead without benefit. For high-risk releases in regulated environments, always require human review of the final approval package before publication.

This prompt template transforms a draft release note into a structured review request tailored to each stakeholder role. It takes your raw draft, the list of reviewers and their responsibilities, and your approval criteria, then produces a review package that each stakeholder can act on without reading irrelevant sections. The template is designed to be copied directly into your application code or prompt management system, with square-bracket placeholders you replace at runtime.

textCopy
You are a release note review coordinator. Your task is to prepare a structured review request from a draft release note, routing the right information to each stakeholder based on their role and approval criteria.

## INPUTS

[DRAFT_RELEASE_NOTE]

[STAKEHOLDER_ROLES]
Format: JSON array of objects with fields:
- role: string (e.g., "Engineering Lead", "Product Manager", "Security Reviewer", "DevRel", "Support Lead")
- responsibilities: string (what this role must verify)
- approval_criteria: string (specific conditions that must be met for this role to approve)
- required: boolean (whether this role's approval blocks the release)

[APPROVAL_WORKFLOW]
Format: JSON object with fields:
- sequential: boolean (whether reviews happen in order or in parallel)
- deadline_hours: number (time window for review completion)
- escalation_contact: string (who to notify if a reviewer is unresponsive)
- signoff_method: string (e.g., "PR comment", "Jira ticket", "Slack thread", "doc comment")

[PREVIOUS_REVIEW_COMMENTS]
Optional. JSON array of objects with fields:
- reviewer: string
- comment: string
- status: "resolved" | "outstanding" | "deferred"
- related_section: string (which part of the release note the comment addresses)

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "review_package": {
    "release_identifier": string,
    "generated_at": string (ISO 8601),
    "summary_for_all_reviewers": string (2-3 sentence overview every reviewer sees),
    "risk_highlights": [
      {
        "risk": string,
        "severity": "critical" | "high" | "medium" | "low",
        "affected_sections": [string],
        "relevant_roles": [string]
      }
    ],
    "role_specific_requests": [
      {
        "role": string,
        "required": boolean,
        "sections_to_review": [string],
        "review_instructions": string,
        "approval_criteria_checklist": [string],
        "questions_to_answer": [string],
        "context_from_other_roles": string (empty if sequential review hasn't reached this role yet)
      }
    ],
    "review_order": [string],
    "outstanding_comments": [
      {
        "reviewer": string,
        "comment": string,
        "status": string,
        "requires_action_from": string
      }
    ],
    "signoff_tracking": {
      "method": string,
      "required_signoffs": [string],
      "received_signoffs": [string],
      "blocking_gaps": [string]
    }
  }
}

## CONSTRAINTS

- Do not fabricate changes, features, or fixes not present in [DRAFT_RELEASE_NOTE].
- If a stakeholder role has no relevant sections, state that explicitly rather than assigning busywork.
- For security-sensitive changes, flag the Security Reviewer role with the specific diff or CVE reference.
- If [PREVIOUS_REVIEW_COMMENTS] contains unresolved items, surface them in the relevant role-specific request.
- Mark any section where the draft is incomplete or unclear with a "needs clarification" flag in the risk highlights.
- Do not assume approval. Every role-specific request must include explicit approval criteria.
- If the approval workflow is sequential, note which roles are blocked waiting for prior signoff.

## EXAMPLE BEHAVIOR

Given a draft release note mentioning a breaking API change and a new OAuth scope, the Engineering Lead should receive the breaking change details and migration impact. The Security Reviewer should receive the OAuth scope change with a request to verify least-privilege compliance. The Product Manager should receive the user-facing feature description and upgrade guidance. The Support Lead should receive known issues and customer communication templates.

To adapt this template, replace each square-bracket placeholder at runtime before sending the prompt to the model. The [DRAFT_RELEASE_NOTE] should contain the full text of your draft. The [STAKEHOLDER_ROLES] array defines who reviews what—update this per release based on which teams are affected. The [APPROVAL_WORKFLOW] object controls whether reviews happen in parallel or sequentially; set sequential: true when later reviewers need context from earlier signoffs. The [PREVIOUS_REVIEW_COMMENTS] array is optional but critical for multi-round reviews, as it ensures unresolved feedback follows the draft into the next review cycle. After receiving the model output, validate the JSON structure against the schema before routing role-specific requests to each stakeholder. If the model produces a blocking_gaps array with entries, halt the release process until those gaps are resolved.

This prompt is designed to sit between draft release note generation and final publication. It takes a completed draft, a list of stakeholders, and their review criteria, then produces a structured review request that each stakeholder can act on. The implementation harness must handle input assembly, stakeholder routing, response collection, and sign-off tracking—not just a single model call.

Input assembly starts by gathering the draft release note, the source change artifacts (commit diffs, PR summaries, schema diffs), and a stakeholder map. The stakeholder map defines each reviewer's role, review criteria, and approval weight. Feed these into the prompt as structured context: [DRAFT] contains the full release note text, [CHANGE_ARTIFACTS] contains the grounded evidence, and [STAKEHOLDER_MAP] lists each reviewer with their role, review_focus, and approval_required boolean. The model should never invent stakeholder criteria—always ground them in the map you provide. Model choice matters: use a model with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may collapse multiple stakeholder reviews into a single undifferentiated block.

Output validation is critical because this prompt generates review requests that real people will act on. Validate that every stakeholder in the input map appears in the output with a distinct review section. Check that each section includes the required fields: change_summary, risk_highlights, approval_criteria, and review_deadline. Reject outputs that merge stakeholders or omit approval criteria. For high-risk releases (security advisories, breaking changes, data migrations), add a human-in-the-loop gate: the generated review request must be checked by the release manager before distribution. Log the raw prompt, the model response, and the validation result for auditability.

Routing and response collection happens outside the prompt but must be designed alongside it. Each stakeholder review section should be extractable as a standalone message (email, Slack, ticket) with a unique review_id. When stakeholders submit feedback, their responses must be mapped back to the original review request. Build a response schema that captures review_id, stakeholder_role, decision (approved/rejected/changes_requested), comments, and timestamp. For sign-off tracking, maintain a state machine: draft → review_requested → in_review → approved/rejected/changes_requested. The prompt's output should include clear instructions for stakeholders on how to submit their decision, reducing ambiguity in the collection pipeline.

Retry and repair logic applies when validation fails. If the output is missing a stakeholder section, retry with a more explicit instruction appended to the prompt: 'Ensure every stakeholder in [STAKEHOLDER_MAP] has a separate review section with all required fields.' If the output hallucinates changes not present in [CHANGE_ARTIFACTS], do not retry blindly—flag for human review and check whether the source artifacts were complete. Escalation paths: if a stakeholder rejects the release note, route the rejection reason and comments back to the draft author with a structured revision request. If a stakeholder fails to respond by the deadline, trigger a reminder workflow. The prompt itself doesn't handle these escalations, but the harness must.

What to avoid: don't use this prompt as a fire-and-forget approval system. It generates review requests, not approvals. Never treat model-generated approval criteria as actual stakeholder sign-off. Don't skip validation just because the output looks plausible—structured review requests with missing stakeholders or hallucinated risks will erode trust in the entire release process. Start with a dry run on a low-risk release, validate every output field, and build the routing and tracking harness before scaling to production releases.