Recipes

A recipe is a versioned GTM playbook: one motion written out with its prerequisites, credit posture, approval gates, and steps. Categories, each phrased as the question it answers: start-here, pipeline-from-zero, catch-warm-signals, linkedin-engine, convert-faster, revenue-truth, agency-scale.

Recipes are advisory. Reading or installing one costs 0 credits and changes nothing outside the wiki. The paid steps inside a play run through their own primitives, with their own --approved and --max-credits gates.

Start with this one

oxygen recipes show day-1-first-win --json

If you have no play running yet, run that one. In one free session day-1-first-win writes down what you sell and who buys it, builds a table of about ten people to contact first with the reason for each, and drafts first messages for the top few. Warm contacts (customers, open deals, unanswered replies, your LinkedIn network) come first when the workspace has them; otherwise a free search finds people who match your buyers. Nothing is sent and no credits are spent.

Find the others

oxygen recipes list --stage day-1 --json
oxygen recipes list "outbound" --category pipeline-from-zero --json
oxygen recipes list --audience agency-operator --json

--stage takes day-1, day-7, day-30, or ongoing. --audience takes founder, gtm-operator, or agency-operator. An unknown value is rejected with the allowed list.

In the browser, the catalog is Plays (/plays): open Settings at the foot of the sidebar and choose Plays, or follow All plays on Home. The web app calls a recipe a play, and a play is a prompt. Each card shows the play's icon, its name and one line on what it gets you, with a Copy prompt button: paste the prompt into the agent you connected to OXYGEN (Claude, Codex or another MCP client) and it runs the play from your workspace. The prompt is the play's request in your own words, then one line naming the play and your workspace and asking the agent to check that workspace and the folder it is working in, then show the plan and its cost first. One search box ranks plays the same way oxygen recipes list "<goal>" does; without a search, the page shows the featured plays first and then every other play under its category. Home shows the featured plays as the same cards. /recipes, /recipes/<slug> and /plays/<slug> land on Plays with that play's card highlighted.

Read one

oxygen recipes show outbound-pilot-50 --json

You get the full body plus the frontmatter facts. The body has four sections, always in this order: The Play (what you get and when it fits), Before You Start (what must exist, the command that checks it and what it costs), Steps and If It Goes Wrong. The frontmatter facts are: outcome, leading metric, a labelled benchmark range, effort, pilot and full credit cost, prerequisites with the check command for each, and the approval gates. A play has no page of its own in the web app: its card is the play, and your agent reads these facts when it opens the play. recipes list --view summary also returns each play's summary (the card's line) and prompt (what Copy prompt copies).

On 2026-10-04 the catalog went from 33 plays to 13: plays that repeated another became options inside it. An old play's name still works. oxygen recipes show competitor-post-engagers --json opens inbound-led-outbound and says so first, and a play that was cut answers recipe_retired with what to use instead.

Every paid or external step in the body is marked > APPROVAL GATE — <slug> and names what you must see before approving. A recipe marked trial-safe keeps its pilot path at or under 100 credits.

Install one

oxygen recipes install outbound-pilot-50 --draft --json

This writes the play into your workspace wiki as a page at playbook-<recipe-slug> — revisioned, searchable, and readable by your agent. Automatic retrieval of wiki pages into AI columns and drafts is built but switched off in production, so an installed playbook is something your agent opens on purpose, not something injected into every AI call. --draft installs it inactive. Edit it freely afterwards; a re-install refuses to clobber your edits unless you pass --force, and --slug <wiki_slug> installs under a different name instead. Read the result with oxygen knowledge page get playbook-outbound-pilot-50 --json or open the returned link at /knowledge/pages/<slug>.

Three different things are called "recipe"

The kit: install a whole motion in one step

A play that needs several blueprints in order carries them as its kit — an ordered list of stages, where a later stage's table input is bound to the table an earlier stage created. oxygen recipes apply installs the whole thing under one approval instead of making you apply each blueprint by hand and copy table ids between them.

oxygen recipes show inbound-led-outbound --json         # the kit, and which stages you already have
oxygen recipes apply inbound-led-outbound --dry-run --json   # preflight every stage, one forecast
oxygen recipes apply inbound-led-outbound --json             # install, 0 credits, workflows disabled

Applying a kit spends 0 credits, makes no provider calls and writes nothing outside your workspace. Every workflow it installs arrives disabled. Installing is not permission to run, enable, enroll, send or spend — each of those still asks you separately, with its own preview and cap.

Re-running apply is safe: a stage you already have is reported as reused, and a stage whose workflow is currently active is skipped rather than replaced, so a reapply can never switch a live motion off. A stage that is republished comes back disabled and needs enabling again — workflow authority is bound to the revision you approved.

Blueprints on their own

Some recipes name a single blueprint that builds the infrastructure the play needs. outbound-pilot-50 names dm-outbound-pilot; the recipe still works without it. You can always work a blueprint directly:

oxygen blueprints list --json
oxygen blueprints describe dm-outbound-pilot --json
oxygen blueprints preflight dm-outbound-pilot --json   # 0 credits, no workspace change
oxygen blueprints apply dm-outbound-pilot --json       # 0 credits, creates workspace objects

Preflight first: it validates inputs against your workspace, reports the per-run credit ceilings you would face later, and returns the exact apply command that preserves the inputs you validated. apply spends no credits and makes no provider calls, but it does create tables, columns, prompt templates, and a workflow — left disabled, so nothing runs until you enable it.

To go the other direction, oxygen blueprints export --workflow <id> --out ./my-play.json bundles a workflow you built, oxygen blueprints save --file ./my-play.json stores it in this workspace, and oxygen blueprints share <slug> returns a public oxygen-agent.com/b/<code> URL anyone can apply.

Blueprints has its own sidebar item under Knowledge, labelled Blueprints and pointing at /blueprints — separate from Recipes, which points at the playbook catalog above. It is beta-gated: it stays hidden until an admin turns on Beta features in organization settings (/settings#/beta-features). The route itself works by URL either way. Recipes is not gated. /blueprints/<slug> lists What this blueprint creates, then Apply via CLI and Share with someone else as copy-paste commands — there is no create button, because blueprints are authored from the CLI.

From MCP

Find Recipe and Blueprint tools with oxygen_capabilities_search, then load the selected schema. Use oxygen_capabilities_read to list, describe or preflight and oxygen_capabilities_call to apply a reviewed Blueprint. Both runners work from core; ?toolset=knowledge optionally lists the tools directly. Per-tool detail: MCP tool reference.