Load or author oto INSTRUCTION PROSE — a how-to loaded when needed, or a readme injected into every session. Two axes: scope = platform | tenant | org | group | user (who writes it, whom it applies to) and delivery = 'on-demand' (default: a guide you load for a task) | 'init' (a readme concatenated into what you receive at handshake). op=list → the on-demand catalog you can see (platform ∪ your org ∪ your own) ; op=read (slug, optional scope) → its markdown body and rev ; op=write / delete (slug, scope, body_md, title?, description?) → author for the PLATFORM (platform admin), a TENANT (its tenant admin or a platform admin; owner_id = the tenant slug, which also reads it back), your ORG (org admin), your TEAM (team lead) or YOURSELF (scope=user, the default). With delivery='init' the slug is canonical per scope — omit it (the user's own readme is scope='user', delivery='init'; an empty body clears that layer). op=patch (slug, scope, mode, ONE target: section or region) → edit ONE region of an existing on-demand guide WITHOUT re-sending its body (how you append to a long guide or a journal): same grammar as oto_doc op=patch, same writers as op=write, and the reply is a receipt, not the body. expected_rev = the rev of op=read: refused if the guide changed since. op=write / delete take expected_rev too (the rev of op=read — readmes included; absent when there was nothing): refused 409 conflict if someone changed it since, nothing written. VERSIONS: what a write, patch or delete replaces is KEPT (30 days, or the 50 most recent per guide, whichever keeps more). op=revisions (slug, scope) → the kept versions, newest first: rev, replaced_at, replaced_by, reason, size — a deleted guide included ; op=read with rev → that version's content ; op=restore (slug, scope, rev) → writes that version back as a NEW write: same writers and same expected_rev guard as op=write, and the version it replaces is kept in turn. Reading versions takes the right to read the guide. Read the relevant guide BEFORE a non-trivial task (e.g. bulk-load). This is PROSE: a repeatable process with slots is a procedure (oto_procedure), and what oto knows about the user is their profile card (oto_profile). ⚠️ Here expected_rev is OPTIONAL on op=write/delete/restore: omitted, the write REPLACES whatever is there, unseen — the legacy default; oto_guide_v2 requires it.

Guides disponibles (charge le corps avec oto_guide(op=read, slug=…)) :

• affinity-playbook — Driving Affinity (affinity_entity, affinity_list, affinity_list_entry, affinity_note, affinity_interactions) : which id each Affinity tool returns and the next one needs, how list columns are written (names, dropdown text, clearing), what is irreversible, and the errors that mean a missing permission — read before writing to Affinity

• app-template-blocks-1 — App templates: dashboard, review queue, kanban : Pages and manifests of three building-block app templates — read app-templates first.

• app-template-blocks-2 — App templates: intake form, files → agent : Pages and manifests of two building-block app templates: an intake form and a drop zone that hands files to an agent — read app-templates first.

• app-template-crm — App template: CRM : Tables, manifest and page of the CRM app template — read app-templates first.

• app-template-finance — App template: Finance cockpit : Tables, manifest and page of the finance cockpit template — read app-templates first.

• app-template-sales — App template: Sales cockpit : Tables, manifest and page of the sales cockpit template — read app-templates first.

• app-template-seo — App template: SEO cockpit : Tables, manifest and page of the SEO cockpit template — read app-templates first.

• app-templates — App templates : Make the New app gallery's apps (CRM, sales/SEO/finance cockpits, dashboard, review queue, board, form, files → agent) through oto_apps: tables, manifests, pages, rules.

• build-apps — Build an app on Tulina : Read before creating or changing an app (oto_apps): what an app is, the manifest, the page bridge (window.tulina), the click rule, files for agents, sharing, patterns and pitfalls.

• bulk-load — Charger un gros volume (réseau, export, enrichissement de masse) : déléguer à un sous-agent, garder les gros payloads hors contexte, ne remonter qu'un reçu léger

• claude-tag — Brancher oto sur Claude Tag (Slack) : la procédure complète pour qu'une équipe puisse mentionner @Claude dans Slack et lui donner accès à oto — jeton d'API, plugin, et ce qu'il faut savoir avant d'ouvrir un canal

• cognism-filters — DSL de filtres Cognism (cognism_search / cognism_redeem) : référence complète des ~150 champs de filtre Cognism — à lire avant une recherche contact/société non triviale

• company-brain-from-claude — Working with the company brain from Claude : How to read from and write back to an org's knowledge base from an AI surface: pin the org, match research to the stakes and budget it, search before listing, open only the hits, load procedures by name, and capture what the session learned.

• custom-api — Connect a tool that has no connector (Custom API) : Read when the user names a tool with no connector in the catalogue (a payroll tool, an ERP, an in-house API), or wants to call an API directly. Find the org's saved custom connector first; otherwise find the tool's API, hand the user a setup link so the key goes into the form and never the chat, then call it by action name. How to make it reusable for the whole org.

• datastore-semantics — Datastore semantics — layers, faces, business key : valeur/comment/link/origine, what a write destroys, what readonly and the business key protect, what diverges between data_* and REST /api/datastore, and what a response does not contain

• fleet-fanout — "Too many rows for one conversation: set up a fleet" : when a queue exceeds what one conversation can loop through, set up an oto_fleet rather than running data_claim_next up to the turn ceiling

• google-ads-gaql — Google Ads GAQL (google_ads_search) : accounts, managers, GAQL grammar, dates, money in micros, ready queries and errors — read before a non-trivial Google Ads query

• included-tools — Tools included with Tulina: what works without the user's own key : Read before asking a user for an API key, or when picking a data source. Organised by use case (search the web, find companies, find employees of a company, find job postings, enrich a contact, SEO, French public data…): which connector to use for each, and whether it runs on Tulina's keys (credits), a free daily quota, open data, or the user's own login. Includes Apify recipes for company employees and job postings. How to check live before relying on this list.

• lemlist-playbook — Conduire lemlist (lemlist_campaign, lemlist_lead, lemlist_inbox, lemlist_watchlist…) : l'ordre de construction d'une campagne, quel outil rend quel id, ce qui déclenche un envoi, et les 8 endroits où l'API lemlist ne fait pas ce que sa doc annonce — à lire avant toute écriture sur lemlist

• linkedin-search — Recherche LinkedIn (Recruiter / Sales Navigator / Classic) — facettes & pagination : ce qui commande la pagination, c'est le PRODUIT (classic ne pagine pas, premium oui), pas le mode d'entrée ; résoudre chaque filtre en id via linkedin_unipile_facets (candidats sous candidates) ; keywords+company peut rendre 0 à tort ; l'URL reste une boîte noire plafonnée ; respecter le rate-limit (429 = backoff variable, de quelques secondes à ~1h selon la cadence récente — ne pas marteler)

• mcp-apps — Apps rendues (cartes interactives dans le chat) : quand appeler un outil *_app plutôt que son équivalent JSON, ce que voit l'utilisateur, replis quand le client ne rend pas

• meta-ads-insights — Meta Ads insights (meta_ads_insights) : levels, metrics, breakdowns, attribution and async reports — read before a non-trivial Meta Ads performance query

• notice — Notice — the oto user manual : Full user manual of the platform — the handshake base is only its summary; read it at the start of a session.

• onboarding — Onboarding: set Tulina up for a new user : Read when the user pastes the onboarding prompt from Tulina's onboarding page. Start from what the website read already wrote, learn the business, pick 3 recurring jobs (a Process: line in the prompt is the first), adapt library processes, link each to a project, show it as a graph in the chat and give its Tulina link, connect only what they need, prove one on real data, schedule it. Leaves nothing in the workspace but what the user asked for.

• procedure-en-routine — Running a procedure autonomously (Claude Code routine) : "Set up a Claude Code routine that runs an oto procedure with nobody in front of the screen: the prompt is a POINTER to the procedure (never a copy), the Oto connector carries the tools, and the trigger can be scheduled, API (instant) or GitHub. Covers the prompt template, passing context to a run (untrusted data, pass a reference), and the five causes of failure — secrets left on the workstation first."

• procedure-flowchart — Le schéma d'une procédure : Dessin REQUIS de toute procédure : digest d'ouverture, grammaire exacte du parseur (numéro d'étape = 1 ou 2 chiffres), exemple de référence, bornes de densité, formes refusées en silence, panneau Connectors (lit dessin ET prose), relecture

• processes — Processes: find, adapt, run, automate : Read before creating, running or scheduling a process. Start from the org's processes, then the library for examples; adapt with fork; always link the process to a project; track every run with run_start / run_finish; automate with a hosted agent (schedule or webhook) on the workspace's model key; improve the process after each run.

• recipes — Recipes: move data on the server, without a model : Read before writing, testing, publishing or running a recipe (oto_recipe), or when a process step loops over a connector's pages or over the rows of a table. What a recipe is, declarative vs code (Python), the create → test → publish → run cycle, the body of each kind, what a recipe may call and write, limits and receipts, for_each, linking a recipe to a process, platform recipes, and the errors you will meet.

• save-tokens — Saving tokens: let the server do the bulk work : Read before any job over many rows or records (qualify, score, tier, enrich, import, count, bulk edit, push to a CRM or lemlist), or when a run gets slow or expensive. Which server-side tool replaces the model reading rows one by one: recipes to fetch and move data, Jev to qualify accounts, data_aggregate to count, data_update_where to edit in bulk, *_push_rows to send rows out, a fleet only for real per-row judgment, and the conditions for each.

• saving-credits — Spending fewer credits: find where it goes, then cut it : read before answering anything about cost, credits, a bill that is too high, or a runway that is too short — measure first, run a cost analysis of the tools used, offer cheaper options among the tools Tulina offers (cheaper tool for the same job, cheaper model, leaner agent behaviour), each applied one at a time with an approval

• signwell-envoi — Envoyer un document à signer avec SignWell (signwell_document) : text tags, ordre de signature, mode test, lien embarqué vs courriel — à lire avant de préparer un document à signer

• work-queue — "Work queue: draining a pool with N agents" : atomic claim, lease, release — the cycle that guarantees a fleet of sub-agents processes a table with no duplicate and no lost row

• brand — Brand for apps : Colours, font and logo this workspace's apps wear — apply it when building an app. [org]

• client-contract — Client contract: build a Tulina services agreement : Read BEFORE drafting any client contract. The approved template (project 277, file #93), what is FIXED vs VARIABLE (only pricing and deliveries change), where the terms come from, how to render the PDF and put it in SignWell as a draft. Approved by Julien on 25/09/2026 (3Dnatives). [org]

• company-brain-from-claude — Working with the company brain from Claude : How to read from and write back to a Tulina org's knowledge base from an AI surface: pin the org, match research to the stakes and budget it, search before listing, open only the hits, load procedures by name, and capture what the session learned. [org]

• granola-two-accounts — Granola has two accounts in org 196: read every call of Julien AND Alessandro : Since 1 October 2026 the Tulina connector holds two Granola keys, one per founder. Any automation that reads Granola (folk sync, brain ingestion, discovery digest, customer review, investor sweep) must read BOTH, or it silently misses half of the calls; and any automation that writes to Folk from those calls runs a DEDUP PASS first (rule 12). Read before any granola_content call or Folk create. [org]

• outbound-cheapest-first — Outbound data: cheapest source first, always : Founder rule (Alessandro, 20 Oct 2026), applies to EVERY outbound, sourcing and enrichment workload, scheduled or ad hoc, without being reminded: the cascade of sources from free to expensive, what to qualify before paying, hard caps per run, and how to report spend. Read before any sourcing or enrichment call. Superseded by the product's built-in cascades once Julien ships them. [org]

• procedure-en-autonome — Faire tourner une procédure en autonome : routine Claude Code ou tâche planifiée Cowork : Deux surfaces font tourner une procédure oto sans personne devant l'écran : les routines Claude Code (développeur, dépôt, cron UTC, déclencheur API et GitHub) et les tâches planifiées Cowork (non-développeur, connecteurs, cadence au choix, exécution distante). Comment choisir, pourquoi le prompt reste un POINTEUR vers la procédure, le montage complet d'une installation client, et l'audit à passer avant de livrer. [org]

• procedure-flowchart-rendu — Le schéma d'une procédure et ce que la page en fait vraiment — corrections au guide plateforme : ⚠️ REMPLACE le guide plateforme procedure-flowchart, qui se trompe sur deux points. Lis CELUI-CI avant d'écrire ou de réécrire une procédure. Corrigé le 24 août 2026 contre le rendu et contre le parseur lui-même, resynchronisé le 30 août : ce que le numéro d'étape accepte (deux CHIFFRES, donc pas 2a/2b), trois formes de dessin que le parseur refuse en silence, et le panneau « Connectors », qui lit désormais le dessin ET la prose. La question de la place du dessin par rapport au tableau « At a glance » est CLOSE : les deux sont sur des onglets séparés. [org]

• seo-keyword-strategy — SEO keyword strategy: what tulina.ai ranks for, in what order : Founder decisions, 23 and 29 October 2026: tulina.ai ranks first on the bottom-funnel GTM searches its buyers make (tier 1), then larger GTM terms (tier 2), then the COCOON QUEUE (tier 3: competitor X vs Y and alternatives, GTM / sales / chief of staff run from Claude, Claude skills; table 430 queue_rank, doc 5532), then connector MCP terms (tier 4). Every SEO agent reads this before picking a page, a cocoon or a Reddit intent. Sessions never write pages by hand: they fill the queue and trigger the agents. [org]

• seo-unattended-publishing — SEO routines: how a scheduled run publishes to tulina.ai without approval : Founder decision (Julien, 18 October 2026, in his own words: "auto updating the website and pushing directly without my approval"). The rule the four scheduled SEO routines follow on tulina-website: merge after the served-build gates pass, verify the live page after deploy, revert on any live failure, always write the ledger and post one line to #seo. Lists what a scheduled run may never publish on its own. [org]