Recipes
Short, task-oriented playbooks. Each one combines a concept page with the CLI or the API — read the linked pages first if a step doesn’t make sense on its own.
Run a full session start to finish
Understand what a session is
Read The loop first — every session follows the same shape, so knowing it up front saves you from guessing mid-run.
Start the machine
Run through Quickstart if this is your first time, or The CLI for the day-to-day commands.
Work the queue
Pick up open work from Tickets — either through the app or
by listing status=open against the API.
Clear anything waiting on you
Anything that needs a human call surfaces as a gate — see Autonomy & gates for what that looks like and how to answer one.
Check the trail
When the session’s done, the evidence for what happened is never just a claim — see Evidence & glass.
Read the evidence trail for a ticket
Fetch the ticket
GET /api/v1/tickets/:id (see Tickets) — the frontmatter
field on the response carries whatever structured evidence has been attached.
Understand what “evidence” means here
Read Evidence & glass — the short version is that a claim without a link to the run that produced it isn’t considered done.
Follow the links
Any evidence reference in a ticket’s body or frontmatter points at a real artifact (a run, a screenshot, a diff) — open it rather than trusting the ticket’s prose alone.
Wire a founder gate for a deploy
Know what a gate is
Read Autonomy & gates first — a gate is a point where work stops until a human decides, not a formality.
Decide where the gate belongs
Deploys are exactly the kind of irreversible, customer-facing action that should stop for one. Put the gate before the action, not after.
Record the decision
File it as a Decision — POST /api/v1/decisions with the
choice framed, then resolve it (POST /api/v1/decisions/:id/resolve) once someone actually signs off.
Notify whoever needs to act
If the person who resolves gates isn’t watching the app, wire a
webhook on decision.resolved (or file the gate as a
ticket so it shows up in the normal queue).
Connect a service end-to-end
Start from the concept, not the button
Connect services covers the pattern: OAuth-first, with manual keys only as a fallback.
Get a token if you’re integrating by API
If the “service” you’re connecting is your own system calling into Lumis (rather than Lumis calling out to a third party), you need a Bearer token — see Authentication.
Subscribe to the events you care about
POST /api/v1/webhooks/subscriptions with the event types you want (see
Webhooks) so your system hears about changes instead of
polling for them.
Verify deliveries before you trust them
Check the X-Lumis-Signature header against your subscription’s secret —
the exact recipe is on the Webhooks page.