OXYGEN Recipes

Recipes teach a proven motion; they are not a hidden execution runtime. Their steps call ordinary native primitives with ordinary previews, approvals, caps, and observability.

Start here

"What should I do first?" gets one named play, not a catalog to browse:

oxygen recipes show linkedin-network-first-motion --json
oxygen recipes list --stage day-1 --json
oxygen capabilities search "proven play for <goal>" --json

linkedin-network-first-motion turns the LinkedIn network the founder already has into captured, deduped rows, then — once they approve a standing grant — a capped warm sequence. It is the day-1 default because it needs no list, no domain, and no email infrastructure. Read it before proposing it — the caveats it carries (capture drips over days; reaching the existing network is opt-in) must be stated before anyone approves, not after.

Otherwise pick from recipes list (also filtered by --audience and the later --stage values), hydrate only that Recipe with recipes show / oxygenrecipesget, and install it when the user wants a durable workspace copy. If a Blueprint is included, it may scaffold hosted Tables, Workflows, or Sequences; inspect its preflight before applying.

Boundary

• Do not load the entire Recipe corpus into context.
• Do not treat a Recipe as mandatory architecture; the primitives stay composable.

Follow the selected file verbatim where it defines ordering, but use live command/schema discovery for exact flags, current provider readiness, and cost. Return deep-links for every created native object and run.