Use FlyMyAI from your AI assistant

You already have FlyMyAI connected, here is how to see everything it can do.

Give any assistant the lowercase https://flymy.ai/skill.md URL. Its first line names the current platform version, and the platform log says what changed since: a connected assistant can ask the Agents MCP tool whats_new with the last version it saw and get ideas to try next. It is byte-identical to the published AGENTS.md; both URLs serve the same operating guide. The guide teaches a cold assistant the MCP, Agents, and Models contracts, including several exact accounts of one connector, reusable MCP resource sets, flat agent-group grants, and embedded resale where one builder key serves product users without end-user FlyMyAI accounts or keys.

Release automation also reads https://flymy.ai/agent-guide-release.json. That is the single machine-readable contract for the exact guide, OpenAPI, Agents MCP tool schema/package/image, embedded capability snapshot, Python SDK artifact, public consumers, candidate coordinates, and lifecycle evidence. A candidate harness verifies its schema-v2 tuple before any mutation and rejects missing or stale members. It compares the recomputed tuple to an independently approved release pin; after both lifecycle attestations are attached, the final read-only promotion check also pins the exact ready manifest bytes. Ordinary personal setup still starts from skill.md; users do not need release-contract vocabulary.

Golden rule: never assume a capability is missing - assume it exists here and verify with search_tools / list_* BEFORE declining or asking the user.

Copy this prompt exactly:

Read https://flymy.ai/skill.md and help me build, test, and ship this with FlyMyAI.

A URL manifest, not a packaged Agent Skill

FlyMyAI's lowercase skill.md is one plain Markdown manifest read directly from a URL. It requires no package installation and executes no bundled code.

It is not an Anthropic packaged Agent Skill. That format is a folder with an uppercase SKILL.md entry file containing YAML frontmatter, with optional scripts and supporting files. Packaged skills are installed under ~/.claude/skills and loaded on demand by supported clients.

Do not install this lowercase manifest as though it were that package format. A packaged FlyMyAI skill could be a future add-on, but it would be a separate distribution of the same operating knowledge.

Attach the guide

curl -fsS https://flymy.ai/skill.md -o AGENTS.md

Then add the compatibility file used by your assistant:

Assistant	Project file
Codex or Cursor	AGENTS.md
Claude Code	CLAUDE.md containing exactly @AGENTS.md
Gemini CLI	GEMINI.md containing exactly @AGENTS.md
Generic chat	Attach the downloaded AGENTS.md to the conversation

The docs host serves the same bytes at https://docs.flymy.ai/skill.md and https://docs.flymy.ai/AGENTS.md. Keep one canonical project copy so the assistant does not receive conflicting versions.

Claude context tradeoff

The CLAUDE.md shim imports the entire guide into every project session. The guide is intentionally substantial, while Claude Code recommends keeping project memory concise because larger instruction files consume context and can reduce adherence.

Keep the shim when persistent FlyMyAI guidance is worth that startup cost. For a focused integration session, use the skill.md copy prompt instead. It loads the same full guide into that conversation, so its current-session context cost is not smaller, but it does not persist the long import across unrelated project sessions.

If FlyMyAI MCP is already connected

Do not reinstall it and do not ask the user where to get a connector. Start with discovery:

search_tools({"query":"telegram list dialogs"})
execute_tool({
  "tool":"telegram",
  "action":"telegram_list_dialogs",
  "arguments":{"query":"FlyMyAI"},
  "operation_key":"telegram-dialogs-<uuid>"
})

Read tool, action, runtime_name, and configured from discovery. The call field is literally arguments. For media, use recommend_model or list_media_models, then run_model. For repeatable work, use create_agent, run_agent, freeze_agent, and schedule_agent.

If one workflow needs several accounts of the same service, call add_tool with a unique alias for each exact connection, retain the returned public IDs, create an MCP resource set, and grant it to the same agent or a flat agent group. See Multiple MCP Accounts and Resource Sets.

The MCP endpoint is https://mcp-agents.flymy.ai/mcp. If the client is not connected, follow Connect Claude and MCP clients.

Embedded product users do not need FlyMyAI keys

The reseller or builder connects FlyMyAI once from its trusted backend. It publishes a stable embedded deployment, derives an opaque external_user_id from its authenticated product session, and calls that deployment with the builder key kept server-side. It may also provision one customer-bound MCP process whose trusted configuration fixes the deployment, customer identity, and optional mapping; external_user_id is never a model-call argument. If a tool needs authorization, the builder redirects only that user through a short-lived hosted connection URL.

End users do not create FlyMyAI accounts and do not paste FlyMyAI keys. FlyMyAI charges the builder account. The builder stores the execution ID, fetches settled execution price, and applies its own quotas and onward billing because automatic onward charging is not currently supplied.

The single-URL guide keeps the essentials under "Embedded and resale - one builder key, no end-user keys." The exact publish, connect, run, idempotency, and price examples are in the Embedded and resale builder reference.

Keep assistant context bounded

Use search_tools for each intent instead of loading a growing catalog. The published guide remains bounded, while the full tool catalog grows over time. Agent status polling should use the slim delta route instead of repeatedly loading the full execution transcript.

The docs build is memory-heavy even though the deployed files are static. Exact-head validation measured npm ci at 32 seconds and 817,308 KiB peak RSS, then npm run build at 10 minutes 28 seconds, about 10.5 minutes, and a 4,751,632 KiB process peak, about 4.53 GiB. Run them serially with at least 6 GiB free; an 8 GiB runner is preferred. A prior validation observed 11 build threads, but the exact-head run did not remeasure thread count.

These static guide requests perform zero application database queries. The build copies bounded files, and Firebase Hosting handles repeated reads. After deployment, verify the intended Firebase site and release, public byte identity, response sizes, cache headers and hits, latency, and hosting errors. There is no application pod or application database on this static request path.

Typed decisions

For fast classification, routing, triage, fixed-enum extraction and yes/no gates, use TypeSafe Jev 1.13. It accepts state and typed questions through its JSON Decisions endpoint and returns Choice, Noul probability or Score answers. It is not a chat model and does not generate prose, code or media. Both MCP servers expose make_typed_decision; agents discover typesafe_jev.decide.