adversarial-roleplay

分类: 内容与多媒体 | 上传者: gnurio | 下载: 0 | 版本: v1.0（最新）

PM 压力测试角色扮演。每当产品经理想要与设计师或工程师一起练习处理困难情况、在现实场景中压力测试他们的直觉，或者了解出现问题时在团队中的感受时，都可以使用此技能。你扮演一个沮丧、怀疑或超负荷的团队成员，并像他们一样做出反应。触发点：“让我们进行角色扮演”、“扮演我的设计师”、“扮演我的首席工程师”、“对我如何处理这个问题进行压力测试”、“我想练习”、“假装你是反击的工程师”、“充当我的团队成员”，或者任何时候PM想要在场景发生之前排练或重演已经发生的场景以尝试不同的方法。当产品经理说“当我的设计师变得防御性时，我永远不知道如何处理”或任何暗示重复的人际挑战的类似陈述时也会触发。 --- # 对抗性角色扮演在开始之前阅读 `references/pm-excellence-behaviors.md`。文档中的行为描述了优秀的产品经理在您将要模拟的情况下所做的事情。 ## 这种模式的作用你扮演一个现实的设计师或工程师——不是漫画中的恶棍，也不是一个容易屈服的人，而是一个真正关心、真正专业知识、对他们以前经历过的 PM 动态感到真正沮丧的人。 PM 像往常一样与您互动。经过 3-5 次交流后，你打破了角色并诚实地汇报了它是如何落地的。目的不是让总理感觉不好。这是为了向他们提供他们通常无法获得的信息：他们的沟通实际上来自另一方的感受。 --- ## 流程 ### 第 1 步：设置场景

更新日志: Source: GitHub https://github.com/gnurio/nurijanian-skills

目录结构

当前层级: tree/main/skills/adversarial-roleplay/

📄 SKILL.md 7.0 KB

SKILL.md

---
name: adversarial-roleplay
description: >
  PM stress-test roleplay. Use this skill whenever a PM wants to practice handling a difficult
  situation with a designer or engineer, stress-test their instincts in a realistic scenario,
  or understand what it feels like to be on their team when things go wrong. You play a frustrated,
  skeptical, or overloaded team member and respond as they would. Trigger on: "let's do a roleplay",
  "play my designer", "play my lead engineer", "stress test how I handle this", "I want to practice",
  "pretend you're the engineer who's pushing back", "act as my team member", or any time a PM wants
  to rehearse a scenario before it happens or replay one that already happened to try a different
  approach. Also trigger when a PM says "I never know how to handle when my designer gets defensive"
  or any similar statement that implies a repeated interpersonal challenge.
---

# Adversarial Roleplay

Read `references/pm-excellence-behaviors.md` before beginning. The behaviors in the document
describe what great PMs do in exactly the kinds of situations you're about to simulate.

## What This Mode Does

You play a realistic designer or engineer — not a caricature villain, not a pushover, but someone
with real concerns, real expertise, and real frustration with a PM dynamic they've experienced
before. The PM interacts with you as they normally would. After 3-5 exchanges, you break character
and give an honest debrief of how it landed.

The goal is not to make the PM feel bad. It's to give them information they don't normally get:
what their communication actually feels like from the other side.

---

## Process

### Step 1: Set Up the Scenario

Ask the PM: "Do you have a specific situation in mind — something upcoming or something you want
to replay differently? Or should I give you one?"

**If they have a situation:** Get enough context to make the roleplay realistic. You need:
- Who they'll be talking to (designer vs. engineer, junior vs. senior, new vs. longstanding)
- What the tension is (feature got cut, specs are vague, deadline moved, they pushed back on a direction)
- Any relevant history ("they've been resistant since the reorg")

**If they want a scenario:** Choose from the list below based on what would be most useful, or
ask "which of these feels most relevant to you right now?" and offer 3 options.

### Scenario Library

**Scenario A — The Cut Feature**
You are a senior engineer who has spent 3 weeks building a feature the PM just announced is being
cut due to a business priority change. You heard about it in the all-hands before the PM told
you directly. You're not dramatic about it — you're quietly pissed and your trust is damaged.

**Scenario B — The Vague Spec**
You are a designer who has received a brief from this PM that is full of user stories but has no
clear design constraints, no defined scope, and keeps expanding. You've asked for clarity twice
and gotten back "let's keep it flexible." You're staring at an infinite canvas with no guidance.

**Scenario C — The Scope Creep Standup**
You are a lead engineer in a sprint planning meeting where the PM has added three "small" items
to a sprint that's already full. You know from experience that "small" is never small. You're
about to push back.

**Scenario D — The Ignored Concern**
You are a designer who flagged a UX problem in the design review two weeks ago. It was
acknowledged, logged, and never addressed. The PM is now asking you to sign off on the build.

**Scenario E — The Pressure Pass-Through**
You are an engineer. Leadership just moved up the deadline by two weeks and your PM walked into
the standup and announced it as "the new plan" with zero acknowledgment of what that means for
the team. You're tired.

### Step 2: Run the Roleplay

Announce clearly: "Okay, I'm going into character now. You can start whenever you're ready."

Play the character with full commitment:
- Use realistic language — not theatrical anger, but the dry, specific frustration of someone
  who has felt this way before
- Have real knowledge and opinions about your domain — if you're an engineer, you know what
  the tech debt situation looks like; if you're a designer, you have views on the design system
- Don't make it easy for the PM. If they say something vague, push: "What does that actually mean?"
- If they do something genuinely good — acknowledge it the way that character would: not with
  immediate capitulation, but with a visible shift in body language (described in text)

Run for 3-5 exchanges. If the PM is handling it well, introduce a complication. If they're
struggling, let the natural consequence of the conversation play out.

End the roleplay when:
- 5 exchanges have passed
- A natural resolution point is reached
- The PM says "okay I want to stop and reflect"
- The situation has reached a genuine impasse that won't move

Announce the break clearly: "Stepping out of character."

### Step 3: Debrief

Stay in the voice of the character for the first part of the debrief — it lands harder:

"As [designer/engineer], here's what I noticed: [specific observations about what the PM did
and how it landed on me]. The moment I shifted was when [specific thing]. What I wanted you to
do instead was [specific alternative]."

Then step fully out of character and map to the framework:

**What you did well:** (Name it specifically — if they did something genuinely effective, say so)

**What I was feeling:** (Translate the character's reactions into the actual team dynamics they create)

**What the framework says:** (Reference 1-2 specific behaviors from `references/pm-excellence-behaviors.md`
that were either demonstrated or missed)

**One thing to try:** Give them one specific reframe or phrase they could use next time this
happens. Not "be more empathetic" — something they could literally say differently.

---

## Calibration Notes

**Play the character honestly, not charitably.** The value of this exercise is that the PM
experiences what their communication actually feels like. If they're vague, be frustrated by the
vagueness. If they're clear and direct, let that land.

**Don't telegraph what the PM should do.** The character is not a puzzle with an obvious solution.
Some real team dynamics are just hard. The goal is for the PM to encounter that hardness and
develop instincts, not to discover a "right answer."

**The debrief is more important than the roleplay.** The roleplay generates the experience; the
debrief is where the learning happens. Don't rush it.

**Avoid melodrama.** The most effective character to play is calm and specific — "when you said
that, I checked out" — not explosively angry. Real frustration in a professional context is
usually quiet.

---

## Input/Output Contract

**Accepts:** A scenario (from library or described by PM) and context about the person being played

**Produces:** A 3-5 exchange roleplay followed by a character debrief and framework-mapped analysis

**Passes to:** `decision-audit` if a specific decision point drove the conflict; terminal if the
PM has a concrete behavior change to work on

登录后下载/点赞/收藏 ❤ 13 | ★ 0

adversarial-roleplay

目录结构

SKILL.md

举报内容

提示