data-designer-new-plan

# Avo MCP — Kick Off a New Tracking Plan

This skill teaches the agent how to bootstrap a brand-new Avo tracking plan from scratch through the Avo MCP server: confirm the workspace is empty, run a purpose meeting, agree a naming convention, and seed the first categories, events, properties, and metrics — then create a branch.

For working with an *existing*, substantial tracking plan — exploring and searching, looking items up, designing tracking against what's already there, reviewing and implementing branches, cross-MCP analysis — use the **data-designer** skill instead. Quick empty check: run `search` with `itemType: "event"` and no `query`; if it returns very few results, you're greenfield and this skill applies. If the plan is substantial, switch to **data-designer**.

The Avo MCP server runs at `https://mcp.avo.app/mcp` and exposes these tools:

Read tools: `health_check`, `list_workspaces`, `get`, `search`, `list_branches`, `get_branch_details`, `get_branch_implementation_guide`, `get_branch_code_snippets`.

`get` looks up a single item by id or exact name. It supports `type` values `event`, `property`, `metric`, `category`, `propertyBundle`, `source`, `destination`, `groupType`, `eventVariant`, and `workspaceConfig`. Use `type: "workspaceConfig"` to retrieve the workspace's tracking plan audit rules — i.e. the workspace-wide event naming, property naming, casing, and validation rules — before proposing any new events or properties.

Write tools (require the `write` scope): `workflow`, `save_items`.

The MCP never merges. Merging a branch to main always remains a human step in the Avo web app.

---

## Flow 1: Start session (bootstrap)

Runs once per session, on the first prompt of any kind. Required before any other workspace-scoped tool.

Trigger: any prompt.

Steps:

1. Call `list_workspaces`.
2. If the user named a workspace (by name or id) in their prompt: set that as the active workspace, respond "Workspace set to [Workspace Name]", and continue answering the original question.
3. Else if the user has access to exactly one workspace: set it active silently and continue.
4. Else: return a numbered list of workspaces the user has access to and ask which one they would like to use. Wait for the user to select, then set it active and continue.

Hold the active `workspaceId` in conversation state for the rest of the session. Every workspace-scoped tool needs it.

---

## Design intake gate (any request to create or design tracking)

A customer will rarely hand you a clean brief. Expect "create events for onboarding" or "add tracking for checkout" — and convert it, on your own initiative, into the full workflow below *before* you propose or create a single item. A short prompt is not permission to skip any of this.

1. **Bootstrap** the workspace (Flow 1).
2. **Read the rules** — `get { type: "workspaceConfig" }` — and state the casing, structure, and tense (and word choice, e.g. past tense, "clicked" vs "pressed") you will follow. Fall back to Avo's default only if none are configured, and say so.
3. **Recon with both lenses** — a semantic `search` (by meaning) **and** a structural filter `search` (by `categories` / `sources` / `properties`) — for items that already exist, and reuse them. The two lenses catch different things; running only one misses reusable items.
4. **Anchor a purpose** — if the prompt names no goal, ask (or state the assumption for) which metric or funnel the events serve. Design to the question the data must answer, not to the feature.
5. **Deliver** events (each in a category) **plus at least one metric you propose** (e.g. a conversion or drop-off funnel metric), tied to that purpose, in the workspace convention.

This skill covers the **empty / near-empty** case — follow **Flow 6** below. If recon shows the plan is already substantial, switch to the **data-designer** skill (Flow 7, Design data for a product update).

---

## Flow 6: Kick off a new taxonomy

For a brand-new workspace or one with no real tracking plan yet. The point is to bootstrap problems and metrics first, then a naming convention, then a starting set of categories and events. Do not jump straight into creating events.

Trigger prompts:
- "We're new to Avo, where do we start?"
- "Help us design our first tracking plan"
- "Set up tracking from scratch"
- "What should we track?"
- "Bootstrap a tracking plan for our product"

Steps:

1. Confirm the workspace is empty or near-empty. Run `search` with `itemType: "event"` and no `query` (filter listing mode); if it returns very few results, treat this as a fresh start. If the plan is substantial, redirect to the **data-designer** skill (Flow 7, Design data for a product update).
2. Ask the user about the product. What does the product do, who are the users, and what stage of growth is it at? Keep this short; one or two sentences is enough to anchor the rest.
3. Run the purpose meeting checklist with the user before designing anything:
   - "What topics does this release cover?"
   - "What problems is the team trying to solve?"
   - "What goals and metrics will tell us we're succeeding?"
   - "Which one or two user funnels matter most right now (signup, checkout, onboarding, etc.)?"
   
   Wait for the user's answers before proposing structure. If answers are vague, push back: good tracking design starts from the question the data needs to answer.
4. Propose a naming convention. Default to Avo's recommendation unless the user already has a convention or their analytics destination demands otherwise:
   - Structure: object-action (e.g. `Signup Completed`)
   - Casing: Title Case
   - Tense: past tense
   
   Show the user one or two example events in their proposed convention, name the three dimensions explicitly (structure, casing, tense), and ask them to confirm or adjust. Capture the chosen convention so subsequent steps stay consistent.
5. Propose a starting set of categories that mirror the funnels the user named. Pick a small subset (three