# Communicating Decisions

> Communicate product decisions so teams understand not just what was decided but why. Covers framing, transparency about trade-offs, and handling disagreement gracefully. Use when decisions aren't sticking, teams are relitigating past calls, or when stakeholders feel left out.

- Skill: `dragoon0x/communicating-decisions` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dragoon0x/communicating-decisions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/communicating-decisions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dragoon0x (https://skillmd.com/u/dragoon0x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dragoon0x/communicating-decisions

---


# Communicating Decisions

Tell people what you decided, why, and what it means for them.

## How to use

- `/communicating-decisions` Apply decision communication constraints to this conversation.
- `/communicating-decisions <decision>` Draft communication for the described product decision.

## Constraints

### Decision Framing
- MUST lead with the decision, then explain the reasoning. Don't bury the headline.
- MUST explain the why: what problem this solves, what data informed it, what alternatives were considered
- MUST name the trade-offs explicitly: what you're giving up and why
- SHOULD acknowledge who was consulted and how their input shaped the decision
- NEVER present a decision without context. Context turns compliance into buy-in.

### Audience Calibration
- Engineering needs: what changes, technical implications, timeline impact
- Design needs: scope boundaries, user flows affected, quality bar expectations
- Leadership needs: strategic rationale, business impact, resource implications
- Sales/CS needs: customer-facing changes, messaging guidance, timeline for enablement
- MUST tailor depth and framing to each audience. One announcement doesn't fit all.

### Handling Disagreement
- MUST create space for disagreement BEFORE the decision is final
- SHOULD actively seek out the strongest counterargument and address it
- Once decided: expect disagree and commit. The decision is the decision.
- If someone was overruled: MUST acknowledge their input and explain why you went a different direction
- NEVER pretend there was consensus when there wasn't. Be honest about the call.

### Documentation
- Every significant decision MUST be written down with: what, why, who was involved, date, alternatives considered
- SHOULD be stored somewhere the team can reference later
- MUST update documentation if the decision gets revisited or changed
- NEVER leave decisions in chat threads where they get lost

### Anti-Patterns
- The Mystery Decision: "we're doing X now" with no explanation
- The Consensus Illusion: pretending everyone agreed when someone was clearly overruled
- Decision Amnesia: no record of why a decision was made, leading to revisits months later
- The Drip: communicating a decision slowly through hallway conversations instead of a clear announcement
- Relitigating: allowing decided issues to be reopened without new information