Oteny Talents

The open catalog of Talents for your OtenyBot — your own private AI assistant on Telegram. A Talent is a ready-made personality and know-how that gives your OtenyBot a focused role: FlatbellyBot the flat-belly coach, ShopBot the shared aisle-sorted grocery list, StockBot the numbers-first stock analyst, TravelBot the travel concierge.

Everything here is open (Apache-2.0) — read any Talent end to end, learn from it, and publish your own. Oteny does the hard part — hosting your OtenyBot, running it safely, and covering the model bills — so a great Talent is all you bring.

Browse the live store at oteny.com/talents. Want to write one? Start at oteny.com/talents/build.

If you read nothing else, read this. It explains what a Talent actually is, why it's safe to run a stranger's Talent, and how a Talent gets from this repo onto a live bot.

A Talent runs on its own private server, sealed off from everyone else's. A Talent ships a persona (a voice + a job), a bundle of skills (markdown playbooks the bot reads), and often its own scripts the bot runs as tools (a first-run check, a data migration, a custom view); it composes the tools Oteny provides — web search, a database, a browser, a scheduler — by requesting them in agent-profile.yaml. Each user's OtenyBot gets its own always-on private computer — a real machine of its own, where it remembers what you tell it, keeps its own data, runs automations on a schedule while you're away, and grows its own tools and skills over time. The hard wall is between bots: a Talent can never reach another user's bot, their data, or Oteny's keys and control plane. So a Talent is powerful inside its own bot and powerless outside it — the blast radius of even a misbehaving Talent stops at the one bot running it, never anyone else's.

One honest caveat: "the bot running it" is yours. Isolation contains the blast radius; it doesn't make every Talent harmless to the person who installs it. Inside your bot a Talent has real reach — its scripts run on your own private machine, alongside your data, your automations, and the tools it requested. The wall keeps a bad Talent off other people's bots; it can't keep one off the bot you chose to install it on. So picking a Talent is a real (and perfectly normal) act of trust — and that's the other reason everything here is open: you, or a reviewer you trust, can read a Talent end to end before it ever touches your bot. Favor Verified Talents, skim what you run, and let the lint gate, neutralized test clones, and the on-device self-check carry the rest. Hard isolation plus open code is what makes a catalog of strangers' Talents safe to browse — and safe to run.

Oteny runs the bot; you bring the Talent. Each user gets their own OtenyBot in an isolated sandbox (its own memory, its own database, its own schedule). Oteny provisions it, keeps it running, and pays the model bills. A Talent is dropped into that bot — it never sees a server, a key, or another user.

A Talent reaches a live bot by git delivery. You push a commit. Oteny pulls that commit with its key and copies the files onto the bot. Your GitHub login never leaves your laptop. Files you have not pushed never reach the bot. active means the box booted — wait until delivery finishes before you test. Detail: how-delivery-works.md.

Two independent clocks. The store/website (what's listed at oteny.com/talents) and the per-bot delivery (what's actually running on a tenant) update on their own schedules — a Talent can be live on bots before its store page changes, or vice-versa. Don't assume one implies the other.

skills/
├── talent-authoring-standard/   the RUBRIC a Talent must meet (+ the lint rules that enforce it)
├── oteny-talent-authoring/      the HOW-TO: create → edit → package → publish
├── oteny-talent-dev-loop/       the TEST/SHIP loop: clone → reload → test → traces → green → tag
├── oteny-flatbelly-talent/      a private flat-belly coach          ┐
├── oteny-shopbot-talent/        one shared grocery list, by aisle   │ the four reference
├── oteny-stock-talent/          terse, numbers-first stock research │ Talents — read these
├── oteny-travel-talent/         a private travel concierge          ┘ as worked examples
└── _shared/                     scripts every bundle reuses byte-identical (selfcheck, migrate, …)
tests/                           the catalog's own unit + scenario tests (CI runs them per PR)
TOOLS.md                         the catalog of tools a Talent may request

The first three skills/ entries are the author docs — the rubric, the how-to, and the test/ship loop. The four *-talent/ bundles are reference Talents you can copy from.

Each marketable Talent is a self-contained directory:

Some bundle docs name Oteny platform skills (e.g. index-reconciler, which wires the Talent's routing) that run on the bot under ~/.hermes/skills/talents/<slug>/ — they are not in this catalog, so docs refer to them in prose plus that on-box path, never as relative markdown links into a missing folder.

Read the talent-authoring-standard (the rubric: numbered, verifiable do-lists — the "airline-pilot checklist" rule), then follow oteny-talent-authoring (create → edit → package → publish, with helper scripts). See TOOLS.md for every tool a Talent may request.

Linting proves the bundle is well-formed; it never sends the bot a message. To prove behavior, the oteny-talent-dev-loop stands the Talent up on a real, disposable, neutralized clone of a bot and runs your tests/scenarios/*.yaml against it — then lets you read the bot's debug traces, fix, and re-run in minutes:

lint-talent → clone → reload (your branch) → test → traces → fix → green → tag a release

This is also the only honest way to prove a migration works against real prior-shape data before it reaches a paying customer. (Today Oteny and trusted partners drive this loop via the Oteny dev CLI; one-push commit → staging → green/red for self-serve authors is rolling out.)

Run the gate locally, open a PR, and a reviewer verifies it (see CONTRIBUTING.md):

python skills/talent-authoring-standard/scripts/lint_upgrade_safe.py skills/<your>-talent
# exit 0 = pass, 1 = fail; add --json for machine-readable output

The same lint rules gate your PR, Oteny's delivery, and the on-device self-check — so a green PR means no surprise rejections. CI (.github/workflows/talent-lint.yml) runs it on every push. A merged Talent lists as Community until a reviewer marks it Verified; a clean automated test run can pre-clear that review.

This catalog is Apache-2.0 (see LICENSE + NOTICE) — open content, contribute freely. The Oteny platform that hosts and runs these Talents is proprietary and is not part of this repo. Paid third-party Talents may ship under a separate commercial licence, and a business's private Talents are not published here.