> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usecustory.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Create a first journey

> Use website, private brief, or standard input context to create a verified journey.

Use this page when you know the journey you want to create and need the right CLI input method.

## What this is

`custory init` creates a first customer journey from product context.

The context can come from:

* a public website
* a private text brief
* standard input from another command or coding agent

Custory uses that context to suggest a source interpretation, a journey, personas, stages, steps, and starting items.

## Why it matters

The CLI is useful when the best source material already exists outside the dashboard.

For a lean team, that usually means less copying between tools and a faster path to a shared map of the customer experience.

## Interactive setup

Use the interactive flow when a person is making decisions:

```bash theme={null}
custory init
```

The CLI asks for the workspace, role, desired outcome, source type, journey choice, source confirmation, and persona confirmation.

This is the safest default because you can reject a weak interpretation before Custory writes the journey.

## Use a public website

Use `--website` when a public page explains the product clearly.

```bash theme={null}
custory init \
  --workspace "Acme" \
  --website https://acme.com \
  --journey recommended \
  --yes
```

Use this for marketing sites, product pages, or docs pages that describe the customer flow.

Do not use it for pages that require login, contain little product context, or represent a different product than the workspace.

Good website URLs are usually homepages, product pages, docs overview pages, onboarding docs, pricing pages, or public pages that explain what the product does and who it is for.

Avoid login, signup, dashboard, account, admin, cart, checkout, privacy, terms, legal, cookie, GDPR, and imprint routes.

## Use a private brief

Use `--brief` when the best context is private, internal, or not available on a public page.

```bash theme={null}
custory init \
  --workspace "Acme" \
  --brief ./product-context.md \
  --journey recommended \
  --yes
```

A good brief includes:

* what the product does
* who the customer is
* the first outcome customers want
* the steps they take to get there
* important touchpoints such as pricing page, signup form, invite flow, onboarding email, support chat, or billing page
* known friction, unanswered questions, and evidence gaps

Do not include secrets, credentials, source code, private customer records, access tokens, or API keys.

### Small brief example

```text theme={null}
Acme helps B2B SaaS teams find trial users who are stuck before activation.
The primary user is a founder or product lead at a 10-50 person SaaS company.
The first valuable outcome is connecting product analytics and identifying
which onboarding step blocks the most trial users.

Important touchpoints: pricing page, signup form, workspace creation,
PostHog connection, activation dashboard, weekly email, and support chat.

Known friction: users are unsure which event to choose as activation, and
some invite their team too late.
```

From a brief like this, Custory may create an illustrative journey such as **Trial user activation**, with stages like **Evaluate**, **Sign up**, **Connect data**, **Find friction**, and **Act on the insight**.

It may suggest a founder/product lead persona, steps such as **Creates workspace** and **Connects PostHog**, and starting items such as assumptions about activation-event confusion or delayed team invites.

That output is not deterministic. Use it as a reviewable starting point.

## Use standard input

Use `--stdin` when another tool prepares the context.

```bash theme={null}
generate-product-context | custory init \
  --workspace "Acme" \
  --stdin \
  --journey recommended \
  --yes \
  --json
```

This is a good fit for coding agents. The agent can summarize relevant, non-secret product context and pipe that bounded summary into Custory.

Custory does not read your repository. The CLI only receives the text you pass through `--brief` or `--stdin`.

## Choose the journey

Use the recommended journey when you want Custory to choose the best starting point from the source:

```bash theme={null}
custory init --workspace "Acme" --website https://acme.com --journey recommended --yes
```

Use a title when you already know the journey:

```bash theme={null}
custory init \
  --workspace "Acme" \
  --brief ./activation.md \
  --journey "New user activation" \
  --yes
```

Good first journeys are narrow:

* new user onboarding
* activation
* trial to paid
* support escalation
* renewal risk

Avoid asking the CLI to map the whole customer lifecycle on the first run.

## What `--yes` confirms

In non-interactive setup, `--yes` lets the CLI accept required source and persona confirmations.

Use `--yes` when:

* the source context is prepared intentionally
* the run is part of a script
* you are comfortable reviewing and refining the result after creation

Do not use `--yes` when the input is vague, untrusted, or generated from a source you have not reviewed.

Some low-confidence persona recommendations can still require explicit confirmation.

If the source interpretation is weak, rerun with a better URL or a clearer `--brief`. Do not use `--yes` to push through weak input unless you expect to heavily edit the result.

## What verified means

From your perspective, verified means Custory read back the saved result and confirmed the basic structure exists.

The verification checks include the workspace, journey name, ordered stages, steps inside stages, linked personas, valid item placements, and no pending writes.

Verified does not mean every assumption is correct. It means the journey was created, stored, and is ready for human review.

## Recovery

If setup stops before completion, resume the latest unfinished run:

```bash theme={null}
custory init --resume
```

If the session expired or no unfinished setup exists, start a new run.

Retries are designed to avoid duplicate workspaces and duplicate journeys for the same installation, but you should still check the final Custory URL before starting another create attempt.

Resume is scoped to the latest unfinished setup for the local installation identity. New non-interactive create runs use idempotency internally for that run, but an expired session should still prompt a manual check in Custory before starting over.

## Next step

After creation, open the journey and read [Journey editor](/journey-editor) to refine stages, steps, and items.