| name | communication-craft |
| description | Communication patterns for feedback, cross-audience content, and eliciting needs. SBI feedback model (Situation → Behavior → Impact), stakes-calibrated review voice, So-What/What/Now-What audience lead for PRs and status reports, and the three-layer Need/Solution/Feature elicitation ladder. Use when giving feedback in a review, writing for a mixed audience (decision-makers + peers + newcomers + skeptics), clarifying an ambiguous ask before committing to a solution, or coaching someone else's communication. |
| lastReviewed | 2026-07-31T00:00:00.000Z |
Communication Craft
Patterns for feedback, audience, and elicitation. Inherited LLM behaviors (clear prose, jargon-defining, signposting) are assumed and not re-stated. Fires on description-match when the request is about how to communicate — for the always-on tone/attunement rules that fire on every user message, see emotional-intelligence.instructions.md.
1. Giving Feedback
SBI Model — Situation, Behavior, Impact
| Component | Include | Example |
|---|
| Situation | Specific context | "In parseInput() line 42..." |
| Behavior | Observable action, not interpretation | "...the function mutates the input array..." |
| Impact | Effect on caller / system / reader | "...which breaks the contract for any caller passing a frozen array." |
Anti-pattern: "This is wrong." → Replace with "This could cause X. Suggest: [specific change]."
Calibrate to Stakes
| Stakes | Approach |
|---|
| Low (typo, style) | Quick inline note, no fanfare |
| Medium (pattern, design choice) | Specific rationale + suggested alternative |
| High (security, contract, irreversible) | Full explanation, alternatives, would-revise-if |
Code Review Voice
| Avoid | Prefer |
|---|
| "This is wrong" | "This could cause X" |
| "Why did you do this?" | "What led to this approach?" |
| "Obviously should be..." | "Consider X because..." |
| "Please fix" | "Suggest: [specific change]" |
Rule of Three: If giving 3+ critical pieces of feedback on one artifact, stop and ask whether the level of review is right — don't pile on.
2. Audience Lead
So-What → What → Now-What for PRs, summaries, status reports, decision asks: lead with impact, then evidence, then ask. Anti-pattern: data dump first, ask buried at the end.
| Audience | Lead with | Avoid |
|---|
| Decision-maker | Impact + ask | Implementation detail |
| Peer engineer | Approach + trade-offs | Marketing language |
| Domain expert | Specifics + edge cases | Over-explanation |
| Newcomer | Context + prerequisites | Jargon without definition |
| Skeptic | Concerns + mitigation | Aggressive certainty |
3. Eliciting Needs
When the user says "build me X," distinguish three layers:
| Layer | Question | Example |
|---|
| Need (why) | What outcome do you want? | "Catch regressions before release" |
| Solution (what) | What approach achieves that? | "Pre-merge integration test" |
| Feature (how) | What specific thing to build? | "GitHub Action running tests on PR" |
Validate the need before committing to a solution. One sharp question beats five generic ones. Ask "why" up to five times when the root need is unclear.
Related
- emotional-intelligence.instructions.md — the always-on tone/attunement rules that read every user message; this skill fires when the user's request is about how to communicate (feedback, audience, elicitation)
- big-idea skill — the compression discipline that distills the "So-What" that this skill's audience-lead pattern requires
- status-reporting skill — a specific application of the audience-lead pattern for status updates
Would Revise If
Revise if SBI feedback produces no measurable behavior change in 3+ instances over a quarter (the model is performative rather than operative), if the audience-lead table produces tone mismatches when applied verbatim, or if the need/solution/feature elicitation pattern misses real user needs that surface later as scope changes.
