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 →

Cross-functional production risk escalation

Produces a structured cross-functional risk escalation brief that identifies production blockers across Merchandising, Creative, and Sourcing, assigns severity and owner, maps launch-date impact, and delivers a…

download .md

Purpose

Turn a messy set of cross-team production dependencies into a clear, severity-ranked escalation brief that names the blocker, the owner, the launch-date impact, and the specific decision each stakeholder must make — so risks get resolved days before they threaten a go-live, not after. Solves the producer's core problem: knowing a launch is slipping but not being able to communicate it in a way that forces action.

When to Use

Invoke this skill when the user asks to:

  • Flag a launch that is at risk of missing its go-live date
  • Escalate a blocker involving Merchandising, Creative, or Sourcing
  • Prepare a status update or escalation for a launch review meeting
  • Assess whether a slipping dependency will actually impact the launch calendar
  • Write a message to stakeholders asking for a decision or resource to unblock production
  • Consolidate scattered blockers across teams into one prioritized view

Inputs Required

Before starting, collect:

  • Launch details: Product/collection name and target go-live date
  • Current production stage: Where the launch is in the pipeline (sample, photo, copy, PDP build, QA, etc.)
  • Known blockers: What is stuck, incomplete, or waiting — one line each, with the team responsible if known
  • Dependencies: What downstream work is waiting on each blocker
  • Team contacts: Who owns Merchandising, Creative, and Sourcing decisions for this launch
  • Hard vs. soft deadline: Is the go-live date fixed (marketing campaign, seasonal drop) or flexible?
  • Escalation audience: Who receives this — peers, team leads, or senior leadership

If team ownership or dependencies are unclear, infer the most likely owner from the blocker's nature and flag it as an assumption to confirm.

Instructions

Step 1: Inventory Every Blocker and Assign a Team Owner

List each blocker and route it to the responsible function. Use these signals:

  • Merchandising: pricing not finalized, assortment/SKU list incomplete, product data missing, category placement undecided
  • Creative: photography not shot/retouched, copy not written/approved, PDP assets or design not delivered, brand review pending
  • Sourcing: samples not received, inventory not confirmed, supplier lead-time risk, quality/spec issues on physical product
  • Cross-team / ambiguous: label these explicitly — they are the most dangerous because no one owns them

For each blocker, capture: what is stuck, who owns it, and what is waiting downstream.

Step 2: Score Severity for Each Blocker

Assign each blocker a severity using this matrix:

  • P1 — Launch Blocker: If unresolved, the go-live date moves. No workaround exists.
  • P2 — At Risk: Resolvable but the buffer is gone; one more slip makes it a P1.
  • P3 — Watch: On the critical path but currently has slack; monitor only.

Base severity on two factors: (1) is it on the critical path to go-live, and (2) how much buffer remains before it forces a date change.

Step 3: Map Launch-Date Impact

For each P1 and P2 blocker, quantify the impact:

  • Days at risk: Estimated days the launch slips if the blocker is not resolved by its decision deadline
  • Decision deadline: The last date a decision or delivery can happen without moving go-live
  • Downstream cascade: What other work stalls behind this blocker (e.g., "photo delay → PDP build delay → QA compressed to zero")

Work backward from the go-live date through the production pipeline to calculate each decision deadline.

Step 4: Define the Specific Ask per Blocker

Every escalated item must have a concrete ask — not "please look into this." Frame each as:

  • The decision or action needed: e.g., "Confirm final SKU list" / "Approve hero image" / "Confirm sample arrival date"
  • The owner: Named person or function
  • The by-when: The decision deadline from Step 3
  • The consequence if missed: The days-at-risk figure

Step 5: Draft the Escalation Message

Write a ready-to-send message calibrated to the audience:

  • Subject line: [Launch Name] — Production Risk: [N] blockers, [go-live date] at risk
  • One-line status: Current health in a single sentence (On Track / At Risk / Blocked)
  • The ask up top: Lead with what you need decided and by when — not background
  • Blocker summary: P1s first, then P2s, each with owner, ask, deadline, and consequence
  • Recommended path: Your recommendation for the fastest way to protect the date

Match tone to audience: peer-to-peer is collaborative and direct; leadership is concise, decision-oriented, and leads with the date impact.

Output Format

  • Structure: Risk register table followed by a ready-to-send escalation message
  • Length: 500–800 words
  • Format: A blocker table (columns: Blocker / Owner Team / Severity / Days at Risk / Decision Deadline / Specific Ask), then the escalation message as formatted prose
  • Sections: Launch Status Summary → Risk Register (table) → Launch-Date Impact Summary → Escalation Message (subject, status, ask, blocker detail, recommendation)
  • Tone: Producer who owns the timeline — calm, specific, action-forcing. States impact plainly without alarm or hedging.

Quality Checklist

Before delivering output, verify:

  • [ ] Every blocker has a named owner team (Merchandising, Creative, Sourcing, or flagged Cross-team)
  • [ ] Every blocker has a severity rating (P1 / P2 / P3) with critical-path reasoning
  • [ ] Every P1 and P2 has a specific decision deadline tied to the go-live date
  • [ ] Every escalated item has a concrete ask with a by-when and a stated consequence — no "please look into this"
  • [ ] The escalation message leads with the ask and date impact, not background context
  • [ ] Any inferred ownership or estimate is flagged as an assumption to confirm

Notes

  • The most dangerous blockers are the ones with no clear owner — always surface cross-team ambiguity as its own line item.
  • Escalate early on P2s: the point of this skill is to move risks before they become P1s, not to report P1s after the date has already slipped.
  • Decision deadlines are more actionable than go-live dates — stakeholders respond to "decide by Thursday" far faster than "launch is at risk."
  • When the go-live date is a hard deadline (seasonal drop, paid campaign), state that explicitly in the message — it changes how leadership prioritizes 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