Skip to docs content
Browse documentation
On this page

First build: ad hoc execute, then persist

Agent playbook after Say hello on the Get started page (/app/onboarding): run one useful ad hoc execute, show the result, persist that working code as a package they own, and offer optional triggers without recommending one.

This guide is the playbook for a Minion team's first build: run one useful ad hoc request, then save that working code as a package the person owns — after they say hello from their agent on the Get started page, or after they skip that step.

The person may have arrived from /app/onboarding and pasted the first prompt into their agent. The built-in onboarding_quick_example prompt points here too.

Before you start

The team needs an authorized MCP app, which they just used to reach this guide. If they pasted the Get started prompt, follow it: explain what Minion can do, show the domains, pick one small thing to automate. If they skipped it, ask what they want to try and use whatever capabilities are already available.

Step 1 — Confirm the connection

Confirm the app is ready with search. If search fails because authorization is still open, tell them to finish the sign-in window and say when /app/onboarding shows the first step as connected. Try once more after they confirm. Do not poll.

If they have a remote MCP server in mind, minion.mcp.list() shows the ones already added. Do not add a server yourself: an owner or admin adds it at /app/mcp-servers.

Step 2 — Run one ad hoc execute

Use execute for a single useful call from their answer. Prefer capabilities that are already on the team: search, memory, a connected MCP server, or a package they own.

Show a short summary of the result. Do not create a package until this call works.

Step 3 — Persist the working code

Save that working module as a package they own with minion.packages.save. package.json is named @<team slug>/<name> and lists its exports, and a README.md says what it does. guide:package_with_daily_job has a complete example.

Name the package after the job it does. Then confirm it is searchable as theirs with search or minion.packages.list().

Step 4 — Name the ownership lesson

In one short message, explain that the package lives in their team: they can edit it, hang triggers on it, or write another. Other members and other connected agents can use it too. This is the permanence lesson for onboarding — not a practice run.

Step 5 — Offer triggers (optional)

Ask whether they want to hang a trigger on it: a webhook, an event subscription (for example new mail in the team inbox), a package app, a scheduled job, or skip for now. List the options without recommending one. If they skip, they are done with Get started.

Troubleshooting

  • Search fails or shows no results — the authorize window is still open, or they are signed in to a different team than the browser session. Wait for their "connected" message; one retry.
  • No remote MCP servers listed — none has been added yet. Ask what they want, or move on with built-in capabilities.
  • Package save rejected — the ad hoc module is incomplete, or package.json or README.md is missing. Keep the execute evidence, fix the package files, and save again. Do not invent extra packages.