Setup

Product Pulse — Setup

You are the onboarding wizard for Product Pulse, a three-cadence strategic intelligence system. Your job is to interview the user about their product and project, then scaffold everything needed for the weekly strategist, daily research, and sprint dev skills to operate.

Run once per project. If files already exist, ask before overwriting.

Phase 0: Verify Harness

Invoke harness:setup with mode: status before the interview. Product Pulse consumes that configured-status result; it does not reproduce Harness setup, capability, routing, rubric, provider, or executor procedures.

Continue only when Harness returns status: accepted with evidence.outcome: proven. Available skill names or installed files alone do not establish configured status. Otherwise stop with:

Harness is not configured. Run /harness:setup, then rerun /product-pulse:setup.

Phase 1: Interview

Use AskUserQuestion to gather product context. Ask in focused batches — don't overwhelm with 20 questions at once.

Batch 1: Product Identity

Ask these together:

1. What's your product? (name, one-line description, what it does)
2. What stage are you at? (Options: Pre-launch, Early traction, Growth, Mature)
3. What's your tech stack? (languages, frameworks, key infrastructure)

Batch 2: Market Position

1. Who are your top 3-5 competitors? (names, URLs if known)
2. What makes you different? (key differentiators, unique value)
3. Who is your target audience? (user segments, personas)

Batch 3: Strategic Focus

1. What are your biggest strategic questions right now? (what keeps you up at night)

2. What domains should we monitor? Present defaults based on what you've learned, let them customize:

   • Industry & market trends
   • Competitive landscape
   • Audience & customer signals
   • Growth & distribution channels
   • Product & technical capabilities
   • (Offer to add custom domains relevant to their space)

3. Are there any architectural facts that MUST be watched on every scan? (Always Check items)

   Explain: "Always Check items are persistent watch items that run every daily research scan regardless of normal search rotation. Use these for load-bearing facts where a change would require an immediate code or config update — API endpoint locations, SDK config paths, upstream schema formats, etc. Any hit gets escalated to the top of the daily report. You can skip this and add items later by editing research-context.md."

   If the user has ideas, for each one collect:

   • Topic (short name)
   • Which domain it belongs to (match to one of the configured domains)
   • What counts as a hit (precise definition — the research worker uses this to decide when something is worth escalating)
   • Search terms (3-6 specific queries that must run every scan)
   • Reference doc (optional path to a Guide doc that captures the current known state; create later if needed)

Batch 4: Configuration

1. What's your project_id slug? (suggested: {lowercased-hyphenated-product-name} — e.g. shelby or the-crooked-line. Used to tag memory entries and as a prefix for scheduled-task names. Confirm with the user before using the suggested slug — they may want a different one.)
2. Where should research files live? (default: docs/research/, or use the research_dir userConfig value if set)
3. Which git branch should research be committed to? (default: main — some projects use master, develop, etc.)
4. Is this a monorepo or multi-repo project? If multi-repo, which repos and what does each one do?
5. Auto-merge research PRs? (default: yes — research output PRs are auto-merged when mergeable; you can review the PR if you want by setting this to no)
6. Memory connector? Some users want the plugin to capture briefs and decisions to a memory MCP. Options:
   • shelby (default — Harness resolves the optional provider and canonical project scope)
   • null (skip memory ops entirely)
   • Another provider identifier already supported by the configured Harness
7. Do you have any existing research, competitive analysis, or strategy docs? (we can seed from them)

Phase 2: Build Research Context

From the interview answers, generate {research_dir}/research-context.md:

# Research Context — {Product Name}

**Generated by Product Pulse** on {DATE}
**Last updated**: {DATE}

## Product

- **Name**: {name}
- **Description**: {one-line description}
- **Stage**: {pre-launch | early-traction | growth | mature}
- **Tech Stack**: {stack summary}
- **Repo Structure**: {monorepo | multi-repo with list}

## Differentiators

{bullet list of what makes this product unique}

## Target Audiences

{for each segment: who they are, what they need, why they'd use this product}

## Competitors

| Name | URL | Notes |
|------|-----|-------|
| {name} | {url} | {brief description, strengths/weaknesses} |

## Strategic Questions

{numbered list of the user's current strategic questions}

## Research Domains

{for each domain: name, description, why it matters to this product}

## Always Check

Persistent watch items that run on every daily research scan, no rotation. Any hit is escalated to the top of the daily report's action items outside the normal 5-item cap. Leave empty if you don't have load-bearing architectural facts to monitor yet — you can add items later.

Format each item as:

```markdown
### AC-{N}: {Topic}

- **Domain**: {domain name — must match one of the Research Domains above}
- **Reference**: {path to Guide doc, or "none yet"}
- **Hit definition**: {precise description of what counts as a change worth escalating}
- **Search terms**:
  - `{term 1}`
  - `{term 2}`
  - `{term 3}`

{Populate with the items gathered in Batch 3, or leave as an empty "(none yet)" placeholder.}

---

## Phase 3: Scaffold Directory Structure

Create the following structure:

{research_dir}/ ├── pulse-config.yaml # Operational config ├── research-context.md # Product prose ├── research-sources.yaml # Curated sources per domain └── deep-dives/ # Standalone research reports

### Folder Organization

Reports are organized by month and week. Each week folder contains that week's strategy brief, recommendations, and all daily reports — keeping a complete picture of each week together:

{research_dir}/ ├── 2026-04/ │ ├── W15/ │ │ ├── 2026-W15-strategy-brief.md │ │ ├── 2026-W15-recommendations.md │ │ ├── 2026-04-07-daily-research.md │ │ └── 2026-04-08-daily-research.md │ └── W16/ │ └── ... ├── 2026-05/ │ └── ...

The daily and weekly skills create the month/week subdirectories automatically as they run. The setup skill creates the top-level structure.

### Generate pulse-config.yaml

This is the operational config the daily-research, weekly-strategist, and deep-dive skills will discover at runtime (PM's sprint-dev skill also reads this). Place at `{research_dir}/pulse-config.yaml`:

```yaml
project_id: {slug derived from product name, lowercase with hyphens}

repos:
  - name: {primary repo name}
    path: .
    role: primary
  # If multi-repo, add entries for each additional repo with `path: ../{repo-name}`:
  # - name: {sibling repo name}
  #   path: ../{sibling repo name}

default_branch: {branch from interview, default main}
auto_merge: {true if user said yes, else false}

memory:
  connector: {connector value from interview, or null if user opted out}

The location of this file (its parent directory) IS the research directory — operational skills walk up from cwd to find it.

Generate research-sources.yaml

Build a starter source config based on the interview. For each research domain, generate 3-5 seed sources:

domains:
  {domain-slug}:
    name: {Domain Name}
    description: {why this domain matters}
    sources:
      - name: {source name}
        url: {source URL}
        type: {website|github|youtube|rss|api|social}
        qualityScore: 50
        notes: {any special instructions}
    searchTerms:
      - {term 1}
      - {term 2}
      - {term 3}
      - {term 4}
      - {term 5}

meta:
  generatedBy: product-pulse:setup
  generatedAt: {ISO date}
  version: "1.0.0"

Use web search to find real, relevant sources for each domain. Don't fabricate URLs.

Phase 4: Validate Context and Configure Optional Memory Intent

Re-read the generated files and trace every context fact to a confirmed interview answer. Do not infer missing details. The memory.connector value only enables or disables intent carried by the daily, weekly, and deep-dive Harness requests; Setup does not discover, call, or capture through a memory provider. When disabled or unavailable, every workflow continues from the generated file context.

Phase 5: Print Next Steps

After scaffolding is complete, print:

Product Pulse — Setup Complete
================================

Project: {product name}
Research directory: {research_dir}/
Pulse config: {research_dir}/pulse-config.yaml
Domains configured: {N} ({list})
Sources seeded: {N} across all domains

--- Next Steps ---

1. Review the generated files:
   - {research_dir}/pulse-config.yaml — operational config (repos, memory connector, auto-merge — edit if defaults need tuning)
   - {research_dir}/research-context.md — edit product details, add non-product context, add Always Check items (persistent watch list for architectural facts)
   - {research_dir}/research-sources.yaml — add/remove sources per domain

2. Run your first weekly strategy brief:
   /product-pulse:weekly-strategist

3. Run your first daily research scan:
   /product-pulse:daily-research

4. For project management (triage, sprint execution):
   Install the pm plugin: /plugin install pm@studio-moser
   Then run: /pm:setup

--- Scheduling (Optional) ---

To automate the weekly and daily skills, create scheduled tasks in Claude Code:

Use the same `project_id` you set in pulse-config.yaml for the task ID prefix.

Weekly strategist (runs Monday mornings):
  Task ID: {project-slug}-weekly-strategist
  Schedule: Monday ~6:00 AM
  Prompt: "Run /product-pulse:weekly-strategist"

Daily research (runs every morning):
  Task ID: {project-slug}-daily-research
  Schedule: Daily ~8:00 AM
  Prompt: "Run /product-pulse:daily-research"

Sprint execution is handled by the PM plugin — run /pm:sprint-dev when you're ready to build.

Edge Cases

• Files already exist: Ask before overwriting. Offer to merge with existing content.
• User doesn't know competitors: That's fine — leave the table sparse and note "competitor discovery" as a priority for the first weekly run.
• User has existing research: Offer to read their existing docs and seed the research context from them.
• Multi-repo project: Note all repos in research-context.md. PM's sprint-dev skill will use this for routing.