mohitagw15856
036511ab3e
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
3.5 KiB
3.5 KiB
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