---
name: flowdar-instrumentation
description: Set up Flowdar (also spelled Flodar), install its SDK, instrument an app, and design a readable event plan with a visual review. Use when a user asks to set up Flowdar analytics, sign up and configure tracking, or change instrumentation. Covers core, streaming, ecommerce and custom industries; account signup availability must be checked separately.
---

# Flowdar instrumentation

Implement deliberate business events in the customer's application, with a local
tracking-plan JSON as the contract. This skill works without a Flowdar login, MCP
connection, or network schema lookup. It is shared guidance for OpenAI and Claude
coding agents, not a vendor-specific tool integration.

## Customer-controlled scope

- Do not add testing, test execution, a testing-permission request, or live-event
  verification to this skill's workflow. Follow testing instructions only when
  independently chosen by the customer or their project. Do not ask whether they
  want tests or make completion depend on tests being run.
- Do not prompt for a Flowdar login, token, MCP connection, credentials, or access
  for the agent as an installation prerequisite. Do not try to discover or connect to an account unless explicitly requested. If the customer
  independently directs authorized use of an existing connection, read
  [connected-mode.md](references/connected-mode.md); otherwise stay local.
- A request such as "sign us up for Flowdar and set it up" explicitly includes
  account setup. Read [onboarding.md](references/onboarding.md). This is not a
  requirement for ordinary instrumentation requests. Never invent a signup tool,
  free-tier allowance, account, credential, or password-setting link.
- Work within the application files/tools already available. Do not request more
  repository access as part of this skill. Where files are unavailable, supply
  the plan and concrete integration instructions appropriate to the available context.
- A missing collector URL is a local configuration slot, not a reason to ask for
  credentials. Leave capture disabled until the customer configures it. Do not
  send to an invented host or ship a dummy endpoint as a live configuration.

## Design the plan

Read [event-design.md](references/event-design.md). Inspect existing instrumentation
and the relevant routes, identity flow, domain models and authoritative outcome
handlers available in the task. Preserve existing customer naming and contracts;
never silently rename or double-instrument a live event.

Start from the relevant pack, using only events applicable to this application:

- [Core](assets/plans/core.json): navigation, authentication, search and failures.
- [Streaming](assets/plans/streaming.json): core plus playback and subscriptions.
- [Ecommerce](assets/plans/ecommerce.json): core plus cart, checkout and orders.
- Other industries: start from core and use [custom-industry.md](references/custom-industry.md).

Store a project-owned `flowdar.plan.json`, conforming to
[plan.schema.json](assets/plan.schema.json), with a customer-specific stable `id`,
human name and version. Define meaningful triggers and property descriptions.
Remove irrelevant template events; do not invent features or instrument every click.
Keep stable event keys and simple scalar properties. Use a property for entity IDs
and screen names, never a dynamically generated event name. Keep custom extensions
distinct (for example `custom_quote_accepted`) until an explicit standard is adopted.

## Show the plan

Always generate a local `flowdar.plan.html` from the final `flowdar.plan.json` using
[review.md](references/review.md), and present a clickable link to the user. The
viewer contains the complete plan, searchable events and properties, examples,
and approval/change-request controls. It works offline and needs no Flowdar account.
Keep it current when the plan changes. Never author a parallel HTML event list that
can drift from the JSON, and never interpret opening the viewer as approval.

Follow the customer's chosen approval process. If they require sign-off before
instrumentation, show the plan first and wait for that decision. Otherwise complete
the authorized implementation and present the viewer for review at handoff. A
single setup request authorizes work, not a fabricated human review receipt.

## Implement

Read [sdk-integration.md](references/sdk-integration.md) for the actual SDK API and
packaging limits. For React Native Android/iOS apps, also read
[react-native.md](references/react-native.md) and use the bundled mobile package.
Add one application-owned analytics adapter; UI components call
that adapter, not dozens of separately initialized SDK clients. Respect existing
consent, identity, error-reporting and configuration conventions.

Implement selected events at their defined trigger, from the designated producer.
Use the standard `screenView` / `pageView` helpers for new consistent navigation
tracking. Existing `screen` / `page` methods retain their legacy naming semantics.
Map legacy instrumentation deliberately rather than sending both names.

Pass the local plan to the SDK for diagnostic validation. Capture failures must not
break checkout, playback or navigation: handle rejected capture promises using the
application's existing diagnostics. Do not silently claim successful delivery.

## Handoff

Describe the plan version, implemented events, trigger locations, and configuration
slots that remain unset. Distinguish implemented instrumentation from actual event
delivery without requesting live access or suggesting a testing step. Never claim
an installation was executed, published or observed in Flowdar unless that happened.
Include the plan JSON, HTML viewer, any human review receipt, and a concise list of
completed versus unavailable account steps. These outputs are part of the normal
workflow; the user does not need to remember a special prompt.