# Instrument Feature Analytics

Plan analytics instrumentation for a feature.

- Repository: https://github.com/mistralai/mistral-vibe (5270 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mistralai/mistral-vibe --skill instrument-feature-analytics -g -a claude-code -y`
Codex: `npx skills add mistralai/mistral-vibe --skill instrument-feature-analytics -g -a codex -y`
Cursor: `npx skills add mistralai/mistral-vibe --skill instrument-feature-analytics -g -a cursor -y`
Gemini CLI: `npx skills add mistralai/mistral-vibe --skill instrument-feature-analytics -g -a gemini-cli -y`

## Description

Plan analytics instrumentation for a feature. Use when implementing any feature, every feature must ship with telemetry. Decides which events and properties the metrics need (funnels, adoption, status flows), checks compatibility with the existing datalake and event registry, and walks through local, staging, and production verification.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Instrument a Feature for Analytics

Answer the tracking questions a software engineer would normally take to a data scientist or data engineer. When they bring one here, answer it the way a data person would, and proactively cover what they didn't think to ask.

The software engineer already knows how to emit an event technically. The hard part, and the reason they'd normally ask a data person, is deciding *which* events and properties matter for the metrics, and making sure they fit what already exists so the data is actually usable. Events land in `mistral-data.lake_eu.logs_events`.

Use the steps below as the full picture to reason from, not a rigid script: if the software engineer arrives with a specific question, answer that first, then pull in whatever other steps are relevant. If they arrive with "I'm adding feature X, help me track it", walk it in order.

## Process

### 1. Understand the feature and the metrics behind it

Ask the software engineer a few questions before anything else:

- **What is the feature?** (a new onboarding step, a way to discover a feature, a status/lifecycle change, an action users repeat…)
- **What will product and data want to measure about it?** Adoption? A funnel and where people drop off? How often a status changes? Whether a surface gets noticed?

Then translate those questions into the events and properties that would answer them. Common patterns:

The rest: https://github.com/mistralai/mistral-vibe/blob/HEAD/.vibe/skills/instrument-feature-analytics/SKILL.md
