# Weir

**Onboarding as code. Shipped without another app build.**

Coding agents author specVersion-4 onboarding flows as JSON config in the app's own repository.
The SDK renders those flows with stock components and app-owned custom components. Compatible
copy, ordering, theme, and flow changes can be delivered to an already-installed app; adding a new
native component type still requires an app release. Signed delivery, component-registry and app
version gates, an embedded baseline, and a kill switch are designed to keep an incompatible remote
config from replacing the fallback shipped with the app.

Weir also defines the event contract and experiment surface underneath the flow. The v4 API,
delivery path, and dashboard are live for a controlled private alpha. Public health reports
`specVersion: 4` and identifies the deployed release artifact by commit and release version.
That traceability is alpha operating evidence; do not read this as production-proof, broad
self-service availability, or a conversion claim.

This site is written for the agent doing that authoring — Claude, Cursor, or anything else
working inside an app repo. Almost everything here has a companion tool call. The one exception is
a human reviewing an already-published flow and leaving comments — see [Review a flow](/docs/review/).
If you are an LLM reading this page, also fetch
[`/docs/llms-full.txt`](/docs/llms-full.txt) for the entire site concatenated as clean markdown.

## Why the repository workflow matters

The flow spec and app-owned component contracts live beside application code, so an agent can
author them, validate them, and put them through normal source review. The MCP toolkit, CLI, and
skill described on this site are the authoring surface; the dashboard operates the published-flow
lifecycle (publish/rollback, experiments) and review.

That workflow is not based on competitors lacking agent tools. Superwall, for example, publicly
documents an account-management MCP, an editor MCP, a skill, CLI tooling, and onboarding Flows.
Weir's intended distinction is narrower: composing the app's own registered native components
through a repository-owned flow contract, with compatibility gates and an app-shipped fallback.
See [Superwall's MCP documentation](https://superwall.com/docs/dashboard/guides/superwall-mcp) and
[onboarding Flows documentation](https://superwall.com/docs/dashboard/guides/using-superwall-for-onboarding-flows)
for the capabilities that comparison acknowledges, and [the native component model](/docs/concepts/#the-native-component-model)
for Weir's product model.

## The 30-second loop

1. **Author** a flow spec — JSON describing screens, branching, and variables — in the app's own
   repo, under `weir/flows/`. If it uses any custom native components, register them once with
   [`weir components sync`](/docs/concepts/#custom-components-and-the-component-manifest).
2. **`weir release`** — validates, runs the contract gate, and publishes the signed config to the
   configured delivery origin.
3. **A compatible installed app can update.** Its update check fetches and verifies the config,
   then promotes it only when the app, SDK, spec, and registered-component gates match. New native
   component types still ship in an app build.

```
edit weir/flows/onboarding.json
  -> weir release --appRoot . --flowId onboarding
    -> relaunch the already-installed app
      -> new onboarding renders; the event lands in weir funnel
```

## Scope, honestly

Onboarding flows only, today. To be precise about what that means: a flow *can* contain a
`paywall` screen, and the iOS SDK ships a working StoreKit 2 purchase client so that screen's CTA
completes real purchases inside the onboarding flow. What Weir does **not** do yet is standalone
paywall *management* — placements, audience targeting, paywall-only experiments, sheet
presentation outside a flow. That layer stays on a dedicated paywall tool (e.g. Superwall) until
Weir builds it.

**Platforms, honestly:** the v4 SwiftUI implementation for iOS and the React Native/Expo
implementation for iOS and Android both exist, including the RN native module and Expo config
plugin, and are integrated into the two dogfood applications. Qualified SwiftUI and React Native
dogfood evidence exists, but public package/reproducibility and the final evidence matrix remain
release gates, so neither path is presented here as production proof. The Kotlin/Compose renderer
also exists, with automated implementation evidence; its final device journey and immutable public
distribution are incomplete, so it is not a supported public platform yet. The retired WebView
delivery architecture is historical and is not the v4 product described here.

## Where to go

- **Setting up the toolkit?** [Install the Weir skill / MCP server](/docs/install/) registers the
  `weir_*` tools in your agent host.
- **Want no account and no server URLs?** [Run everything locally](/docs/local/) is the whole loop
  on one machine.
- **New to an app?** Start at [Quickstart](/docs/quickstart/).
- **Know the tool/node/event name you need?** [Reference](/docs/reference/) is one page, deep-linkable.
- **Want the delivery/signing/kill-switch model?** [Concepts](/docs/concepts/).
- **Operating a live flow?** [Monitoring](/docs/monitoring/) and [Experiments](/docs/experiments/).
- **Checking exactly what is proven today?** [Evidence status](/docs/evidence/) distinguishes the
  public local loop, qualified dogfood evidence, and the release gates that remain.
- **Reviewing a flow before or after it ships?** [Review a flow](/docs/review/) — the one page in
  this site for a human, not an agent.
- **An agent that just wants the whole site as text?** [`llms.txt`](/docs/llms.txt) /
  [`llms-full.txt`](/docs/llms-full.txt).