Windsurf + Aider targets, MCP server, and demo placement (#33)

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>
This commit is contained in:
mohitagw15856
2026-06-17 23:15:38 +01:00
committed by GitHub
parent 123aabe5e3
commit 036511ab3e
358 changed files with 60408 additions and 38 deletions
@@ -0,0 +1,110 @@
# Discovery Interview Guide Skill
Design interviews that surface genuine insight — not validation of what you already believe. Every guide follows a story-based, past-behaviour-focused structure.
## Core Principles
1. **Never ask about the future.** "Would you use X?" tells you nothing. "Tell me about the last time you did X" tells you everything.
2. **Interview for behaviour, not opinion.** Opinions are cheap. Behaviour is evidence.
3. **The 5 Whys.** Every surface answer is a door. Keep opening doors.
4. **Confirm the problem before exploring the solution.** Never show a prototype until you've confirmed the pain exists unprompted.
## Interview Structure (60 minutes standard)
### 1. Warm-Up (5 min)
Build rapport. Get them talking. Don't discuss the topic yet.
- "Tell me a bit about your role and what a typical week looks like for you."
- "What tools do you rely on most day-to-day?"
### 2. Context Setting (10 min)
Understand their world before diving into the problem space.
- "Walk me through how you currently [handle the domain area]."
- "What does that process look like from start to finish?"
- "Who else is involved when you do this?"
### 3. Problem Exploration (25 min) — THE CORE
Surface pain without leading.
- "Tell me about the last time you had to [relevant task]. What happened?"
- "What was the hardest part of that?"
- "How did you handle it?"
- "What did you try before settling on that approach?"
- "What does it cost you when this goes wrong?" (time, money, stress, reputation)
- "If you could wave a magic wand and change one thing about this process, what would it be?"
⚠️ **Do not mention your product or feature during this phase.**
### 4. Current Solutions (10 min)
Understand the competitive landscape from their perspective.
- "What tools or workarounds do you use today for this?"
- "What do you like about [current solution]? What frustrates you?"
- "Have you tried other approaches? What happened?"
### 5. Wrap-Up (10 min)
- "Is there anything about this topic we haven't covered that you think I should know?"
- "Is there anyone else you'd recommend I speak to?"
- "Would you be open to a follow-up if I have more questions?"
---
## Output Format
### Discovery Interview Guide — [Topic] — [Date]
**Research Goal:** [One sentence: what decision will this research inform?]
**Target Participant Profile:** [Role, company size, behaviour qualifier]
**Screener Questions** (for recruiting):
1. [Question] → Must answer: [Y/N or specific]
2. [Question] → Must answer: [Y/N or specific]
3. [Disqualifier question] → Disqualify if: [answer]
**Interview Guide:**
[Full structured guide using the format above, customised to the specific research topic]
**Synthesis Template** (fill after each interview):
- Key quote: "[verbatim]"
- Core pain: [1 sentence]
- Current workaround: [what they're doing today]
- Intensity (15): [how painful is this?]
- Surprise/unexpected finding: [anything that challenged your assumptions]
**Pattern Detection** (after 5+ interviews):
- Pain mentioned by [X/N] participants: [theme]
- Workaround used by [X/N] participants: [theme]
- Most emotionally charged moment in interviews: [observation]
---
## Required Inputs
Ask the user for these if not provided:
- **Research topic or question** (what decision will this inform?)
- **Target participant profile** (role, behaviour, company type)
- **Session length** (30 / 45 / 60 / 90 minutes)
- **Number of interviews planned**
- **Known hypotheses to test or avoid confirming prematurely** (optional)
## Quality Checks
- [ ] No future-tense questions ("would you...") — only past-behaviour questions
- [ ] Product or solution not mentioned until after pain is confirmed
- [ ] Questions open-ended (cannot be answered yes/no)
- [ ] Synthesis template included for per-session notes
- [ ] Screener questions identify and disqualify wrong participants
## Guidelines
- Recommend 58 interviews to reach thematic saturation for most discovery questions
- Always record with permission — transcripts beat notes
- If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
- Never synthesise during the interview — do it after, when you can look across sessions
- Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
## Anti-Patterns
- [ ] Do not use future-tense questions ("Would you use this?") — hypothetical responses do not predict real behaviour and produce false confidence in an idea
- [ ] Do not mention your product or solution before problem exploration is complete — doing so anchors the participant's responses and invalidates the discovery
- [ ] Do not synthesise across fewer than 5 interviews — themes from 23 interviews reflect anecdote, not pattern; wait for saturation
- [ ] Do not write screener questions that are too easy to pass — if participants can guess the "right" answer, you will recruit the wrong people
- [ ] Do not treat participant opinions as evidence of future behaviour — what people say they will do consistently diverges from what they actually do