Release Communication Architecture Prompt

This prompt is for release coordinators, platform engineers, and SREs who are designing or reviewing a stakeholder notification system. Use it when you are defining who gets notified, what triggers a notification, how change logs are assembled, and how freeze periods are communicated. The prompt produces a structured architecture review that identifies alert fatigue risks, missing escalation paths, and audience segmentation gaps. It is a design review tool, not an operational playbook.

Before using this prompt, you need a clear picture of your release pipeline stages, the stakeholder groups affected by each stage, and the communication channels available (email, Slack, status pages, webhooks). The prompt works best when you provide concrete details about notification triggers, such as 'deployment started in staging,' 'canary promotion approved,' or 'rollback initiated.' Vague inputs like 'notify the team when something happens' will produce vague reviews. The prompt expects you to define [AUDIENCE_SEGMENTS], [NOTIFICATION_TRIGGERS], [COMMUNICATION_CHANNELS], and [FREEZE_POLICIES] as structured inputs. If you cannot articulate these, the review will surface that gap as a finding rather than producing a useful architecture.

Do not use this prompt for incident response runbooks or real-time alerting configuration. It will not help you configure PagerDuty, write Prometheus alert rules, or design on-call schedules. Do not use it to draft the actual notification messages—it reviews the system design, not the copy. If you need message templates, use a content-generation prompt instead. This prompt also assumes a single release pipeline; if you are coordinating across multiple independent services with separate release cadences, you should run the review once per pipeline or explicitly model the cross-pipeline dependencies in your inputs.

After running this prompt, you should have a list of architectural risks ranked by severity, concrete recommendations for audience segmentation, and a gap analysis of your notification coverage. The next step is to take the highest-severity findings and address them in your notification system design before the next release cycle. If the review surfaces fundamental disagreements about who owns communication or what constitutes a critical notification, escalate those decisions to your release management governance process before attempting to automate.

The prompt below is designed to act as a structured review partner for a release communication architecture. It forces the model to evaluate the design against specific criteria—alert fatigue, missing escalation paths, and change log automation—rather than producing a generic summary. Before using it, gather your architecture diagram, stakeholder list, notification channel inventory, and any existing runbooks. The prompt expects these as context.

textCopy
You are a senior site reliability engineer and incident communications specialist. Your task is to review a proposed release communication architecture for gaps, risks, and anti-patterns.

## INPUTS
[ARCHITECTURE_DESCRIPTION]
[STAKEHOLDER_MAP]
[NOTIFICATION_CHANNELS]
[EXISTING_RUNBOOKS]

## REVIEW CRITERIA
1. **Notification Triggers**: Are triggers clearly defined for each release phase (pre-release, canary start, full rollout, rollback, freeze)? Identify any missing triggers or ambiguous conditions.
2. **Audience Segmentation**: Is the stakeholder map segmented by need-to-know (e.g., on-call engineers, product managers, support, executives)? Flag any group that receives too much or too little information.
3. **Change Log Automation**: Is the change log generated automatically from the VCS or issue tracker? If manual, note the risk of human error and staleness.
4. **Freeze Communication Templates**: Are there pre-approved templates for deployment freezes, exceptions, and freeze lifts? Check for missing approval fields or unclear effective dates.
5. **Alert Fatigue Analysis**: Estimate the notification volume for a typical release week. Identify any channel that would generate more than [ALERT_THRESHOLD] messages per on-call engineer per day.
6. **Escalation Paths**: For each notification type, verify that an escalation path exists if no acknowledgment is received within [ACK_TIMEOUT] minutes. Flag any dead-end alerts.
7. **Audit Trail**: Confirm that all stakeholder notifications are logged with timestamps, recipients, and delivery status for post-incident review.

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "summary": "<One-paragraph overall assessment>",
  "findings": [
    {
      "id": "<string>",
      "category": "trigger_gap | segmentation | automation_risk | template_gap | alert_fatigue | escalation_gap | audit_gap",
      "severity": "critical | high | medium | low",
      "description": "<Clear description of the finding>",
      "recommendation": "<Actionable fix>"
    }
  ],
  "risk_score": <integer 1-10, where 10 is highest risk>,
  "requires_human_review": <boolean>
}

## CONSTRAINTS
- Base all findings on the provided inputs. Do not invent stakeholders or channels.
- If an input is missing, note it as a critical finding with the category "missing_input".
- For any finding with severity "critical" or "high", set `requires_human_review` to true.

To adapt this template, replace every [SQUARE_BRACKET_PLACEHOLDER] with your actual context. The [ALERT_THRESHOLD] and [ACK_TIMEOUT] variables should be set to your team's operational targets (e.g., 20 messages/day and 15 minutes). If your architecture spans multiple services, paste the full description into [ARCHITECTURE_DESCRIPTION]. The output JSON is designed to be parsed directly by a CI/CD pipeline or an internal dashboard, so keep the schema intact. If you need to add review criteria specific to your organization—such as regulatory notification requirements—append them to the numbered list without removing the existing checks.

Before sending this prompt to a model, validate that you have populated every placeholder. An empty [STAKEHOLDER_MAP] will cause the model to flag a critical missing_input finding, which is a useful guardrail but wastes a round-trip if you intended to provide it. After receiving the output, run a structural validation on the JSON to ensure the findings array is present and each object has the required fields. For high-risk releases, route any output where requires_human_review is true or risk_score is above 7 to a release manager for manual approval before proceeding.

This prompt is designed to be called programmatically from a release management tool, a CI/CD pipeline stage, or an internal platform API. It expects a structured input payload containing the release metadata, notification architecture design, and audience segmentation rules. The system instruction should set the model's role to 'senior release architecture reviewer' and explicitly instruct it to return only valid JSON conforming to the defined output schema. Do not call this prompt from a chat interface or expect conversational output; it is a machine-to-machine prompt built for structured review generation.

Parse the JSON response into your existing review dashboard or release governance system. If the model returns findings with severity critical, route the output to a human reviewer before publishing any release communication artifacts. Log every invocation with the prompt version, input hashes, and output signature for auditability. Implement a retry mechanism with exponential backoff if the response fails JSON schema validation. After three consecutive validation failures, escalate to a human and attach the malformed response for diagnosis. Set a timeout appropriate for your model provider's latency profile—typically 30–60 seconds for a review of this complexity.

For model choice, prefer a model with strong structured output capabilities and a large context window to handle detailed architecture descriptions. If your release communication design includes sensitive internal system details, route the prompt through a private deployment or a zero-retention API endpoint. Do not send unreviewed critical findings directly to stakeholders. The output of this prompt is a review artifact, not a final communication. Always apply human judgment to severity classifications and remediation recommendations before acting on them.