Skip to main content
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:
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.
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.
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

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.
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:
Use a title when you already know the journey:
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:
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 to refine stages, steps, and items.