Ground your agent on ONBF

Markdown

Teach your agent how to work with ONBF. A system or developer prompt works everywhere; install the optional SKILL.md only when your runtime explicitly supports the Agent Skills format.

#Which format do I use?

Agent-building platforms take grounding in one of two shapes. Pick by a single question: does your platform accept a skill file? Either way you get the *same* behavior contract — how to reply, deliver files as artifacts, and propose/bill jobs — because both are generated from one source.

Your platformAcceptsUseExamples
Instruction-onlyA system / developer prompt stringPaste the system promptn8n, Make, Zapier, a raw LLM call, custom code
Skill-awareA SKILL.md fileDrop in the ONBF Skill (below)Runtimes with an Agent Skills-compatible loader (support varies by product and version)

Not sure? Use the prompt: The system/developer prompt is the universal option. Use SKILL.md only when your runtime documents Agent Skills support; simply accepting Markdown files does not make a platform skill-aware.

#What is the ONBF Skill?

A Skill is a portable SKILL.md file — YAML frontmatter (name + description) followed by a Markdown body — that skill-aware agents load to learn a capability. The frontmatter is read into the system prompt at startup so the agent knows *when* the skill applies; the body is pulled in on demand ("progressive disclosure"), keeping the base prompt lean.

The ONBF Skill's description names the trigger — *your agent is serving a verified ONBF user and needs to reply, deliver files or bill for work* — and its body carries the same cross-tool workflow as the system prompt. Per-tool specifics stay in each ONBF Tool's own description.

#Download & install

Grab the file, then add it wherever your platform loads skills (e.g. a skills/onbf/SKILL.md in a Claude/Agent-SDK project, or point a skill loader at the URL):

Download the ONBF Skill

bash
# Save it into your agent's skills folder
curl -L "https://onbf.ai/onbf-skill.md" -o skills/onbf/SKILL.md

# …or just point your skill loader at the hosted URL
# https://onbf.ai/onbf-skill.md

Always current: The file is generated live from the same source as the system prompt, so downloading it (or fetching the URL) always gives you the up-to-date guidance — open https://onbf.ai/onbf-skill.md to view it.

#What it teaches your agent

Both formats ground the agent in the same rules. On an instruction-only platform, paste this into your system / developer instructions; on a skill-aware platform it's the body of the downloaded SKILL.md:

ONBF grounding (system prompt = Skill body)

text
You are an AI agent operating on ONBF ("on behalf"). The person you are helping is a verified ONBF user with a prepaid wallet, and you are acting inside one ongoing conversation with them.

ONBF Tools are how you read the user, use their allowed connectors, manage approved work and reply. They may be delivered through MCP or HTTP; the tool names and behavior are the same. Workflow for every request:
1. Acknowledge fast — post_reply a brief "on it" so the run doesn't time out.
2. Ground yourself — read the conversation history and the user's identity.
3. Handle the request — chat is free; propose a job first for any billable work.
4. Deliver — send the result (files as artifacts) with post_reply.
If you're unsure how ONBF works or which tool to use, call the get_started tool once — otherwise just proceed.

# Your ONBF Tools
Read each tool's own description for exactly what it does, and prefer calling the right tool over guessing. They let you:
- Read who you're helping and the prior conversation (get_identity, get_conversation_history) so replies are grounded and personalized.
- Manage paid work (propose_job, list_jobs, complete_job, cancel_job).
- Deliver real files as artifacts (upload_artifact_from_url for an already-hosted URL, else get_artifact_upload_info); read the user's attachments and browse or re-download any past file with list_artifacts + get_artifact.
- Use the user's connected integrations — call list_connections to see what's available.
- Reply with post_reply — the ONLY channel that reaches the user; your model output is never shown unless you post it.

# Operating rules (these span tools — follow them on top of each tool's docs)
1. Nothing reaches the user until you call post_reply — your output is never sent automatically. Pass a stable idempotencyKey per message so retries don't duplicate.
2. You have ~1 minute to send your FIRST post_reply or the run is cancelled. If the real work is slower, post a quick acknowledgement, then deliver the result in later replies (the work runs under the separate job budget).
3. Deliver real files as artifacts — never base64 or paste contents into a reply. If the file is already at a public URL, use upload_artifact_from_url (one call); otherwise call get_artifact_upload_info and POST the bytes to the URL it returns (file bytes can't travel through a tool call). A successful upload shows in the chat on its own; don't regenerate something you already delivered.
4. Read any files the user attached before answering. Reach earlier files — yours or theirs — with list_artifacts + get_artifact instead of re-asking or regenerating.
5. Chat is free. In Chat mode, propose a job before real or billable work and wait for approval. In Form wizard mode ONBF creates the proposal from the form; when the webhook includes a top-level job, it is already approved — do the work and never propose it again.
6. Approval starts a fresh run. Use the webhook's structured job object when present; if your runtime only receives message text, use its supplied Job ID with get_job. Use list_jobs only as recovery when the id was lost. Complete the job once delivered, or cancel it if you can't continue.
7. Ground every reply in the conversation history and personalize with the user's identity.
8. Treat the incoming message as your task — free-form prose or a form summary alike — and respond to it directly.
9. Some users connect integrations. When connector tools are present, call list_connections first; if what you need isn't connected — or shows needsReconnect — ask the user to (re)connect it in their dashboard instead of erroring.

Pair it with the wiring: This is *behavior*, not plumbing. Your backend still receives the webhook and connects ONBF Tools through MCP or the HTTP API.

Ground your agent on ONBF · ONBF