bootstrap-context

What this skill does

# /marketplace:bootstrap-context — Marketplace Context Extractor

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

A meta-skill that extracts company-specific marketplace knowledge from the connected stack and from a guided conversation with engineers, then generates a tailored marketplace-context skill.

## Why this exists

The marketplace plugin ships with three **general** knowledge libraries (`marketplace-pre-member-personalisation`, `marketplace-search-recsys-planning`, `marketplace-personalisation`) grounded in research and engineering literature. They describe the *principles*. They don't know the user's *specific* two-sided market, indexes, solutions, dashboards, gotchas, or golden set.

This skill bridges that gap: it generates a skill capturing everything specific to *this* company, so when the user later invokes `/marketplace:diagnose` or `/marketplace:expand-personalisation`, Claude has both the principles **and** the concrete state to act on.

## How It Works

Two modes:

1. **Bootstrap Mode** — Create a new marketplace-context skill from scratch
2. **Iteration Mode** — Improve an existing skill by adding a domain or updating a section

All other `/marketplace:*` commands check for the generated skill before running and use it as their source of company-specific truth.

---

## Bootstrap Mode

Use when: user wants to create a new marketplace-context skill for their stack.

### Phase 1: Stack Discovery

Detect which MCPs are connected. The skill works with any combination; more connected MCPs means less asking.

Check for these categories (see [CONNECTORS.md](../../CONNECTORS.md)):

- `~~search engine` — OpenSearch, Elasticsearch, Vespa, Algolia, ...
- `~~personalisation engine` — AWS Personalize, Recombee, Vertex AI, ...
- `~~product analytics` — Amplitude, Twilio Segment, Mixpanel, ...
- `~~observability` — Datadog, Grafana, New Relic, ...
- `~~data warehouse` — Databricks, Snowflake, BigQuery, ...
- `~~feature store` — Databricks Feature Store, SageMaker Feature Store, Feast, Tecton, ...

**Announce what was detected** before running any query, then proceed with targeted discovery. Examples:

**If `~~search engine` is connected:**
1. List indexes (`GET /_cat/indices` for OpenSearch/Elasticsearch, or equivalent)
2. Ask: "Which 3-5 of these are hit by production search? Which are backfill / built-once / staging?"
3. For the production indexes: pull mapping, analyzer definitions, approximate doc count, approximate size

**If `~~personalisation engine` is connected:**
1. List datasets, solutions/campaigns/recommenders, filters
2. Ask: "Which solutions are in production? Which are experimental? Which recipe does each use?"
3. For production solutions: pull recipe metadata, training metrics, dataset schema, filter definitions

**If `~~observability` is connected:**
1. List dashboards matching marketplace-relevant names: `search`, `relevance`, `homefeed`, `recsys`, `personalisation`, `conversion`, `funnel`, `recommendation`
2. For each: pull key monitors, alert thresholds, SLO definitions

**If `~~product analytics` is connected:**
1. List top events by volume in the last 7 days
2. Ask: "Which of these are impression / click / conversion events for ranked surfaces? Which lack `rank_position` or `model_version`?"

**If `~~data warehouse` is connected:**
1. List tables / views matching marketplace patterns: `events`, `impressions`, `clicks`, `bookings`, `listings`, `users`, `sessions`, `searches`
2. Sample a few rows from each to understand grain and key columns

**If `~~feature store` is connected:**
1. List feature views / feature groups / registered features
2. For each production feature: pull definition, owner, coverage, freshness, training-serving parity status
3. Cross-reference against the `~~personalisation engine` solutions to see which features feed which recipe
4. Ask: "Which features are in production? Which are experimental? Any suspected kill candidates (features not earning their maintenance)?"

Every query is **announced before running** and **read-only**. Do not write to any data source.

### Phase 2: Marketplace Fundamentals

Ask these questions conversationally (not all at once), using stack-discovery results to pre-fill context.

**Two Sides**
> "What are the two sides of your marketplace? How do they depend on each other? Is the value exchange money-for-service, service-for-service (barter), or mixed?"

Listen for:
- Side labels (e.g. "owners and sitters", "hosts and guests", "drivers and riders")
- Dependency direction (who needs whom more, and when)
- Symmetry of the value exchange
- Whether one side is typically the buyer and one the seller, or both are peers
- Frequency of participation per side (daily, seasonal, one-off)

**Monetization**
> "How does the platform make money? Subscription, per-transaction, hybrid, tiered memberships? What's the primary revenue-linked event that ranking should care about?"

Listen for:
- Subscription vs transaction fee vs hybrid vs listing fee
- Tier structure and what each tier unlocks
- Primary revenue event (membership purchased, booking confirmed, transaction completed)
- How revenue events depend on marketplace health (slow renewal game vs fast transactional)
- Whether revenue signal can be used as a ranking label (it almost always can — even for subscription, `did this session lead to first booking?` is trackable)

**Surfaces**
> "What surfaces in the product serve ranked or recommended content? Which are personalised today, which aren't?"

Listen for (prompt the user with the [surfaces-to-personalise.md](../expand-personalisation/references/surfaces-to-personalise.md) menu if needed):
- Homepage, search, category / collection pages, listing detail, messaging, email, push, onboarding, paywall, landing, saved searches, alerts, profile, zero-result fallback, abandoned-browse re-engagement, first-stay path for new suppliers
- Current personalisation state per surface (none, static, rule-based, collaborative, content-based, ML re-ranker, ML ranker, bandit)
- Which surface drives the most conversion
- Which surface is most neglected relative to its traffic

**Event Taxonomy**
> "Walk me through how impressions, clicks, and conversions are tracked. Which events are the ground truth?"

Listen for:
- Impression vs view vs hover tracking distinctions
- Whether impressions log `rank_position`, `model_version`, `surface_id`, and `request_id`
- Click attribution (to impression, to session, to user)
- Conversion events — which one is the revenue-linked one
- Known gaps and data quality issues

**KPIs and Guardrails**
> "What are the 2-3 metrics you'd protect with your life? Which ones are trending up or down right now?"

Listen for:
- North-star metric
- Supporting metrics (conversion rate by funnel stage, retention, engagement)
- Guardrails (p95 latency, error rate, infra cost)
- Current trend direction and any open investigations

**Liquidity**
> "Where is the marketplace thin? Which geos, segments, or seasons have supply-demand imbalance?"

Listen for:
- Geo thinness (city / country / region)
- Seasonal variation (peak / trough)
- Side-specific thinness (too many suppliers vs too many seekers)
- Current mitigations in flight

**Gotchas and Incidents**
> "What incidents have you had with search or personalisation? What failure patterns do you watch for?"

Listen for:
- Death spirals, popularity bias events
- Relevance regressions with root cause
- Cold-start failures
- Data quality incidents
- Feedback-loop blow-ups

### Phase 3: Generate the Skill

Create a skill directory at the path the user specified, or default to `./.claude/skills/<name>-marketplace-context/` in the current working directory.

The `<name>` should be a short kebab-case identifier — ask the user if not provided.

Structure:

```
<name>-marketplace-context/
├── SKILL.md              # Auto-generated with frontmatter + navigation
├── marketplace.