Claude
572b8acf8c
Make the library multi-platform without duplicating content. Each skills/<name>/SKILL.md body remains the single source of truth; a new generator renders platform-ready exports from it. - scripts/build-exports.mjs — dependency-free Node generator with a PLATFORMS registry so new platforms (Gemini, Cursor, …) are a few lines. Ships ChatGPT exports at exports/chatgpt/<bundle>/<skill>/SYSTEM_PROMPT.md (172 skills), plus generated index READMEs. Supports --platform and --check. - exports/ — generated ChatGPT system prompts, ready to paste into a Custom GPT. - .github/workflows/check-generated.yml — fails a PR if exports or web/skills.json drift from the source skills. - README "Works With" now documents the ready-to-use exports and regen command. - CHANGELOG + SKILL-AUTHORING-STANDARD note the generated artifacts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px
66 lines
3.5 KiB
Markdown
66 lines
3.5 KiB
Markdown
# 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
|
|
1. Tag each signal by source and apply weight
|
|
2. Look for **convergence**: same underlying need appearing across 3+ sources
|
|
3. Look for **divergence**: contradictory signals suggesting user segmentation
|
|
4. 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")
|
|
5. Produce ranked insights by weighted frequency
|
|
6. **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
|