Purpose
Convert scattered, conflicting stakeholder input into three ready-to-share alignment artifacts — design principles, a tradeoff summary, and a decision log entry — that let a cross-functional team commit to a direction and stop reopening the debate. Solves the "we already decided this three times" problem by making the reasoning, tradeoffs, and dissent explicit and durable.
When to Use
Invoke this skill when the user asks to:
- Break a stalled design or product decision where stakeholders keep disagreeing
- Turn a messy Slack thread, doc comment war, or meeting recap into a clear decision
- Document why a design choice was made so it doesn't get relitigated later
- Get engineering, PM, design, and leadership to disagree-and-commit
- Write a decision log, ADR-style entry, or set of design principles for a feature
- Summarize competing options and tradeoffs before a decision meeting
Inputs Required
Before starting, collect:
- Decision topic: The specific question being decided (e.g., "onboarding: progressive vs. all-at-once")
- Stakeholder inputs: The raw material — paste of Slack messages, meeting notes, comments, or a summary of who wants what
- Options on the table: The 2–4 directions being considered (if unclear, infer them from the inputs)
- Stakeholders involved: Who holds a position and their role (PM, eng lead, design, leadership, etc.)
- Constraints: Hard limits — deadline, tech feasibility, budget, brand, legal, platform
- Success signal: What outcome the team is ultimately optimizing for (activation, revenue, speed to ship, etc.)
- Decision owner: Who makes the final call if consensus isn't reached (the DRI)
If the decision owner is unstated, flag it explicitly — an unassigned DRI is the most common cause of stalled alignment. If options aren't listed, extract them from the raw inputs and confirm them in the output.
Instructions
Step 1: Extract Positions from the Mess
Parse the raw stakeholder input into a clean map:
- List each distinct position and who holds it (attribute by name/role)
- Separate stated positions (what they say they want) from underlying interests (why they want it — the goal beneath the opinion)
- Flag any false conflicts — cases where two stakeholders actually want compatible outcomes but are arguing about implementation
- Note unspoken assumptions each side is making that haven't been surfaced
Format as a short position map: [Stakeholder/role] wants [position] because [underlying interest].
Step 2: Draft Design Principles (4–6)
Generate the principles that should govern this decision — the decision-making criteria the team can agree on before picking an option.
- Each principle is a directional statement: "When forced to choose, we favor X over Y."
- Principles must create tension — a principle that no one would disagree with is useless. Good principles make hard calls easier by pre-committing to a value ordering.
- Ground each principle in the success signal and constraints, not in personal preference
- Example shape: "We optimize for time-to-first-value over feature completeness in onboarding."
Step 3: Build the Tradeoff Summary Matrix
Create a comparison table of the options on the table:
- Rows: Each option under consideration
- Columns: The 3–5 dimensions that matter most (derived from principles + constraints — e.g., activation impact, eng effort, risk, reversibility, time-to-ship)
- Fill each cell with a concrete, honest assessment — not "good/bad" but specific consequences
- Add a Reversibility note per option: is this a one-way or two-way door? (Two-way-door decisions deserve less debate and faster commitment.)
- Below the matrix, write a 2–3 sentence honest tradeoff statement: what the team gives up no matter which option wins
Step 4: Write the Recommendation and Decision Log Entry
Make a clear recommendation, then formalize it:
- Recommendation: State the recommended option and tie it directly to the principles from Step 2. Be decisive.
- Decision Log Entry (ADR-style), containing:
- Decision: One sentence — what was decided
- Date & Owner: Who made the call (the DRI)
- Context: The problem being solved, in 2–3 sentences
- Options considered: One line each, why the others were not chosen
- Rationale: Why this option, referencing the principles
- Dissent captured: Who disagreed and their strongest objection — recorded respectfully, not erased
- Commitment ask: The explicit disagree-and-commit statement everyone signs off on
- Revisit trigger: The specific condition under which this decision should be reopened (e.g., "if activation drops below X after launch")
Step 5: Provide the Alignment Message
Draft a 4–6 sentence message the decision owner can paste into Slack or email to close the loop: states the decision, thanks dissenters by acknowledging their concern, and asks for explicit commit.
Output Format
- Structure: Five sections in order — Position Map → Design Principles → Tradeoff Matrix → Recommendation & Decision Log → Alignment Message
- Length: 700–1,000 words
- Format: Position map as attributed bullets; principles as a numbered list; tradeoffs as a table; decision log as a labeled structured block; alignment message as short prose
- Sections: Position Map, Design Principles (4–6), Tradeoff Summary Matrix, Recommendation, Decision Log Entry, Alignment Message
- Tone: Neutral facilitator — even-handed toward all stakeholders in the map, then decisive in the recommendation. Never dismissive of dissent; never wishy-washy on the call.
Quality Checklist
Before delivering output, verify:
- [ ] Every position in the map is attributed to a stakeholder or role — no anonymous "some people think"
- [ ] Each design principle makes a real tradeoff (favors X over Y) — none are universally agreeable filler
- [ ] The tradeoff matrix has one row per option and cells contain specific consequences, not "good/bad"
- [ ] Each option is labeled one-way or two-way door
- [ ] The decision log captures at least one dissenting view rather than erasing disagreement
- [ ] The revisit trigger is a specific, measurable condition — not "revisit later"
- [ ] A single decision owner (DRI) is named; if none was provided, this is flagged
Notes
- The most common failure mode isn't disagreement — it's decisions that were never actually made, just discussed. Force a named owner and an explicit commit ask every time.
- Two-way-door decisions (easily reversible) should be resolved fast with minimal debate; reserve deep alignment work for one-way doors.
- Capturing dissent isn't a courtesy — it's what makes disagree-and-commit real. A dissenter whose concern is recorded is far more likely to commit than one who feels steamrolled.
- If the underlying interests reveal a false conflict, surface it prominently — resolving a false conflict is faster and cheaper than choosing between options.
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:
- Drag this file into a new chat, or copy and paste its contents
- 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