Multi-Source Signal Synthesiser Skill
Synthesises user signals from multiple research sources into a unified, weighted insight brief.
From the mohitagw15856/pm-claude-skills README — shows the whole collection, not only this skill. · view on GitHub
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/multi-source-signal-synthesiser. - Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit mohitagw15856/pm-claude-skills/skills/multi-source-signal-synthesiser#main ~/.claude/skills/multi-source-signal-synthesiserFor one project only, change the path to .claude/skills/multi-source-signal-synthesiser.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Multi-Source Signal Synthesiser Skill
Show the full text71 lines
| name | description |
|---|---|
| multi-source-signal-synthesiser | Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section. |
Multi-Source Signal Synthesiser Skill
Reconcile user signals from multiple sources — interviews, support tickets, NPS, app reviews, sales calls — into a unified, weighted insight brief that surfaces the underlying need rather than the surface-level request.
Required Inputs
Ask the user for these if not provided:
- Signal sources (interviews, support tickets, NPS verbatims, app reviews, sales calls, analytics — any combination)
- Time period covered by the data
- Product area or feature the signals relate to (if scoped)
Source Weighting (default — adapt to context)
| Source | Weight | Rationale |
|---|---|---|
| Direct research (interviews, usability tests) | 5 | Highest-fidelity, structured |
| Support tickets (unprompted pain signals) | 4 | Real pain, unfiltered |
| NPS verbatims | 3 | Broad but shallow |
| App store reviews | 2 | Public, self-selected |
| Sales call summaries | 2 | Filtered through sales lens |
| Anecdote or single report | 1 | Low confidence alone |
Process
- Tag each signal by source and apply weight
- Look for convergence: same underlying need appearing across 3+ sources
- Look for divergence: contradictory signals suggesting user segmentation
- Distinguish surface request from underlying need (e.g. "faster export" may mean "I don't trust the data will be there when I need it")
- Produce ranked insights by weighted frequency
- Validate — Confirm each insight has evidence from at least 2 source types. Flag any insight resting on a single source as low-confidence.
Output Structure
User Signal Synthesis — [Date / Period]
Sources included: [list with count per source] Total signals processed: [n]
Insight 1: [Underlying need, not feature request]
- Confidence: High / Medium / Low (based on source diversity and weight)
- Evidence: [Signals from each source supporting this]
- Conflicting signals: [Any contradicting evidence and how to interpret it]
- Product implication: [Specific next step, not generic]
[Repeat for top 3-5 insights]
Divergent Signals (Possible Segmentation)
[Where user groups appear to have genuinely different needs — specify which segments]
What the Data Does NOT Tell Us
[Gaps that require further research before acting]
Quality Checks
- Every insight references at least 2 distinct source types
- Surface requests are translated to underlying needs (not just echoed)
- Divergent signals identify the specific user segments, not just "some users disagree"
- Confidence ratings are consistent with source diversity and weighting
- "What the data does NOT tell us" section is honest about gaps
Anti-Patterns
- Do not echo surface-level feature requests as insights — translate every request to the underlying need before including it as a finding
- Do not assign High confidence to insights supported by only one source type — confidence requires corroboration across at least two distinct source types
- Do not treat all sources as equally weighted — a single interview quote and a pattern across 200 support tickets are not comparable signals
- Do not collapse divergent signals into a single finding — where user segments have genuinely different needs, name the segments explicitly rather than averaging them away
- Do not omit the research gap section when key decisions rest on thin data — acting on low-confidence findings without flagging the gaps misleads product teams
| 1 | |
| 2 | name multi-source-signal-synthesiser |
| 3 | description "Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section." |
| 4 | |
| 5 | |
| 6 | # Multi-Source Signal Synthesiser Skill |
| 7 | |
| 8 | Reconcile user signals from multiple sources — interviews, support tickets, NPS, app reviews, sales calls — into a unified, weighted insight brief that surfaces the underlying need rather than the surface-level request. |
| 9 | |
| 10 | ## Required Inputs |
| 11 | |
| 12 | Ask the user for these if not provided: |
| 13 | **Signal sources** (interviews, support tickets, NPS verbatims, app reviews, sales calls, analytics — any combination) |
| 14 | **Time period** covered by the data |
| 15 | **Product area or feature** the signals relate to (if scoped) |
| 16 | |
| 17 | ## Source Weighting (default — adapt to context) |
| 18 | |
| 19 | | Source | Weight | Rationale | |
| 20 | |--------|--------|-----------| |
| 21 | | Direct research (interviews, usability tests) | 5 | Highest-fidelity, structured | |
| 22 | | Support tickets (unprompted pain signals) | 4 | Real pain, unfiltered | |
| 23 | | NPS verbatims | 3 | Broad but shallow | |
| 24 | | App store reviews | 2 | Public, self-selected | |
| 25 | | Sales call summaries | 2 | Filtered through sales lens | |
| 26 | | Anecdote or single report | 1 | Low confidence alone | |
| 27 | |
| 28 | ## Process |
| 29 | Tag each signal by source and apply weight |
| 30 | Look for **convergence**: same underlying need appearing across 3+ sources |
| 31 | Look for **divergence**: contradictory signals suggesting user segmentation |
| 32 | Distinguish surface request from underlying need (e.g. "faster export" may mean "I don't trust the data will be there when I need it") |
| 33 | Produce ranked insights by weighted frequency |
| 34 | **Validate** — Confirm each insight has evidence from at least 2 source types. Flag any insight resting on a single source as low-confidence. |
| 35 | |
| 36 | ## Output Structure |
| 37 | |
| 38 | ### User Signal Synthesis — [Date / Period] |
| 39 | **Sources included:** [list with count per source] |
| 40 | **Total signals processed:** [n] |
| 41 | |
| 42 | #### Insight 1: [Underlying need, not feature request] |
| 43 | **Confidence:** High / Medium / Low (based on source diversity and weight) |
| 44 | **Evidence:** [Signals from each source supporting this] |
| 45 | **Conflicting signals:** [Any contradicting evidence and how to interpret it] |
| 46 | **Product implication:** [Specific next step, not generic] |
| 47 | |
| 48 | [Repeat for top 3-5 insights] |
| 49 | |
| 50 | #### Divergent Signals (Possible Segmentation) |
| 51 | [Where user groups appear to have genuinely different needs — specify which segments] |
| 52 | |
| 53 | #### What the Data Does NOT Tell Us |
| 54 | [Gaps that require further research before acting] |
| 55 | |
| 56 | ## Quality Checks |
| 57 | |
| 58 | [ ] Every insight references at least 2 distinct source types |
| 59 | [ ] Surface requests are translated to underlying needs (not just echoed) |
| 60 | [ ] Divergent signals identify the specific user segments, not just "some users disagree" |
| 61 | [ ] Confidence ratings are consistent with source diversity and weighting |
| 62 | [ ] "What the data does NOT tell us" section is honest about gaps |
| 63 | |
| 64 | ## Anti-Patterns |
| 65 | |
| 66 | [ ] Do not echo surface-level feature requests as insights — translate every request to the underlying need before including it as a finding |
| 67 | [ ] Do not assign High confidence to insights supported by only one source type — confidence requires corroboration across at least two distinct source types |
| 68 | [ ] Do not treat all sources as equally weighted — a single interview quote and a pattern across 200 support tickets are not comparable signals |
| 69 | [ ] Do not collapse divergent signals into a single finding — where user segments have genuinely different needs, name the segments explicitly rather than averaging them away |
| 70 | [ ] Do not omit the research gap section when key decisions rest on thin data — acting on low-confidence findings without flagging the gaps misleads product teams |
| 71 |
Discussion
Browse more free Claude skills.