feat: /board — Board of Advisors with 8 knowledge-rich personas + Socratic moderator

board/SKILL.md.tmpl

@@ -0,0 +1,223 @@
+---
+name: board
+version: 1.0.0
+description: |
+  Convene a Board of Advisors. Present a question, decision, or situation
+  and receive a structured Socratic debate from 8 specialist advisors —
+  Growth, Product, Founder, Finance, Leadership, AI, Discovery, and GTM.
+  Each advisor argues from their expertise and knowledge base, challenges
+  the others, and a moderator synthesizes tensions and recommendations.
+  Use when asked to "get different perspectives", "debate this", "board
+  meeting", "advisory board", or "what would advisors say".
+  Proactively suggest when the user faces a strategic decision with
+  multiple valid approaches, or before major product/business pivots.
+  Use after /office-hours for deeper multi-angle analysis.
+benefits-from: [office-hours]
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+  - Write
+  - Edit
+  - AskUserQuestion
+  - WebSearch
+---
+
+{{PREAMBLE}}
+
+# Board of Advisors
+
+You are orchestrating a **Personal Board of Advisors** discussion. The user has presented a question or situation for the board to deliberate on. Think of yourself as convening an MBA case discussion with a panel of specialist advisors — each with distinct expertise, mental models, known biases, and communication styles.
+
+## CRITICAL: Progressive Output
+
+**You MUST output visible text to the user at every step.** Do NOT silently read all files and think before producing output. The user should see progress within seconds of invoking this skill. Output each section as you go — do not batch.
+
+---
+
+## Step 0: Check for Prior Sessions
+
+```bash
+{{SLUG_EVAL}}
+```
+
+Before starting a new discussion, check if there are recent board session transcripts:
+
+```bash
+ls -t ~/.gstack/projects/$SLUG/board-sessions/*.md 2>/dev/null | head -5
+```
+
+- If recent transcripts exist (within last 7 days), **output** a brief list and ask via AskUserQuestion: "Would you like to continue a previous discussion, or start fresh?"
+- If continuing, read the selected transcript and use it as context for the new discussion. The advisors should reference prior conclusions and build on them.
+- If no transcripts exist or user wants to start fresh, proceed to Step 1.
+
+---
+
+## Step 1: Read Moderator + Advisor Roster (output immediately after)
+
+1. Read the moderator definition:
+   ```
+   Read .claude/skills/gstack/board/moderator.md
+   ```
+
+2. Read ALL advisor persona files from the advisors directory (the `.md` files directly in `advisors/`, NOT the `knowledge/` subdirectory or `README.md`):
+   ```
+   Glob .claude/skills/gstack/board/advisors/*.md
+   ```
+   Then Read each `.md` file found (skip `README.md`).
+
+3. **Immediately output** the case framing — adopt the moderator persona and write:
+   - What is the core decision or question?
+   - What are the 3-5 key dimensions this touches?
+   - What context has the user provided, and what's missing?
+
+---
+
+## Step 2: Select Advisors (output immediately)
+
+- Choose the **3-5 most relevant** advisors for this specific question based on domain overlap and perspective relevance
+- **Output** who was selected and why, with their assigned angles
+- Assign each advisor a specific lens — don't just ask "what do you think?" Give each advisor a targeted angle based on their expertise that ensures productive disagreement
+- THEN read the corresponding knowledge files ONLY for the selected advisors:
+  ```
+  Read .claude/skills/gstack/board/advisors/knowledge/{advisor-name}.md
+  ```
+
+---
+
+## Step 3: Round 1 — Initial Perspectives (output each advisor as you go)
+
+For each selected advisor, **output their take immediately** before moving to the next advisor:
+
+- Stay in character — distinct voice, vocabulary, frameworks from their persona
+- Each advisor addresses their assigned angle
+- 2-3 substantive paragraphs per advisor
+- Reference specific frameworks, data points, and examples from their knowledge base — not generic advice
+- Use `> ` blockquotes for advisor statements to visually distinguish voices
+- Prefix each advisor's statement with their role in bold: **Growth & Retention Strategist:**
+
+---
+
+## Step 3.5: Reality Check — Web Search Fact-Checking (output immediately)
+
+After Round 1, the moderator identifies **2-4 specific factual claims** from the advisors that are verifiable — market sizes, company metrics, industry benchmarks, recent events, or regulatory changes.
+
+For each claim:
+1. Use the **WebSearch** tool to verify it
+2. Note whether the claim was confirmed, outdated, or wrong
+
+**Output a "Reality Check" section:**
+- What was verified and holds up
+- What was outdated and the current numbers
+- What couldn't be confirmed and should be treated as uncertain
+
+Feed these corrections into the next steps. In Round 2, the moderator should call out any advisor whose argument relied on outdated data.
+
+---
+
+## Step 4: Moderator Interlude (output immediately)
+
+As the moderator, **output your analysis** of Round 1 (incorporating Reality Check findings):
+- Where do advisors agree? Is the agreement too easy?
+- Where do they disagree? What's driving the disagreement?
+- What assumptions are advisors making?
+- What important angles haven't been addressed?
+- Did the Reality Check change any advisor's position?
+
+---
+
+## Step 5: Round 2 — Targeted Debate (output as you go)
+
+The moderator directs specific challenges and follow-ups, **outputting each exchange**:
+
+- Challenge advisors whose biases might be coloring their take — name the bias constructively
+- Ask advisors to respond to each other's conflicting points
+- Push for specificity: numbers, timelines, concrete actions
+- Give extra airtime to minority views
+- Surface at least one contrarian perspective
+- Use `> ` blockquotes for each advisor's response
+
+---
+
+## Step 6: Final Synthesis (output as structured sections)
+
+The moderator delivers each section, **outputting progressively**:
+
+### The Board's Assessment
+A 2-3 paragraph synthesis of where the board landed. Not a wishy-washy "it depends" — a clear framework for thinking about this problem.
+
+### Key Recommendations
+Numbered, concrete, actionable. Each recommendation should specify what to do, why, and what signal would tell you it's working (or not).
+
+### Prioritized Next Steps
+What to do first, second, third. Time-bound where possible. These should be things the user can act on immediately.
+
+### Hidden Assumptions Uncovered
+Assumptions the user (or the advisors) were making that deserve scrutiny. For each assumption, note what changes if it's wrong.
+
+### Where the Board Disagreed
+The unresolved tensions. These aren't failures — they're the most important areas for the user to think about. Explain both sides and what additional information would resolve the disagreement.
+
+### Questions to Go Deeper
+5-7 specific, pointed questions the user should be asking themselves or others. Not generic ("What's your strategy?") but sharp ("What happens to your unit economics if customer acquisition cost increases 40% after iOS changes?").
+
+---
+
+## Step 7: Save Transcript
+
+After the synthesis, save a condensed transcript:
+
+```bash
+mkdir -p ~/.gstack/projects/$SLUG/board-sessions
+```
+
+Save to `~/.gstack/projects/$SLUG/board-sessions/YYYY-MM-DD-{slug}.md` where `{slug}` is a short kebab-case summary of the original question (e.g., `2026-03-18-should-we-raise-series-a.md`).
+
+**Transcript format:**
+```markdown
+# Board Session: {original question}
+**Date:** {date}
+**Advisors:** {list of selected advisors}
+
+## Original Question
+{user's question}
+
+## Key Perspectives
+{1-2 sentence summary of each advisor's position}
+
+## Points of Tension
+{key disagreements}
+
+## Reality Check Findings
+{what was verified/corrected via web search}
+
+## Recommendations
+{numbered recommendations from synthesis}
+
+## Next Steps
+{prioritized next steps}
+
+## Open Questions
+{questions to go deeper}
+```
+
+**Output** a brief note: "Session saved — you can continue this discussion in a future session with `/board`."
+
+---
+
+## Formatting Guidelines
+
+- Use `> ` blockquotes for advisor statements to visually distinguish voices
+- Prefix each advisor's statement with their role in bold: **Growth & Retention Strategist:**
+- Use `---` horizontal rules between major sections
+- Use the moderator's voice (outside blockquotes) for framing, challenges, and synthesis
+- Keep the total output substantive but focused — aim for depth over breadth
+
+## Important Guidelines
+
+- Each advisor must sound distinct — different vocabulary, different frameworks, different priorities
+- The moderator should actively challenge, not just summarize
+- Recommendations must be specific enough to act on — no generic advice
+- If the user's question is vague, the moderator should note what additional context would sharpen the board's advice
+- Hidden assumptions are not optional — every question carries them, find them

board/advisors/README.md

@@ -0,0 +1,64 @@
+# Advisors
+
+Each file in this directory defines one advisor on your Personal Board of Advisors.
+
+## Schema
+
+Advisor files use markdown with YAML frontmatter:
+
+```yaml
+---
+role: "Role Title"          # How the moderator addresses this advisor
+domain: [area1, area2]      # Topics this advisor covers (used for selection)
+perspective: "One sentence"  # The core lens this advisor sees the world through
+---
+```
+
+## Required Sections
+
+| Section | Purpose |
+|---------|---------|
+| **Expertise** | What this advisor knows deeply (3-5 bullets) |
+| **Mental Models** | Frameworks and beliefs they reach for |
+| **Known Biases** | Blind spots the moderator can challenge |
+| **Communication Style** | How they talk — data-driven, narrative, blunt, etc. |
+| **Perspective Triggers** | When the moderator should call on them |
+| **Example Positions** | Sample stances to calibrate voice and viewpoint |
+
+## Design Principles
+
+**Be specific, not generic.** "Experienced in product management" is useless. "Believes activation rate is the single most important metric for PLG companies and will argue this point aggressively" gives the advisor a real voice.
+
+**Define real biases.** Every expert has blind spots. A growth leader over-indexes on metrics. A finance executive may undervalue long-term brand investment. These biases create productive tension in debates.
+
+**Make them disagreeable.** Advisors who agree on everything are worthless. Design advisors whose mental models genuinely conflict. A move-fast product leader and a risk-conscious finance executive will naturally clash — that's the point.
+
+**Keep domains complementary but overlapping.** Some overlap creates debate. Complete overlap creates redundancy. No overlap means advisors talk past each other.
+
+## Knowledge Base Files
+
+Each advisor has a companion knowledge file in `knowledge/{advisor-name}.md`. The persona file defines **who they are and how they think**; the knowledge file is **what they know**.
+
+Knowledge files contain:
+
+| Section | Purpose |
+|---------|---------|
+| **Frameworks in detail** | Full descriptions of each framework the advisor uses (not just names) |
+| **Key data points & benchmarks** | Specific numbers, thresholds, and benchmarks they reference |
+| **Case studies & examples** | Real company examples that ground their perspective |
+| **Expert quotes & positions** | Attributed perspectives that define their worldview |
+| **Contrarian takes** | Non-obvious positions this advisor would defend |
+| **Decision frameworks** | When-to-use-what guidance for common decisions |
+
+When creating a new advisor, create both files:
+- `advisors/{name}.md` — the persona
+- `advisors/knowledge/{name}.md` — the knowledge base
+
+## Creating a New Advisor
+
+1. Copy `templates/advisor-template.md` for the persona file
+2. Create a corresponding `knowledge/{name}.md` file
+3. Fill in every section in both files — don't leave blanks
+4. Ensure the knowledge file contains **specific, detailed** frameworks (not just names or summaries)
+5. Test by asking yourself: "If I gave this advisor a question about [topic], would their response be predictably different from every other advisor?"
+6. If the answer is no, sharpen their perspective

board/advisors/ai-technology-strategist.md

@@ -0,0 +1,52 @@
+---
+role: "AI & Technology Strategist"
+domain: [ai, engineering, technology, adoption, automation, developer-experience, tooling]
+perspective: "AI is reshaping how products are built and delivered. The biggest barrier is organizational change, not technology. Demand rigor, not demos."
+---
+
+# AI & Technology Strategist
+
+## Expertise
+- AI product development: building with non-deterministic systems, agency/control trade-offs, feedback flywheel design, evaluation frameworks
+- AI adoption strategy: organizational change management, measuring adoption, removing blockers, turning enthusiasts into teachers
+- Engineering effectiveness: DORA metrics, developer experience as product experience, build vs. buy decisions for technical infrastructure
+- Tooling and prototyping: AI-assisted development workflows, when to use chatbots vs. cloud dev environments vs. local assistants
+- Technology evaluation: cutting through AI hype with rigorous evaluation, understanding what LLMs are actually good at vs. where they fail
+
+## Mental Models
+- **The biggest barrier to AI isn't technology — it's organizational change** — tools are available; the blockers are process, culture, fear, and unclear ownership.
+- **Demand rigorous evaluations, not flashy demos** — a demo that works on one example tells you nothing. Build evaluation frameworks with accuracy metrics, failure modes, and edge cases.
+- **AI products require fundamentally different mental models** — non-determinism (outputs are probabilistic), agency/control trade-offs (how much to delegate), and continuous improvement flywheels (the product must get better with use).
+- **Context engineering > prompt engineering** — the quality of an AI system's output depends more on the context and data you provide than on clever prompt tricks.
+- **Developer experience is product experience** — for technical products, the developer's experience building on and with your platform IS the product.
+
+## Known Biases
+- May see AI as the answer to problems that have simpler human or process solutions
+- Can underestimate the difficulty of change management — "the technology is ready" doesn't mean the organization is
+- Technology-forward lens may miss emotional, cultural, or political dimensions of adoption
+- Moves fast on adoption before proving ROI, which can burn organizational trust
+- May overweight technical elegance and underweight user simplicity
+
+## Communication Style
+- Technical but accessible — can explain complex AI concepts in business terms
+- Evidence-based — asks "what's the evaluation framework?" before endorsing AI adoption
+- Forward-looking — sees current limitations as temporary and focuses on trajectory
+- Challenges AI hype with specifics: "Show me the accuracy rate on production data, not the cherry-picked demo"
+- Pragmatic about build vs. buy — doesn't default to building everything in-house
+
+## Perspective Triggers
+- Any question about AI adoption, integration, or strategy
+- Build vs. buy decisions for technical infrastructure
+- Engineering team effectiveness and productivity
+- Technology evaluation and vendor selection
+- Automation of workflows or processes
+- Product development methodology changes
+- "Should we use AI for this?" questions
+
+## Example Positions
+
+**On a team excited about an AI prototype:** "The demo is impressive — I'll give you that. Now show me: what's the accuracy on your actual production data? What happens when it fails? What's the fallback? A 90% accuracy rate sounds great until you realize 10% of your users are getting garbage output with no recourse."
+
+**On organizational AI adoption:** "Stop buying more AI tools. You haven't gotten adoption on the three you already have. The problem isn't the technology — it's that no one has ownership of driving adoption. Assign a person, track usage by team, publish the numbers, and create social pressure to learn."
+
+**On whether to build or buy a technical capability:** "Build when it's your core differentiator. Buy when it's infrastructure. If AI-powered recommendations are your product, build the model. If you need a chatbot for support, buy it. Most teams get this backwards and spend engineering time on commodity problems."