Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Stakeholder communication generator for technical policy decisions

Translates technical enforcement or AI system decisions into plain-language stakeholder communications with a decision summary, policy impact analysis, risk framing, precedent notes, and a recommended action for…

download .md

Purpose

Convert a technical system change — a model update, enforcement threshold adjustment, classifier retraining, or automated decision logic change — into a structured, plain-language communication that policy and legal stakeholders can review, question, and approve without needing to understand the underlying engineering. Solves the recurring gap where technical decisions stall in cross-functional review because reviewers can't map system behavior to policy risk.

When to Use

Invoke this skill when the user asks to:

  • Explain a model, classifier, or algorithm change to non-technical policy or legal stakeholders
  • Write an enforcement change notification for a trust & safety or policy team
  • Summarize the policy impact of an automated decision or AI system behavior
  • Prepare a technical decision for cross-functional review or executive sign-off
  • Draft a communication that translates false positive/negative tradeoffs into policy consequences
  • Document a threshold, rule, or logic change for a legal or compliance audience

Inputs Required

Before starting, collect:

  • The technical change: What is changing in the system — the model, threshold, rule, or logic (in the PM's own words)
  • Why it's changing: The problem being solved or the trigger for the change
  • Audience: Who receives this — policy team, legal, trust & safety leadership, executives, or a mix
  • Behavioral impact: What users or content will experience differently (more enforcement, fewer removals, faster review, etc.)
  • Known tradeoffs: Any expected shift in false positives/negatives, appeal volume, or coverage gaps
  • Metrics available: Any before/after numbers — precision, recall, volume, error rates (optional but strongly used if present)
  • Decision needed: Whether this is informational (FYI) or requires stakeholder approval

If metrics aren't available, produce qualitative impact framing and flag which metrics would strengthen the case.

Instructions

Step 1: Extract the Decision in One Sentence

Compress the technical change into a single plain-language sentence a policy lawyer could repeat accurately. Strip all engineering jargon.

  • Replace terms like "classifier," "model," "threshold" with functional descriptions: what the system now catches, misses, or does differently
  • The sentence must answer: what changed and what will now happen differently
  • Test: could a reviewer paraphrase this correctly to their manager after one read?

Step 2: Build the Policy Impact Analysis

Map the technical behavior to policy consequences across three dimensions:

Coverage — what the system now enforces or stops enforcing

  • Which policy areas or violation types are affected
  • Whether the change tightens or loosens enforcement

Error profile — who gets affected by mistakes

  • Translate false positives into "users wrongly actioned" and false negatives into "violations that slip through"
  • Frame the tradeoff in human terms, not statistical terms: "this catches ~15% more violations but wrongly flags roughly 1 in 200 legitimate posts"

Affected populations — who experiences the change

  • User segments, content types, or geographies disproportionately impacted
  • Any group with elevated appeal or fairness sensitivity

Step 3: Frame the Risk Honestly

Reviewers trust communications that name the downside. For each material risk, state:

  • The risk: what could go wrong in plain language
  • Likelihood: rough qualitative assessment (low / moderate / elevated)
  • Mitigation: what's in place or planned to contain it
  • Reversibility: whether the change can be rolled back quickly if it misfires

Do not soften or bury risk — legal reviewers escalate hidden risk far harder than disclosed risk.

Step 4: Add Precedent and Consistency Notes

Situate the decision against prior decisions:

  • Whether this aligns with, extends, or departs from existing enforcement precedent
  • Any external commitments (transparency reports, regulatory filings, public policy statements) the change touches
  • Whether it creates a precedent future decisions will be measured against

Step 5: State the Recommended Action and What's Needed

Close with the ask:

  • If informational: state clearly that no action is required and by when concerns should be raised
  • If approval is needed: state exactly what decision is being requested, the deadline, and what happens if no response is received
  • List the specific questions stakeholders are best positioned to answer

Output Format

  • Structure: Titled communication with a bolded one-line decision summary at the top, followed by labeled sections
  • Length: 500–800 words
  • Format: Structured document — short paragraphs and scannable labeled sections; error tradeoffs may use a compact table
  • Sections: Decision Summary (one line) → Why This Is Changing → Policy Impact → Risk & Mitigation → Precedent & Consistency → Recommended Action / What We Need From You
  • Tone: Calm, direct, non-defensive. Written as a product manager who respects the reviewer's expertise and doesn't hide behind technical language or optimism

Quality Checklist

Before delivering output, verify:

  • [ ] The one-line decision summary contains zero engineering jargon (no "model," "classifier," "threshold" without a functional gloss)
  • [ ] Error tradeoffs are stated in human terms (users affected, violations missed) — not raw statistical terms alone
  • [ ] At least one material risk is named with likelihood, mitigation, and reversibility
  • [ ] Affected populations are identified specifically — not "some users"
  • [ ] The Recommended Action states clearly whether approval is required and by when
  • [ ] Precedent section connects the decision to prior enforcement or external commitments

Notes

  • The most common failure is under-disclosing risk to get faster approval — this backfires; disclosed risk earns trust and reversibility earns approval
  • When metrics are strong, lead the impact section with them; when metrics are weak or absent, lead with qualitative framing and explicitly flag the measurement gap
  • This communication is reusable as a template across enforcement change notifications — keep the section structure stable so stakeholders learn where to find risk and the ask every time
  • For legal-heavy audiences, precedent and reversibility carry more weight than performance metrics; for executive audiences, lead with the decision summary and the ask

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills