Purpose
Turn messy team feedback — retro notes, survey verbatims, interview snippets — into a ranked map of where cross-functional work breaks down, with root-cause diagnosis and specific interventions for each friction point. Solves the problem of "everyone knows things are slow at the handoffs, but no one can name exactly where or why."
When to Use
Invoke this skill when the user asks to:
- Analyze retrospective or survey data to find recurring team friction
- Diagnose why cross-functional projects keep stalling or slipping
- Map handoff breakdowns between departments (e.g., Sales→CS, Product→Eng, Design→Eng)
- Synthesize interview or feedback themes into an alignment action plan
- Prepare a friction summary for a leadership offsite or planning cycle
- Identify which team seams cost the most time or rework
Inputs Required
Before starting, collect:
- Functions involved: The teams or departments whose interactions are being analyzed
- Input data: The raw material — retro notes, survey responses, interview quotes, Slack threads, or postmortems (paste or describe)
- Time period: What window the data covers (last quarter, last 6 months, single project)
- Known pain areas: Any friction the user already suspects, to validate or challenge
- Recent org changes: Reorgs, new tools, headcount shifts, or process changes in the period
- Primary outcome: What the user wants to fix (speed, rework, morale, missed handoffs)
If input data is thin, note the confidence limitation and flag which conclusions are provisional versus well-supported.
Instructions
Step 1: Extract and Tag Friction Signals
Read all input data and pull every distinct friction signal. For each, tag:
- The seam: Which two functions the friction sits between (or "internal" if within one team)
- The moment: Where in the workflow it occurs — handoff, dependency wait, decision gate, feedback loop, or ownership gap
- The signal type: Complaint, delay, rework event, escalation, or blocked work
- Frequency: How many independent inputs mention this (count them — repetition is signal)
Deduplicate near-identical signals but preserve the count. A friction mentioned by six people is not the same as one mentioned once.
Step 2: Cluster Into Friction Points
Group tagged signals into distinct friction points. A friction point is a recurring, nameable breakdown — not a one-off. Give each a plain-language name (e.g., "Design handoffs arrive without acceptance criteria" not "communication issues"). Aim for 5–9 named friction points; if you have more, the clustering is too granular.
Step 3: Diagnose Root Cause by Category
Classify each friction point's root cause into one of five categories:
- Ownership gap: No one is accountable for the handoff or the space between teams
- Information gap: The receiving team lacks context, spec, or data to act
- Process gap: No defined trigger, SLA, or checklist for the handoff
- Tooling/visibility gap: Work is invisible across the seam; no shared source of truth
- Incentive misalignment: Teams are measured on conflicting goals that pit them against each other
State the category explicitly and give one sentence of evidence from the data. Distinguish symptom from cause — "Eng deprioritizes CS requests" is a symptom; "CS and Eng have no shared prioritization ritual" is the cause.
Step 4: Score and Rank Each Friction Point
Score each friction point on three dimensions (High/Medium/Low):
- Frequency: How often it recurs (from Step 1 counts)
- Cost: Time lost, rework created, or deals/deadlines at risk
- Fixability: How tractable the fix is in the next quarter
Rank the friction points by a combined priority, weighting Frequency × Cost most heavily, with Fixability as the tiebreaker. Surface "high-leverage quick wins" (High cost, High fixability) separately.
Step 5: Prescribe a Specific Intervention Per Friction Point
For each friction point, write one concrete intervention matched to its root-cause category:
- Ownership gaps → name a single accountable owner or DRI for the seam
- Information gaps → define the required handoff artifact (spec, brief, acceptance criteria)
- Process gaps → propose the ritual, trigger, or SLA to install
- Tooling gaps → name the shared view or single source of truth to establish
- Incentive misalignment → propose the shared metric or joint goal
Each intervention must name what changes, who owns it, and how success is measured. No "improve communication."
Step 6: Build the 30-60-90 Action Plan
Sequence the interventions:
- First 30 days: Quick wins and the single highest-priority fix
- Days 31–60: Process and artifact changes requiring cross-team buy-in
- Days 61–90: Structural or incentive changes needing leadership sponsorship
Output Format
- Structure: Ranked friction map as a table, followed by per-friction-point diagnosis and intervention, then the phased action plan
- Length: 900–1,300 words
- Format: Summary table + structured sections per friction point + sequenced plan
- Sections: Executive summary (3–4 sentences) → Ranked friction map table → Per-friction-point diagnosis & intervention → Quick wins → 30-60-90 action plan → Confidence & data gaps note
- Tone: Chief of staff analytical — neutral about people, direct about systems, evidence-anchored, non-blaming
Quality Checklist
Before delivering output, verify:
- [ ] Every friction point is named in plain language, not a vague category
- [ ] Each friction point cites frequency count from the input data
- [ ] Every root cause is classified into one of the five categories with evidence
- [ ] The ranking is driven by Frequency × Cost — not listed arbitrarily
- [ ] Each intervention names what changes, who owns it, and how success is measured
- [ ] Diagnosis distinguishes symptom from cause (no symptom labeled as root cause)
- [ ] A confidence note flags any conclusion drawn from thin or single-source data
Notes
- The most common misdiagnosis is calling an ownership gap a "communication problem" — friction at seams is almost always structural, not interpersonal
- Frequency count is the strongest signal in messy data; weight what's repeated across independent sources over what's stated most emphatically once
- Keep the analysis system-focused, not person-focused — naming individuals as the problem kills adoption of the fixes
- If the user has only one data source (e.g., one retro), state clearly that patterns are directional and recommend a second input type before major structural changes
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