Your org's procedures (named guides / skills) + the public library. The base guide is INJECTED at connect — op=get with slug loads ONE skill's full markdown (scope=group targets your active department; guide_id loads by STABLE id, incl. one SHARED to your org; org pins the read to an explicit org id you belong to; the body comes WITHOUT its flowchart when it has one, one <!-- flowchart: … --> line standing in — see set for what brings it back; full=true reads it, and the catalog description, in full) / list (catalog: slug/title/summary/version, no body; verbose=true for the full description) / create (NEW procedure: slug REQUIRED and free — a slug already taken is REFUSED, slug_taken, nothing overwritten. Use it whenever you ADD a procedure: set on a taken slug silently replaces it) / set (write: slug is REQUIRED — one named skill. It is an UPSERT: an existing slug is EDITED (new version, the prior one kept in history). Pass expected_version (the version you read) and a concurrent edit gives you version_conflict instead of being lost silently. scope='group' writes your TEAM's procedure and only needs MEMBERSHIP (group pins an explicit team id): whoever RUNS a procedure may improve it, and from_version undoes a bad edit. Omitting scope writes YOUR OWN procedure (scope='user'): PRIVATE, visible to you alone — say scope='org' (needs org_admin) for the org's. If the body you read carries a <!-- flowchart: … --> line, keep it VERBATIM and op=set puts the stored drawing back, but ONLY on the same slug and scope you read from: op=create, a new slug, or an omitted scope (= user) drop it. diagram_warning speaks only of a drawing that is there: two drawings in one body, or one that will not render. from_version restores; org pins an explicit org id. slots = the entities the prose cites as slot:name, and its SHAPE is [{name, type}] — a bare list of names is refused, so is a list of {name} alone. type is one of tableau | connecteur | doc. Optional per entry: description; connector on a connecteur slot ONLY (omit it and the slot NAME is used as the connector — it is not required, contrary to what the refusals may suggest); schema on a tableau slot only, to prescribe the target table's shape. The refusals name the faulty entry by index and say what was expected, so read them rather than guessing — but one procedure still reached version 3 discovering this shape by trial, which is why it is written here. ⚠️ The org README (the prose injected into every session, « socle de l'org ») is NOT a procedure: write it with oto_guide(op='write', scope='org', delivery='init')) / describe (fix title and/or description ALONE — the body is carried over untouched. Use this for a stale catalog line instead of re-sending the whole body through set, which risks degrading prose you did not mean to edit. Same scope/group/org axes and same permission as set; still versioned, so from_version undoes it) / rename (slug → new_slug, same axes and permission as set: the stable guide_id, project links, shares and the whole history are KEPT, the version does not move; runner triggers, campaigns and pending jobs naming the old slug follow in the same transaction (runner); the old slug stops resolving, no alias. A taken new_slug is refused, nothing changed) / archive (exact slug, same axes and permission as set: the procedure leaves every listing and stops being offered, its history is KEPT; idempotent, archived_at says since when) / unarchive (puts it back in service; was_archived_at echoes what was undone) — prefer archive to delete / delete (exact slug; same scope/group/org axes as set, but DESTRUCTIVE — it takes the whole version history, so scope='group' needs the team LEAD) — and the PUBLIC library: op=library_list (browse/search, filter category/author_kind) / library_get (full body by public slug) / publish (share one of your org's skills; visibility=public|unlisted) / fork (copy a public entry: an org procedure for an org_admin, a personal one for a member — scope user|org overrides, org needs org_admin; optional new_slug, project_id to link the copy to a project) / unpublish (id). WEB LINK of one org procedure (org_admin): op=share_get / share_readers (who read it) / share_unpublish / share_set (show_readers); share_publish is done by a person in the app, never by an agent. An ARCHIVED procedure is left out of op=list (include_archived=true lists it too); op=get still reads it by slug, with archived_at set, and a scheduled or webhook agent on it is refused (procedure_archived). set/create answer body_sha256, the SHA-256 of the body as STORED (trimmed, tool names canonical): compare it with your hash of the trimmed body you sent — a mismatch means the stored text is not what you published.

Procedures you can load (pass the slug to load the body) — [personal] = yours alone, [team] = your team's, no tag = your org's:

• pages-process-uploaded-leads — Add the leads of an uploaded file : Test agent for in-app pages (Tulina doc 5420): reads one file a page uploaded into project 818 and adds the people it lists to table 1067 as pending leads. [personal]

• qa-code-recipes-lot2 — QA: code recipes (lot 2) prod matrix : One-shot QA run of oto_recipe kind="code" in production: 24 cases, results written to table 947. Uses only free open-data tools (fr_search, fr_get). Internal test, run once on 12/10/2026. [personal]

• 1001pneus-fleet-accounts — 1001pneus · Pro fleet accounts from the registry : Find SMEs that run vehicle fleets (ambulances, driving schools, taxis, VTC, adapted transport) in a département, group sister companies, estimate tyre spend and write a scored account list with the decision maker.

• 1001pneus-fleet-hiring-signals — 1001pneus · Fleet-manager hiring signals : Weekly intent signal: French companies that posted a fleet-manager or vehicle-park job, grouped per company and scored, so sales reaches the new fleet buyer while suppliers are being chosen.

• 1001pneus-new-garages-trigger — 1001pneus · New garages and tyre shops (BODACC) : Weekly trigger: garages and tyre shops newly registered in France, from BODACC creation notices, scored so the team offers a Pro account and a free 1001Stations listing in their first month.

• 1001pneus-stations-recruitment — 1001pneus · 1001Stations partner recruitment : Map every tyre fitter (fixed and at-home) around a city, drop chains and existing partners, identify the legal entity and manager, score and write a call list for the 1001Stations team.

• add-connector-to-oto — Add a new connector to Oto (oto-core + oto-backend) : Practical recipe for building/extending an Oto connector: oto-core client class, oto-backend MCP tool layer + registry, keyed-mount auth patterns, merged solo/bulk verb tools, dry_run diffs, multi-tenant URL/auth gotchas, the live smoke test that finds what mocks cannot, the agent-facing guide, versioning and git workflow.

• agencies-linkedin-drip — Outbound | LinkedIn sending for Alessandro's account: governor, auto ramp-up and agencies drip : The single orchestrator of everything sent from Alessandro's LinkedIn. Five small runs per weekday (09:23, 11:23, 13:23, 15:23, 17:23 Paris). A governor (table 980) sets the daily budget and raises it step by step (5 → 8 → 12 → 15 → 20 invites a day) only when the account is healthy, backs off on any warning, and pauses everything on a checkpoint. Works the RevOps & GTM agencies partner campaign (table 969) and drains the backlog of stale pending invites (table 979). Hand-off, nothing to start: then linkedin-unreplied-digest-alessandro drafts replies to the conversations it opens. Then linkedin-weekly-recap-sales sums up the week on Friday.

• agent-doctor — Agent Doctor: heal customers' hosted agents before they notice : Every 30 minutes on weekdays (hosted agent, org 196, Julien's platform role lent through platform_tools): read the open failure episodes of hosted agents in EVERY org (oto_admin_agent_repair), diagnose the ones the backend loop could not classify, re-run what is safe, write the cause on the episode, escalate the rest, and post one short line in #product only when a person must act. Never touches a customer's key, identity, procedure, schedule or data; never writes to a customer. Plan: doc 5475.

• agent-fleet-debugger — Agent fleet debugger: find what broke in Tulina's hosted agents, fix what is safe, report in #general : Daily: sweeps every hosted agent of org 196 (failed and blocked runs, dying jobs, expired occurrences, tool errors, agent recaps on Slack that report a problem), traces each problem to its root cause in the procedure, table schema, data or agent config, applies the fixes that are safe and reversible, verifies them, logs every incident in table 1064 and posts what happened and what was fixed in Slack #general.

• audit-your-website — Audit your website for SEO issues every week : Crawls your site weekly, finds broken pages and links, pages Google can't index, duplicate titles and slow pages, writes each issue with its fix, and posts only the new critical ones in Slack. Never edits the site.

• backlink-outreach-lemlist — Backlink outreach: weekly prospects from the SERPs, launched in Lemlist : Every week, reads who ranks for the bottom-funnel GTM queries our buyers search (Clay alternatives, RevOps and GTM tools, Claude Code for GTM, website visitor tools, n8n alternatives) plus a few MCP terms, records listicles, guides, directories and partner programs in the seo-link-prospects table, finds one person per page with a verified email (Pipecorn, Apollo, then FullEnrich), dedupes against the table and the Tulina CRM tables (sales-pipeline 1175, crm-people 1247, crm-investors 1248, gtm-accounts 1230), adds each new person to the running Lemlist backlink campaign with three checked variables and launches them (Julien's decision, 23 Oct 2026), at most 15 a run. Directory forms stay for Julien to file by hand.

• bulk-vs-per-row-tool-strategy — Bulk vs. per-row: choosing tool shape for multi-contact procedures : Decision framework for any procedure that processes N contacts/rows: which tools batch natively (e.g. batch email-enrichment calls, data_write) vs. which are hard-floored at one-call-per-item (CRM create/update, single-profile enrichment lookups, most other single-record connector calls), how to structure a procedure so batchable steps run in bulk while non-batchable steps stay tight loops, and when the claim-based work-queue pattern (data_claim_next) is actually the right tool vs. an expensive default. Written up after a contact-sourcing run used ~50+ tool calls for 11 contacts where ~27 was the honest floor — the gap was entirely from looping batchable calls per-row instead of batching them.

• cal-booking-to-website-leads-slack — Website demo booking → #website-leads alert with booking source (Cal.com webhook) : Event-driven, one Cal.com booking per run. When someone books a Tulina demo, a hosted agent reads the booking from Cal.com (the webhook body drops the website path, guests and answers), works out WHERE it came from (the website path tulina.ai recorded with the booking: referrer, UTM tags, landing page and pages seen, a Google search landing on the home page being a branded search; then Lemlist campaign, LinkedIn conversation, email thread, cold call, website visit, or no prior touch), looks up the company and the person (Serper, LinkedIn search), and posts who booked, when, the source with its evidence, the website path, guests, what they typed and a short overview in #website-leads as the Tulina app. Read-only everywhere; never contacts the booker.

• client-pr-live-watch — Tell customer success when a client PR goes live in prod : Twice a weekday, check every PR follow-up still waiting on a merge or a prod release: is the PR on main, is it in what prod runs. Mark the row ready when its condition is met, and post the rows that name a client to #customer-success with what they unblock. Silent when nothing moved. Reads GitHub only, never writes to it.

• cold-call-list-prep-phone-cascade — Outbound | Cold-call list prep: phone cascade from cheapest to dearest, tiers, call notes and Minari-ready lists : Turns Lemlist lists into separate cold-call lists: stages them in one table, finds LinkedIn URLs and phones cheapest source first (Serper, AI Ark, Google Maps, then capped dear sources like Forager), tiers and annotates each person, and builds Minari-ready payloads and CSVs without pushing.

• cold-call-session-followup-emails — Outbound | After a cold-calling session: follow-up email drafts for everyone who asked : After a cold call, drafts the follow-up email for everyone who asked for one. Runs by itself during calling sessions (hosted agents: a scheduled sweep every 30 minutes on weekdays, and a per-call webhook mode ready for Minari's call.completed), or by hand at the end of a session. Reads each connected Minari call and its transcript, skips anyone already written to in Gmail, resolves missing addresses with FullEnrich (Apollo, then AI Ark as backups), and saves one Gmail draft per person in the rep's style. Never sends.

• compact-tool-output — Sorties compactes : aplatir la ligne, puis servir en TOON : Recette réutilisable pour réduire ce qu'un outil oto coûte en contexte à l'agent qui le lit, appliquée un outil à la fois. Deux leviers dans cet ordre, jamais l'inverse : APLATIR l'enregistrement (remonter les blocs imbriqués sur un niveau, ne garder que les colonnes qu'un agent lit), puis l'encoder en TOON sur le canal texte — un format tabulaire qui déclare les colonnes une fois et écrit une ligne par enregistrement. L'ordre est le sujet : mesuré le 08/09/2026 sur une page AI Ark de 100 profils, TOON seul rend 8 %, l'aplatissement seul 21 %, les deux 47 %, parce que TOON ne met en tableau que des lignes plates et uniformes. Porte trois vagues (tableaux du datastore, journal de monitoring, connecteurs à commencer par AI Ark), la fondation à construire une fois (encodeur Python, middleware de sortie, axe _format de repli), le seuil sous lequel on abandonne, et ce que ce levier NE répare pas — un corps markdown, un enregistrement seul, et le vrai plafond qui est de ne pas renvoyer les lignes du tout.

• connector-page-depth-pass — Keep every tulina.ai connector page complete and deep: new connectors get a page, five pages a night : Takes the next five connector pages from the SEO query table (wave W1, then W1b, by US volume, skipping pages already deepened), reads the live SERP and its People Also Ask, establishes what the connector really does from its card and tool schemas, verifies the vendor's own MCP server on the vendor's docs, then rewrites each MDX body with PAA questions as H2s, a Tulina-vs-official comparison table only where verified, three real example prompts and an honest limits list. Verifies on a served build with curl and dates depth_pass_at in tulina-seo-pages. A scheduled run publishes on its own under the guide seo-unattended-publishing (founder decision, 18 October 2026): merge, verify live, revert on failure. A run started by hand hands the worktree to Julien.

• connector-page-seo-pass — Make a connector page findable by the words a buyer types : Twice-nightly pass: take five /connectors/* pages with no SEO pass yet, rewrite title/description/connection-section from the real SERP, assert on the served build, merge and verify live, revert on any live failure.

• customer-onboarding-fast — Customer onboarding : Stand a new customer's workspace up in about half an hour: create their org and a Sales project, write ICP and Offer from their site, read their stack twice — what they said on their Granola calls and what TheirStack observes on their domain — turn on every connector that stack names, install only the tulina.ai processes their own words asked for, set the org README, and hand it over. Three memory pages, not a knowledge base.

• customer-support-reply — Customer support reply: draft in Alessandro's voice for each customer Slack message (webhook) or sweep : When a customer writes in their Slack Connect channel (webhook, one message per run) or on the scheduled sweep: split the message into tickets, answer from Standing Answers, the company brain, the customer's own org and, when still unsure, the product code on GitHub, and draft the reply in Alessandro's voice. Posts one short summary to #customer-success saying which customer asked what, with every draft in the thread. Never posts in a customer channel. A sweep with nothing new exits after one cheap check.

• daily-feedback-triage — Daily feedback triage → #product : Every evening (hosted agent #80, 20:00 Paris): pull the day's Tulina-customer signals and tool errors, check each against the code via the GitHub connector and the deployed version, decide if it is a real bug and whether we can act, then post one per-account digest to Slack #product. Read-only on signals and GitHub.

• daily-pr-linear-slack-digest — Turn merged into Slack notif and ticket update : Nightly (21:00 UTC): find today's merged PRs across the 4 core repos, log each one on its matching ticket in tulina-product-feedback (table 370) and move the ticket's status, then post a short summary to #product. Linear is retired.

• deal-won-lookalike-campaign — GTM 1 · Source: deal won → 70 lookalike accounts of the new client (their campaign is staged paused for a founder) : Two hosted agents. Hourly, a cheap watcher reads Stripe (a new paying customer) and the Tulina sales-pipeline table 1175 (a company that reaches Closed Won / is_client=yes), records each new won client once in table 1220 and starts the builder. The builder works out what the client sells and to whom and writes up to 70 lookalike companies to the accounts table 1230 (track deal-lookalike). Writes accounts only; then gtm-account-scoring scores them, gtm-find-decision-makers finds the people, and gtm-email-channel stages them in the client's own paused Lemlist campaign and asks a founder to launch it. Nothing reads or writes Folk.

• demo-call-prep — Sales | Demo call prep: a project per prospect with processes built for their trade, run on real data, and a private operator brief : Before a demo or discovery call: reads the email thread, calls and outbound row, studies the business and the attendee, pulls what Tulina proved for similar clients and the community library, then creates a project for the prospect in org 196 with three or four tailored processes and tables run on real data, and a private one-page brief for the operator. Reproduces the Giano Capital prep.

• finance-kpi-report — Refresh the finance data (Stripe + Qonto → Tulina tables, Finance app) : Weekly (Monday 07:00 Paris, agent 226): snapshots Stripe subscriptions (product vs services), lists Stripe invoices with their tax and issuer, pulls Qonto transactions through the Custom API, and writes them to the Finance tables. The Tulina app « Finance » (app 9) computes KPIs, VAT and the 12-month projection from them. Writes nothing to Stripe, Qonto or any spreadsheet.

• find-backlink-opportunities — Earn backlinks: find the right person behind each article and email them : Every week: finds the articles that rank for your buyers' searches or link to your competitors, picks the one person who decides each page, finds a verified email, writes a short email tailored to the article with a backlink exchange as the offer, and sends it from your sequencer or mailbox after checks. At most 15 a run; the first run sends 5 and shows them in Slack.

• find-new-customers-matching-your-icp — Find new customers matching your ICP : Writes your ideal customer profile from your website and your existing customers, has you confirm it, then finds new matching companies in Apollo and AI Ark, deduplicated, scored A/B/C and written to a table with one line on why each fits.

• founder-social-video — Turn a founder recording into a social video : Alessandro films himself talking about a feature; a Claude Code session on his Mac cuts the takes, shows the real product in 3D over the shot, adds word captions and new music, and hands back a proof-read 9:16 film (and its cover) for X, LinkedIn and Instagram. First made for the Apps launch, 2 Nov 2026.

• front-english-check — Weekly English check of the Tulina app : Every Monday: finds French that reaches English readers of tulina-app-front (connectors with no English copy, French in the English messages, French literals in components) and opens one pull request that fixes it. Writes only to its own branch; never merges.

• granola-call-to-tables — Granola calls to Tulina tables: classify, route, update the pipeline tables, write the recap, draft the follow-up : Per Granola call (webhook, one note per run): classify it (sales, customer success, talent, partner, investor, internal), update the Tulina tables that replace Folk (sales-pipeline 1175, crm-people 1247, crm-investors 1248, crm-call-notes 1249), write the recap row, and draft the Gmail follow-up for the call's leader. Nothing is written to Folk. Successor of granola-latest-call-to-folk.

• granola-latest-call-to-folk — Granola calls to folk: classify, route, update Status and Notes, draft the follow-up, every 12 hours : Granola calls update objects in folk (on a schedule). Connected to Julien's and Alessandro's Granola accounts.

• gtm-account-scoring — GTM 2 · Account scoring: every sourced account gets a tier (A, B, C, Out) and a reason : Takes every account at status sourced in table 1230, applies the gates (clients, open deals, partners, investors, never-contact, already contacted, outside the countries or the size band, not B2B), sets the lane and scores fit plus signal into a tier A, B, C or Out with a one-line reason. Writes accounts only. Hand-off: then gtm-find-decision-makers finds the people at the A and B accounts.

• gtm-call-list-minari — GTM 4 · Call channel: today's Minari call list from the A and B people with a phone, approved by a founder before the push : Every weekday morning, picks up to 40 people with a phone from table 969 (tier A first, then B, never called or due for another attempt), writes a short call note for each, and posts the list in #gtm. When a founder answers "go" in the thread, pushes it as one Minari list and marks the people in_list. Hand-off: then the Minari follow-up sweep reads each call and writes its outcome back to tables 969 and 1230.

• gtm-email-channel — GTM 4 · Email + LinkedIn channel: copy from the library, checks, push to the lane's Lemlist campaign, LinkedIn queue : Takes the people waiting at stage candidate in table 969, reads each company's site, writes the five emails and the LinkedIn messages from the weighted copy library (table 993) with the lane playbook's rules, checks every lead mechanically, pushes and reads back in the lane's Lemlist campaign (agencies EU, agencies North America, startups; a won client's lookalikes go to their own paused campaign for a founder to launch), launches when the lane's autolaunch switch is on, and queues LinkedIn. The French sales-leaders lane is LinkedIn only: its message comes from its own playbook. Hand-off: then agencies-linkedin-drip sends the LinkedIn steps of the leads queued here.

• gtm-find-decision-makers — GTM 3 · Decision makers: one person per A and B account, with a verified email (and a phone for A accounts in call markets) : Takes the A then B accounts of table 1230 that have no people yet, finds the person who buys (the lane playbook's step 4: free lemlist database first, then AI Ark, Pipecorn then FullEnrich for the email), adds a phone for A accounts in the countries we call, and writes the person to table 969. Hand-off: then gtm-email-channel writes and sends the emails, and gtm-call-list-minari puts the people with a phone on the next call list.

• gtm-followup-email — Follow-up email from a conversation : Turn a LinkedIn, event or meeting exchange into a Gmail draft in the prospect's language, grounded in the Tulina knowledge base and written in the operator's voice. Draft only, never sent.

• gtm-lane-agencies — GTM lane playbook | Agencies: who they are, how to qualify, who to pick, the copy, the checks, the campaign : Reference for the GTM stage agents: the agencies lane's ICP, qualification, exclusions, person picking, copy rules, mechanical checks and Lemlist push settings, copied from the former autopilot on 2 Nov 2026.

• gtm-lane-salesfr — GTM lane playbook | Sales leaders FR: who they are, the free pool, the LinkedIn message (max 15 a day) : Reference for the GTM stage agents: the French sales-leaders lane (heads of sales, VP sales, CROs at French B2B companies of 11 to 1000 staff), its free lemlist-database pool (table 1229), and Alessandro's "machine GTM" LinkedIn message, sent by the LinkedIn drip at most 15 a day. Copied from sales-leaders-fr-linkedin v2 on 2 Nov 2026.

• gtm-lane-startups — GTM lane playbook | Startups: who they are, how to qualify, who to pick, the copy, the checks, the campaign : Reference for the GTM stage agents: the startups lane's ICP, qualification, exclusions, person picking, copy rules, mechanical checks and Lemlist push settings, copied from the former autopilot on 2 Nov 2026.

• gtm-outbound-community-signal — Slack communities : Build an outbound campaign from membership of an adjacent tool's community. Covers browser-only Slack extraction, why the roster is not the list, resolution and enrichment gates, per-person openers, segment copy, and the Origami build sequence with the endpoints that lie.

• gtm-outbound-company-brain — Company-brain ICP: hiring signal to three persona campaigns in Lemlist : Hosted agent, daily 08:04 Paris. Outbound to tech companies of 5 to 100 people in the US, the UK and Ireland, and Europe (never Germany or Austria) that are provably building or buying an internal AI layer. Sourced from a measured high-precision hiring-title set on a 3-day delta, stripped of everyone any lane has handled, qualified on the company's own site, resolved through AI Ark for CEO and COO and the LinkedIn session for Chief of Staff, emails cascaded AI Ark then FullEnrich on EVERY person with a domain gate and a completion gate. Writes five emails per person from the weighted copy library (table 993, lane brain) into table 969, checks every lead mechanically, then pushes, reads back and launches it in one of three standing Lemlist persona campaigns (CEO, COO, Chief of Staff), migrating the 112-person Origami backlog a batch at a time. Switches in table 989 (brain.*), one ledger row per day, the recap in the run note; posts in #gtm only when a person has an action point. Moved from Origami to Lemlist on 21 October 2026.

• gtm-outbound-liste-participants-evenement — Liste de participants à une campagne française, sans jamais citer la source : Transformer une liste de participants d'un événement sales en campagnes Origami françaises, en gardant la source strictement invisible. Couvre la déduplication de l'export, la cascade titre-puis-adresse, le filtre décideur, l'écran concurrent en trois passes, les six classes de défaut nominatif, et le patron d'accroche qui remplace la récitation de fait par une implication.

• gtm-outbound-lyon-industrial-hiring-signal — Signal de recrutement ingé/tech — industrie bassin lyonnais : Repère les grands industriels (aéro, défense, ferroviaire, nucléaire, énergie, mécanique) ayant un site à moins de 100 km de Lyon et qui recrutent des ingénieurs ou techniciens, puis sort les bons interlocuteurs techniques par usine avec email et téléphone.

• gtm-outbound-negoce-specialise — Superseded — Négoce spécialisé (kept for the email template) : SUPERSEDED on 12 September 2026 by the two Enterprise lanes, negoce-lane1-reprise (PE backing signals) and negoce-lane2-tension (Job signals). Its targeting is too narrow — it covers only specialty food and drink at 11-50 in FR, IT, UK and US, a universe of about 1,300, where the Enterprise lanes cover five sector families at 11-200 in FR and IT, about 22,300 companies. Its market sizes and its 25-company funnel test are superseded by measurements taken the same day against the French registry. Do not run it. Two things in it are still live and are not yet carried by the lanes: the three-email French sequence with its +4 and +7 timing, and the copy constraints behind it. Both move into the lanes at the copy validation pass.

• gtm-outbound-sequence — Grossistes (Wholesalers) FR : The outbound motion end to end: build the universe from SIRENE, gate it on a named buyer and a verified website before spending a credit, tier each prospect by the hardest signal found (back-office hiring, known ERP, trade press, or none) to decide campaign and order, enrich the email through FullEnrich, write one site-grounded opener per row that never names the signal, compose the five-email playbook sequence per lead into subject / l_e1…l_e5, and add the people to the two standing Lemlist campaigns. Every step below has run on real data at least once; the weekly autopilot runs it unattended.

• investor-pipeline-dormant-sweep — Investor pipeline: move to Dormant after a week without contact : Every day at 07:46 Paris (Tulina hosted agent 76), read the Tulina table crm-investors (1248, replaces the Folk group Pre-seed Investors; VC funds, business angels and advisors) and move to Dormant every investor whose status is Contacted, First call done or In discussion and whose last contact is more than 7 days ago, after checking the recap table crm-call-notes (1249) and Granola on BOTH accounts for a call not yet synced. Funds added by hand with no contact date are left as they are, and the run never creates a row (dedup pass first: a second row of the same fund is reported, not written). Writes status, status_before_dormant, last_contact and a dated line in description. Sends nothing. Nothing is read from or written to Folk. A call recorded in Granola lifts a Dormant row again (granola-call-to-tables, step 2d).

• job-sourcing — Skill — Sourcing d'offres sur Google Jobs : Recette pas-à-pas pour sourcer, filtrer et qualifier des offres senior via serpapi_search_jobs.

• klark-crm-hygiene — Klark 3: Keep HubSpot clean (job changes, duplicates, missing data) : Scheduled agent that checks HubSpot contacts and companies for job changes, duplicates and missing fields, in the pattern of Partoo's verify-account process.

• klark-signal-outreach — Klark 2: Find the support leader and prepare the lemlist campaign : For the top accounts in slot:klark_tam, find the support or client-experience leader, personalise the opener and push to the matching lemlist campaign.

• klark-tam-mapping — Klark 1: Map the TAM from lemlist's database : Build and score Klark's TAM: French B2C brands running a helpdesk Klark plugs into, with support-team signals, into the slot:klark_tam table.

• koncile-lemlist-daily — Point quotidien sur les campagnes lemlist de Koncile : Chaque matin à 9h00 Paris, lire les campagnes lemlist de Koncile sous leur propre clé (org 270), relever les compteurs de la veille en un seul batch_stats, en garder une ligne par campagne et par jour dans koncile-lemlist-daily, puis poster trois lignes en français DIRECTEMENT dans le canal Slack partagé avec Koncile — sans relecture humaine entre le run et le client. Vérifie d'abord si la journée est déjà partie (poste_le), parce que rien en amont ne dédoublonne un déclenchement. Ne signale que ce qui mérite de l'être — bounces, chute d'envois, changement de statut, file qui s'épuise — se tait complètement les jours sans envoi, et n'énonce jamais une cause supposée. Aucune écriture sur lemlist.

• launch-day-amplifier-tickoff — Launch day: tick off the amplifiers on LinkedIn : Hourly on launch day (Wed 28 Oct 2026, 12:15 to 20:15 Paris): finds which amplifiers posted about the launch or engaged with the founders' LinkedIn launch posts, writes launch_status and post_url in the Amplifiers table (994), and posts in #gtm the new posts the founders should engage with. Read-only on LinkedIn: never likes, comments or messages.

• launch-linkedin-campaign-send — Launch campaign: send the LinkedIn messages in waves : Every 20 minutes from 08:05 to 14:45 Paris on Wed 28 and Thu 29 Oct 2026: sends the next drafted launch messages from table 1099 (LinkedIn campaign messages), 5 per founder per run and never more than 100 per founder per day, each with that founder's own launch post link from the Posts calendar (996), from Alessandro's and Julien's LinkedIn accounts. Stamps every send, never sends a row twice, and stops on the first LinkedIn limit error with a line in #gtm.

• launch-visuals-for-each-release — Make launch images and short motion clips for each release : For each release, a Tulina agent writes three visual ideas from what shipped and the brand guide, makes four stills per idea with Higgsfield on Tulina credits (each job priced first, within a budget), looks at every take and keeps the two cleanest, animates them into 5 second clips, saves the files and posts the picks in Slack with what they cost. About $1.20 a release.

• lemlist-positive-reply-to-sales-slack — Outbound | Positive lemlist reply: alert #sales with a suggested reply in the thread : Event-driven, one lemlist reply per run. A lemlist reply webhook starts a hosted agent that reads the reply, keeps only the positive ones, posts a short alert in Slack #sales and puts a suggested reply in the thread. Drafts only: nothing is ever sent to the prospect.

• linkedin-post-benchmark — Benchmark LinkedIn posts of any kind : How to benchmark any type of LinkedIn post (a launch, a fundraise, a hire, a customer story, an opinion...): scrape public posts of that kind, score them on engagement, label hook, structure, proof and call to action on the server, compare the best quarter with the worst, and write the winning patterns down with a template. Never posts and never uses your LinkedIn account.

• linkedin-post-review — LinkedIn post review: challenge a draft before it goes out : Give it a LinkedIn draft (text, plus the image idea and the goal if any). It challenges the draft against the project's posting playbook (including Julien's own voice, learned from his published posts) and against comparable posts from the 17-creator benchmark table: angle, hook tension, proof, structure, personal stake, ending question, links, AI-sounding phrasing. Returns a verdict (post / rework / don't post), the 3 objections a sceptical RevOps reader would raise, the 3 fixes that matter most, 3 alternative hooks and one rewrite in the author's voice. Never publishes anything.

• linkedin-post-video — LinkedIn post video: animated, beat-synced visual for a post : Turns a final LinkedIn post into a 24-second animated video (4:5, 1080×1350) with a 120 BPM techno-house track: the post's hook and key finding as kinetic type and an animated chart, every entrance on the beat, a punchline end frame and a thumbnail. Every line on screen is checked against the final post text. Built in the founder-videos Remotion repo on Julien's Mac (local Claude Code, not a hosted agent). Ends with the video, the thumbnail and the post text in Julien's Downloads and clipboard. Never publishes. Learned on the "121 calls: what makes people try vs buy" post (06/11/2026).

• linkedin-unreplied-digest — LinkedIn — fils sans réponse + brouillons, DM Slack 4×/jour : Balaye la messagerie LinkedIn de Julien depuis le dernier passage, isole les fils dont le dernier message vient de l'interlocuteur, rédige un brouillon dans son style et le livre en DM Slack : nom, lien LinkedIn, dernier message, brouillon. Ferme aussi la boucle sur les fils déjà livrés : si Julien y a répondu lui-même sur LinkedIn depuis, compare sa vraie réponse au brouillon pour affiner le style. N'envoie jamais rien sur LinkedIn.

• linkedin-unreplied-digest-alessandro — LinkedIn — unreplied threads + draft replies, Slack DM once a day (Alessandro) : Scans Alessandro's LinkedIn inbox since the last pass, isolates threads where the other person wrote last and a real reply is needed, drafts a reply in his style and delivers a SHORT list by Slack DM. Drops only obvious, irrelevant cold pitches. Also closes the loop on threads already delivered (Phase 9). Never sends anything on LinkedIn. Alessandro's copy of Julien's unreplied-threads digest, same trigger setup (once a day, 18:29 Paris). Everything in English.

• linkedin-weekly-recap-sales — Reporting | Weekly LinkedIn outreach recap to #sales (Friday 17:47 Paris) : Every Friday, after agencies-linkedin-drip has sent its last slot of the week, reads the outreach state (tables 969, 979, 980 and the week's drip runs) and writes a short, scannable recap of Alessandro's LinkedIn outreach (volume, acceptance, messages, replies with names, account health and ramp level, backlog cleanup, queue left) in the run_finish note. Posts in Slack #sales only when a person has something to do (replies waiting for an answer, account restricted or paused). Read-only apart from that one possible Slack post.

• make-film-thumbnails — Make the thumbnails for a new film : After the product update's films are rendered: one sharp product frame per film, a 2-5 word headline and a true pill, a 2560x1440 render with the thumbnail kit, a phone-size check, then a person uploads them to YouTube and a PR puts 960px copies in the app's video library. The tour film gets two (YouTube and in-app). Issue 01's five thumbnails are the worked examples.

• narrated-release-video — Make a narrated video of each product release : For each release, a Tulina agent writes a 35 to 60 second script from what shipped, makes the voice and the music with ElevenLabs on Tulina credits, plans every shot inside the product, has a free Remotion project on GitHub render it, proof-reads every frame and posts the film in a Slack thread, where replies start another round. Includes how to set up the Remotion project with Claude Code.

• negoce-lane1-reprise — Enterprise | PE backing signals : Enterprise lane: registry-first qualified volume through Apollo → AI Ark → FullEnrich, staged in paused Lemlist campaigns for manual launch.

• negoce-lane2-tension — Enterprise | Job signals : Enterprise lane: registry-first qualified volume through Apollo → AI Ark → FullEnrich, staged in paused Lemlist campaigns for manual launch.

• negoce-lane2-tension-2 — Enterprise | Job signals : Enterprise lane: registry-first qualified volume through Apollo → AI Ark → FullEnrich, staged in paused Lemlist campaigns for manual launch.

• oto-backend-pr-1392-live-dm — Tell Alessandro on Slack when oto-backend PR #1392 is live : Hourly, one-off: checks whether the code running on mcp.tulina.ai contains both fixes of oto-backend PR #1392 (recipe calls in parallel, agent runs kept across reconnects). The first time it does, DMs Alessandro on Slack once, then switches its own agent off.

• oto-front-local-backend-setup — Run oto-front locally against the real oto-backend : How to connect a local oto-front (Next.js) dev server to the real oto-mcp backend via Logto auth, and pull real connector data instead of mock data.

• outbound-ai-native-stack — Company-brain | AI-native stack (companies already building their own company brain) : The second signal for the company-brain ICP, and a measurably different buyer from the hiring motion: zero of wave 2's 21 companies overlap with it. Targets companies of 5 to 100 people whose detected stack shows they are assembling an internal AI layer by hand. Sourced from TheirStack company technographics under paired technology slugs, where the lever is a paid deployed tool in the pair rather than the _and operator. Wave 2 ran 31 August 2026, lifted scrape yield from 22 to 76 per cent, and produced 37 emailable people across two campaigns. Shares the hiring motion's table so nobody is worked twice.

• outbound-autopilot-agencies — GTM 1 · Source: new RevOps, CRM and GTM agencies into the accounts table every weekday (EU + North America) : Two hosted agents, weekdays (EU 07:42, North America 15:12 Paris). Learns new lookalike seeds from the latest positive replies, then finds RevOps / CRM / GTM / AI-automation agencies from hiring signals and lookalikes of the agencies that converted, and writes them to the accounts table 1230 (track agencies-eu or agencies-na). Writes accounts only; then gtm-account-scoring scores them.

• outbound-autopilot-agencies-na — GTM 1 · Source: agencies, North America run (pointer, GEO=NA) : The North America half of the agencies source, on its own schedule. It holds no method: it runs the agencies source with GEO=NA and writes the agencies it finds to the accounts table 1230 (track agencies-na). Writes accounts only; then gtm-account-scoring scores them.

• outbound-autopilot-buyers — Outbound | Agency-buyers autopilot: founder-led B2B companies, short human copy in Alessandro's style, into Lemlist at volume : Hosted agent, weekdays 09:37 Paris. Replicates the Lemlist playbook that won Pipelab the Emma.legal deal, with Tulina's edge from the Klark win (software and team in one contract, priced under the GTM agencies on Clay or Cargo). Sources founder-led B2B software companies of 2 to 30 people with no sales team (the companies that buy a GTM agency), never a partner's prospect or client, finds the founder and a verified email, works out who THEY sell to and the public, dated moment their buyer becomes ready, finds one real dated example of it, writes a four-email sequence (buyer moment, workflow, dated case + one-contract positioning, breakup) from the weighted copy library (table 993, lane buyers), checks every lead mechanically, pushes and launches it in cam_DL6Tgdtw2sCSt3K8Z, queues tier A for the LinkedIn drip and posts a recap to #gtm.

• outbound-autopilot-startups — GTM 1 · Source: B2B startups building their sales team (hiring signals + Klark lookalikes) into the accounts table, every weekday : Hosted agent, weekdays 08:12 Paris. Learns new lookalike seeds from the latest positive replies, then finds European B2B software startups (8 to 200 staff) hiring SDRs, BDRs, business developers or RevOps right now (free lemlist database first, one TheirStack call), tops up with lookalikes of Klark and of every positive replier, and writes them to the accounts table 1230 (track startups). Writes accounts only; then gtm-account-scoring scores them.

• outbound-buyers-backfill — Outbound | Buyers backfill helper (pointer to outbound-autopilot-buyers, parallel volume runs) : On-demand helper for the agency-buyers lane volume push (Alessandro, 25 Oct 2026: 500 launched by 26 Oct, ~1,000 accounts, a couple hundred a week after). Holds no method: runs outbound-autopilot-buyers on the country group named in its handoff, in parallel with agent 189.

• outbound-buyers-bulk — Founders and CEOs of small B2B tech companies : The fast route for the agency-buyers lane (campaign cam_DL6Tgdtw2sCSt3K8Z), built 25 Oct 2026 for volume: a server-side recipe pulls founders and CEOs of small B2B tech companies from lemlist's free database into table 1069, free server-side rules reject out-of-lane rows, the server-side email waterfall (Apollo then AI Ark) finds verified work emails, the agent writes the short four-email sequence in Alessandro's style for each lead, and lemlist_push_rows launches them in batches of 50 (auto-launch is on). Replaces the one-company-at-a-time flow of outbound-autopilot-buyers for volume.

• outbound-buyers-monitor — Outbound | Buyers lane monitor: keep sourcing fed, track replies and meetings : Alessandro, 25 Oct 2026: goal is meetings booked this week from cam_DL6Tgdtw2sCSt3K8Z. Every run: count launched leads, keep backfill runs queued until 500 launched, then a couple hundred a week; count replies (into the run note); post in #gtm only for a health problem a person must act on. Silent otherwise.

• outbound-campaign-manager — Outbound | Campaign manager: pause campaigns that do not work, rewrite weak email steps as 50/50 tests : Hosted agent, Monday and Thursday 08:20 Paris, after the cockpit refresh. Pauses running Tulina Lemlist campaigns with no engaged reply or meeting after 300 leads and 14 days (or bounces over 5 %), switches the lane off when all its campaigns are paused, and tells #gtm. Finds the weakest email step (150+ delivered, under 1 % for email 1, 0.5 % for follow-ups) and tests a rewrite 50/50 lead by lead on leads that have not had that step, proving first that Lemlist sends the rewrite. Starts in dry_run (table 989 manager.mode).

• outbound-campaign-playbook — Outbound campaign playbook: read before building or expanding any outbound motion : The cross-cutting checklist for any new outbound campaign or process in the Outbound project (257), whatever the segment: what to check first, the copywriting and segmentation rules that apply to every lane, the cheapest-tool-first credit cascade, the non-negotiable pause and verification rules, the end-of-run Slack recap, and the exact points where a build must stop and ask instead of assuming. Full reasoning and the incidents behind each rule live in the project doc "Outbound Build Playbook" (project 257); this procedure is the short, authoritative version that gets checked automatically.

• outbound-capacity-manager — Outbound | Capacity manager: keep lead volume matched to sending capacity : Hosted agent, weekdays after the cockpit refresh. Compares the Lemlist sending limit with what the leads coming in will need once their follow-ups run, then raises the volume of the best lanes when capacity would go unused and lowers the worst lanes when leads pile up. Acts only through lane caps in table 989 and extra runs of the agents listed in manager.boost_agents. Follows manager.mode: dry_run reports only.

• outbound-cockpit-refresh — Outbound cockpit: refresh Lemlist campaign data, sequences and mailbox limits : Every morning, refresh the data the Tulina Outbound cockpit app (project 257) reads: each sending mailbox's daily limit, warm-up and status in Lemlist (table 1174), the Lemlist campaign list and each campaign's email step timing (table 1172), and campaign stats per day plus lifetime totals (table 1173). Read-only on Lemlist: never sends, launches or edits a campaign, a sequence or a mailbox. No Slack post.

• outbound-copy-optimizer — Outbound | Copy and strategy optimizer: score every variant on meetings booked and move the traffic to what converts : Hosted agent, Monday and Thursday 06:52 Paris, before the outbound autopilots run. Records for every autopilot and partner-campaign lead when email 1 left, whether they replied, replied positively or booked a meeting (Lemlist, Cal.com, the founder calendar, discovery calls, the sales-pipeline table 1175); scores every copy variant and every segment on meetings plus half of positive replies; reads what people actually said; shifts the variant weights toward winners within strict bounds, adds at most one challenger per lane, retires only clear losers on large samples; adjusts lane caps, country rotation and score bonuses on Mondays; checks every change; reports on the scoreboard page and in run_finish, and posts in #gtm only when a person must act.

• outbound-exclusion-list-sync — Outbound | Exclusion list sync: clients, open deals and partners never get a cold email : Every weekday before the autopilots run, rebuilds table 1006 outbound-exclusion-list from Stripe, the Tulina CRM tables (sales-pipeline 1175, crm-people 1247, crm-investors 1248) and table 169 (signed clients, prospects in an open deal, partners, investors, founder blocks) and mirrors every active domain into Lemlist's domain unsubscribe list, so every Lemlist campaign skips them, including campaigns built by hand. A lost deal becomes contactable again. Nothing reads Folk any more (3 Nov 2026). Founder rule, Alessandro, 20 Oct 2026. Hand-off, nothing to start: then outbound-autopilot-agencies reads the list before every push. Then outbound-autopilot-agencies-na does the same. Then outbound-autopilot-startups does the same.

• outbound-investor-lookalike — Outbound | Investment-firm lookalike: from one reference fund to a paused, fully personalised Lemlist campaign : Turns a reference fund (customer or hot prospect) into a lookalike campaign: AI Ark + Apollo firm list, Jev scoring, 2–3 decision makers per firm, FullEnrich/Apollo emails, 5 personalised emails per person in Alessandro's voice (portfolio-based openers, real signals, outcomes), staged paused in Lemlist and diffed lead by lead.

• outbound-reply-followup-digest — Outbound | Daily follow-up digest: every outbound reply logged, meetings checked, today's follow-ups drafted per founder in #sales : Every weekday morning: sync every Lemlist reply (email and LinkedIn, all campaigns) into the outbound-replies table, check for each person whether a meeting is booked or held (both founders' Google Calendars, Granola, Lemlist), decide who must be answered or followed up today, draft each follow-up from the real thread (Lemlist inbox and the founder's Gmail), and post one message per founder in #sales tagging them, drafts in the thread. Drafts only: nothing is ever sent. Only rows that changed or are due are read each run. Hand-off, nothing to start: then cal-booking-to-website-leads-slack posts the demo when the prospect books one.

• outbound-textile-lookalike-italy — Outbound | Italian textile lookalike: from one reference mill to a paused Lemlist campaign and a call list : Turns a reference mill whose staff re-key emailed orders into Italian lookalikes with verified contacts, five-step Italian copy in Alessandro's voice, a paused Lemlist campaign and a call list with direct mobiles.

• outbound-yc-directory — YC directory: founders named and reachable before anyone else has them : The third and cheapest signal for the company-brain ICP. Sources the Y Combinator directory through Apify at $0.00105 per company, where the founder's name and LinkedIn arrive attached at 99.4 per cent fill, so the AI Ark people search never runs. Emails cascade: AI Ark export first at a measured 65 per cent cold hit rate, FullEnrich for the remainder, and every address gated against the domain qualified on the company's own site. Wave 1 ran 30 August 2026: 169 companies to 221 people in two draft campaigns, for well under a dollar of sourcing.

• pipeline-email-sync — Sales pipeline email sync: keep next actions true to the founders' latest emails : Twice a weekday: read Julien's and Alessandro's Gmail for every open sales-pipeline account (table 1175), and when an email after the last recorded touch shows the next action was done, rescheduled or replaced (a sent recap, an accepted invite, a reply with a new ask), rewrite next_action / due / owner / waiting_on / action_status / last_touch with the Gmail link as evidence. Never touches stage, deal value or client fields; never sends or drafts.

• platform-credit-watch — Platform credit watch: no platform key runs dry unannounced : Every morning (Tulina hosted agent, 08:30 Paris): read the balance of EVERY platform key Tulina pays for (oto_admin_platform_balances — whatever it returns, never a fixed list), set it against 7 days of use and the last 24 hours of 402s, write one row per key to table 931, and post to #billing ONLY when a key is under threshold, refused, or unmeasured and failing. Sunday: one all-green line so silence is never ambiguous. Read-only on everything but table 931 and #billing.

• pm-publish — publier un livrable produit : du brouillon local à la doc partagée (notion/confluence) — étape explicite, avec preview et confirmation.

• process-page-seo-pass — SEO | Process pages: measure every job, re-aim the live pages, map the missing ones : For tulina.ai's /processes/* catalogue: writes the phrasings a buyer would search for each live process page and for every job the connectors can do that has no page yet, measures them (DataForSEO volume, difficulty, suggestions) and reads the live Google results for the strongest. Scores each query on the cocoon ratio (volume x PMF² / (KD + 5)) with a process-specific PMF rubric that keeps template and definitional volume out, then re-aims the live pages on their best query (title tag, description and the PROCESS_TEMPLATE §8b sections the results page calls for), and queues the missing pages with the source each should be built from. A scheduled run publishes on its own under the org guide seo-unattended-publishing (founder decision, 18 October 2026); a run by hand hands the worktree to Julien.

• product-calls-to-tickets — Call feedback becomes tickets and doc gaps : Every call recorded during the day, on either founder's Granola account, is distilled overnight. An item is dropped when we already told the customer the feature exists, or when the company brain says it is already built. What survives is matched against the tickets in tulina-product-feedback (the product tracker since 25 October 2026, Linear is no longer used): a match adds the account, its quote and its MRR to that ticket; no match creates a new ticket row. The account's stage and MRR come from the Tulina table sales-pipeline (1175), not from Folk. Documentation gaps become counted rows. Each call that produced an action posts to #product with the customer, the ask and its MRR, and the ticket action goes in the thread. One digest closes the week on Friday. The corroboration count, not the ticket count, is what this exists to produce.

• product-calls-to-tickets-nightly — Nightly run of product-calls-to-tickets (steps 1 to 7b) : The nightly entry point of product-calls-to-tickets, run at 02:00 Paris by a Tulina hosted agent: yesterday's calls become tickets in tulina-product-feedback (no Linear), doc gaps are counted, and #product gets one message per call with the ticket action in the thread. All method lives in product-calls-to-tickets; this page only says which steps the nightly run covers.

• product-signal-digest — Friday product signal digest to #product : Every Friday at 16:00 Paris, post one message to #product summarising the week of product-calls-to-tickets: new issues, corroboration with the MRR behind it, what was already built, documentation gaps, what did not meet the bar. Reads the two product tables, writes nothing. The template lives in Step 7c of product-calls-to-tickets.

• product-update-every-other-monday — Send the product update every other Monday : Tulina's product update, end to end: on a production Friday an agent proposes what to feature from the last two weeks' dev digests, a second agent makes each picked film (script, voice, music, a render on GitHub, proof-read before Alessandro sees it) while the email is written, the list is kept current by two agents (every Monday, from the Tulina CRM tables and Stripe, and on each demo booking), and Resend sends the update the Monday after at 11:00. Each hosted agent runs its own section.

• prospect-knowledge-base — Prospect knowledge base from a website : Paste a company website URL and get a fully linked knowledge base in a Tulina org for them, then invite the owner and draft the onboarding email. Built from their public site, optionally enriched from documents they give you, and written so it survives being handed over. Use for prospect prep, demos, and client onboarding.

• prospect-plays — High-impact plays for a first sales call : Give a prospect's website and the LinkedIn URL of the person you are meeting, and get three to five ranked automation plays with flow diagrams, each pinned to something they said and each verified against a data source you actually touched. Use before a first call or discovery.

• qualify-accounts — Outbound | Qualify accounts: ICP yes / no / unknown for any list of companies : Takes a table of companies (one row per domain), enriches size, age and industry server-side (Lemlist DB then Apollo), classifies the type with Jev (GTM agency, B2B startup, traditional B2B, B2C/other), applies the ICP rules in plain code and writes ICP Yes / No / Unknown with a one-line reason. Optionally writes the result to the icp custom field of the Minari contacts. Never sends, never deletes. Evidence and definition: doc "ICP analysis, 23 October 2026".

• reddit-thread-scout — SEO | Reddit thread scout: find agentic RevOps threads and draft a reply for every one, for a human to post : Weekdays 09:40 Paris (hosted agent). Positions Tulina on SCALING AGENTIC REVOPS: running RevOps work (enrichment, scoring, CRM hygiene, outreach, pipeline) with many AI agents, reliably. Searches Reddit (reddit_search / reddit_subreddit, Google as fallback) in r/gtmengineering, r/revops, r/automation, r/AI_Agents and similar subs for threads about building agent automations for RevOps or running agents at scale, drops connector/MCP-setup threads, reads up to 8 and drafts a reply for EVERY thread read (Tulina mentioned in at most 1 draft in 4, always with disclosure). Logs every thread in seo-reddit-threads and posts the batch to #seo with no link previews. Never posts to Reddit itself: a person posts from their own account.

• sales-custom-lead-page — Sales | Custom lead page: a hidden tulina.ai page for one prospect, from the call to the follow-up email : Sales. After a demo call, builds a hidden page on tulina.ai for that one prospect: the system we would run for them drawn like the home page, one real run on live public data in their market (top ten scored companies with the rubric and a link to each source), what leaves their stack and what stays, unit prices, the engine process by process. Then checks the served build, ships it through a draft pull request, merges only on the founder's word, and leaves a follow-up email as a Gmail draft. First built for the /fr/yuma page.

• sales-demos-refresh — Sales | Daily refresh of the sales pipeline, real demos and conversion (Sales app) : Every morning: reads the founders' Cal.com bookings and new Granola notes, classifies each call (real demo, discovery, follow-up, customer, partner…) with its evidence in slot:sales_demos (table 1171), keeps slot:sales_pipeline (table 1175, the CRM of record, no Folk) current for what the calls and Stripe show: new accounts from calls, paid/MRR/org id, pains, team potential, and a next action only where none was set. Never overwrites a stage, deal value or next action a call run or a person set. Feeds the Sales app (app 13, filed in project SalesOps). Read-only on Cal.com, Granola and Stripe; never contacts anyone; no Slack post; no Folk.

• sales-discounted-payment-link — Sales | Discounted payment link tied to a customer org (Stripe) : After a call where a discount was promised: find the offer in the call note, create a one-use promotion code on the right coupon, and a one-use Stripe payment link whose subscription carries the customer's org_id, so billing links the subscription to their Tulina org on its own. Then hand the operator the one dashboard toggle the connector cannot do and put link + code into the follow-up draft.

• sales-leaders-fr-linkedin — GTM 1 · Source: French sales leaders (heads of sales, VP sales, CROs) from the free lemlist database into the accounts table : Hosted agent, weekdays 08:47 Paris. Keeps the free pool of French sales leaders (table 1229, lemlist database) filled, checks each person and company against the lane's rules, and writes their companies to the accounts table 1230 (track sales-leaders-fr), the person staying in the pool for the next stages. Writes accounts only; then gtm-account-scoring scores them, gtm-find-decision-makers takes the sales leader from the pool, and gtm-email-channel writes the LinkedIn message.

• sales-nda-signwell — Sales | NDA: a prefilled mutual NDA sent for signature through SignWell, from the template : Sales. Sends Tulina's mutual NDA (French, branded) to a prospect or partner through SignWell: reads the counterparty's legal entity from their own site, creates a document from the template with their details prefilled, reads the prefill back, sends it on the founder's word and follows up. Leaves the registration number, the signer and the title for the counterparty. First run: Yuma AI, 5 Nov 2026.

• sales-post-call-followup — Post-call follow-up: from the call note to a live lead in folk : Turn a recorded call into a drafted follow-up email and a live lead in folk: read the Granola note, draft against gtm-followup-email, create the contact and let folk resolve the company, fill the pipeline fields at company level, write the call recap, and set a dated reminder. Draft only, never sent.

• self-improvement-punchlist-digest — Daily self-improvement punchlist digest : Daily run, our own org (196) only. Re-verifies every open item in the self-improvement-punchlist datastore against live state before posting anything — never re-reports a fixed item as broken. Posts open items, grouped by category, to #general. Closes items that verification shows are already resolved.

• seo-article-drafts — Draft the next articles from your SEO queue, for a person to validate : Takes the top of your keyword queue, reads the live top 10 and what your site says, and writes complete, sourced articles for a person to validate: title, meta, body, FAQ from the People Also Ask questions. Rewrites the ones sent back. Never publishes.

• seo-cocoon-keyword-scoring — SEO | Score a connector cocoon: keyword volume, difficulty and PMF into one priority ratio per page : For one connector (LinkedIn, HubSpot, Salesforce…): pull the long tail of searches in the US and France from DataForSEO, merge variants, score each intent's product-market fit for Tulina from 1 to 3, compute ratio = volume × PMF² ÷ (KD + 5), assign every keyword to one page (the connector hub or one article), and publish the page ranking so a person picks what to write next. Writes the seo-cocoon-keywords table; never writes or publishes a page itself.

• seo-keyword-queue — Keep a queue of the searches your site should win : Every month: measures where your site ranks, finds new searches your buyers make, scores each one on demand, difficulty and fit with what you sell, and keeps a ranked queue of pages to write or improve. Capped at 1 USD of data a run. Never writes a page.

• seo-reddit-scout — Find Reddit threads where your buyers ask, and draft an honest reply : Weekdays: finds fresh Reddit threads where your buyers ask about the problem you solve, reads them, and drafts the most useful reply in the thread for a person to post. At most 1 draft in 4 names you, affiliation first, never a link. Never posts.

• signup-activation — Signup activation, planner: plan the first-week messages and the trial notices, never send : Every morning: plan the two trial notices for every member of every free workspace (t1 before the trial ends, t2 after; sent even to people who replied), read replies to hello@tulina.ai (fail closed), skip anyone a founder already has a meeting booked with (founder calendars in the Onboarding brief), find where each Tulina signup of the last 30 days is, and write the one due activation email per person into table 868. Has no email tool; the sender agent sends.

• signup-activation-send — Signup activation, sender: send the trial notices and every due email, hand Slack clients to the team, recap on Slack : Every morning at 11:00: in live mode, send the trial notices (t1/t2, every free workspace, no cap) first, then every due activation email of table 868 from hello@tulina-contact.com (team in Cc), fixed and AI-written alike; post Slack-client messages as drafts in #customer-success; post the recap on Slack with the full text of every AI-written email sent, for review after the fact. Draft mode: everything is a Gmail draft.

• signup-alert-to-general — Post each new Tulina signup to #general : Webhook relay: Logto calls this agent the instant someone finishes signing up to Tulina. The agent writes one line (name, email, app or Claude connector) and posts it to #general as the Tulina app; preprod test accounts and other apps are skipped.

• stripe-payment-to-billing-slack — New Stripe payment or failed payment → #billing alert : Every hour (Tulina hosted agent): read Stripe's successful charges AND failed invoice payments since the last one seen, and post one message per event in #billing — a payment with amount, who paid, what for and a first-payment flag; a failed payment with amount due, customer, org, attempt and the invoice link. Dedupe ledger in table 1107 (stripe-payment-alerts). Read-only on Stripe; silent when nothing new.

• tulina-brain-for-customers — Tulina brain for customers : Per-customer routine: check their stack via TheirStack + web research to recommend connectors on onboarding, then recommend processes by reading their own account signal (calls, email, gap reports, own tableaux), tiered by role-based connector feasibility (not literal tool match), posting candidates to #tulina-brain-customers for a person to validate before a customer ever sees them.

• website-process-from-real-doctrine — Build a tulina.ai process page from a real Oto doctrine, or from scratch : How to turn a real, running Oto doctrine from any org into a public /processes/* page on tulina.ai: sourcing the right doctrine, stripping client identity while keeping the real mechanics, and building the page to the site's PROCESS_TEMPLATE.md spec. When no doctrine or library entry does the job, it designs the process from scratch instead: from the article's own do-it-yourself steps and the connectors' verified tool operations, saved as an org procedure first so the page has a real source, then built as a page that claims no results it has not measured. A scheduled run publishes on its own under the org guide seo-unattended-publishing (founder decision, 18 October 2026); a run by hand hands the worktree to Julien.

• website-read-key-alert-to-product — Post the website read's key alerts to #product : Webhook (Tulina hosted agent 104): the hourly GitHub check of the onboarding website read's Anthropic key sends one delivery when its result changes (down, still down once a day, works again, or a test). Post its text to #product as the Tulina app, exactly as received, once. A dry run posts nothing. Nothing else: no other channel, no other tool.

• website-seo-article — Write a tulina.ai article that can rank : The full production of an /articles/* page on tulina-website. Pick the page with the highest summed ratio in the cocoon table. Read the live results page, then dissect the top five ranking articles. Write a brief: must-cover topics, gaps nobody fills, our own evidence, and a short slug of two to four words. Draft answer-first, with People Also Ask questions as H2s, "do it yourself" first, then a required "with Tulina" section with the exact prompt and the run trace of the process dedicated to that article's channel and job. Build at least five visual elements and verify on the served HTML with curl. Publishing: founder decision of 18 October 2026 (Julien: "I want this to be fully automatic"): a scheduled run publishes on its own under the org guide seo-unattended-publishing (merge, verify live, revert on failure); a run by hand hands the worktree to Julien.

• website-visitor-to-linkedin-invite — Website visitors signal --> CRM lookup --> data enrichment --> multi channel outreach : On each company lemlist identifies on tulina.ai (webhook), and in a daily sweep that catches anything the webhook missed, give each visiting company one decision: excluded, customer, live deal, no page signal, out of lane, or a new target with a named person and a short LinkedIn note written like a founder typing on his phone. Since v24 the note opens on something that just happened to the person (a raise, a new role, their own post, a launch, a hiring push, read from their LinkedIn posts and the news), then asks in one plain sentence whether a job we run is a topic for them right now; no product pitch, no compliment on their product, no signature, no em dash, no question mark, no mention of the visit. Since v29 the sales pipeline table (1175, with 1230 and 1247 as second reads) decides the lane and is never written to; TheirStack supplies the stack. Nothing is sent: the note waits at drafted with its hook and source on the row, a human approves it in the visitors table, and the sender re-checks the live network distance before every invite. #website-leads hears about an invite to approve or a deal back on the site as it happens and gets one short daily recap. Hand-off, nothing to start: then cal-booking-to-website-leads-slack posts the demo when a visitor books one.

• weekly-arr-to-billing-slack — Weekly Stripe ARR to #billing : Every morning 08:58 Paris (Tulina hosted agent; slug kept for continuity): turn the Stripe recurring book — plus prepaid plans billed outside a subscription, from tulina-arr-manual-contracts — into one ARR figure per currency, consolidate it into a single undated euro headline at the ECB reference rate, diff it against the last run at constant rate, and post to #billing with the movements and the client renewals coming up, so the team can make sure those clients are happy before they renew. Falls back to subscription-linked invoices when the restricted key cannot read subscriptions — and says so in the post. On Sunday runs only, also posts the ARR figures alone (headline, currencies, rate; no movements, renewals or errors) to #oto-tulina, compared with the previous Sunday.

• weekly-customer-relaunch — Weekly customer relaunch: every Monday, review each client, propose the relaunches and paste the drafts in #customer-success : Every Monday morning (Paris), review every paying client reachable on a Slack Connect channel or WhatsApp: where they are, how they use their workspace, what shipped this week, and which shipped features they asked for themselves. The client list comes from the Tulina table sales-pipeline (1175, is_client=yes) and active Stripe subscriptions, not from Folk. Post at most six relaunch proposals to #customer-success, one short line each, with the ready-to-send draft and the details in the thread. Never messages a customer.

• weekly-discovery-digest — Weekly discovery digest: new Granola calls into the discovery table and page, then a Slack summary, every Saturday morning : Every Saturday morning, read the external Granola calls not yet in the discovery table, add one row per call (value props that resonated, what fell flat, objections, price heard, next step), recompute the rolling counts on the Customer Discovery page in Fundraising, and post a short digest to #gtm. Never posts in a customer channel. Never renames the page.