Onboarding

Onboarding

Use this skill when onboarding is pending or the user asks to onboard again. Finish with a durable profile and useful help using whatever authorized access is available. Connections are optional, not a prerequisite. Keep turns short and conversational, but complete the steps in order unless the user explicitly asks to skip one:

1. For an org admin, check whether the Slack bot is missing before offering setup. Otherwise go straight to personal connections through an authorized access skill.
2. Choose how you should sound.
3. Read connected tools for a real work snapshot.
4. Confirm your read, then propose and—with approval—create concrete help.

If they ask to stop, mark onboarding completed and do not raise it again. A returning user keeps what memory already knows; focus on what changed.

State and persistence

Memory is the source of truth. Before the first question, read the notebook with the memory tool and rewrite it with an ## Onboarding section and this exact marker:

- Onboarding: pending v2 since YYYY-MM-DD.

After every step, read and rewrite the full notebook, preserving existing content. Record connected apps, focus areas, people and aliases, deadlines, rules, recurring workflows, cron IDs, and published app links. On completion or an explicit stop, replace the marker with:

- Onboarding: completed v2 on YYYY-MM-DD.

Memory is not a file; never edit it with shell commands.

1. Connect accounts

Use the selected access skill to connect the apps the user chooses. The direct OAuth flow below is for the direct connector. Do not request new project keys from regular users or change credential grants during onboarding.

The surface already authenticated the user. Greet them by name; do not ask their name or role, and do not research them in the opening turn. Explain that connecting lets you act as them without seeing their password and can be revoked.

Slack bot first for admins

For a system-identified org admin on a human-started turn, read the admin skill's Guide Slack installation section and check GET /v1/admin/slack-installation before mentioning Slack bot setup. If their role is unclear, use GET /v1/admin/whoami; do not infer it from their title or being the first user.

• configured: true: skip silently and go straight to personal connections. Include no Slack setup heading, checklist, status announcement, or verification task.
• Confirmed missing bot: offer the setup early, with the available steps and links together as described in the admin skill. Do not make the admin ask for each step.
• Disabled or deferred setup: skip silently. A failed or unavailable status read is unknown, not missing; continue onboarding without advertising setup or claiming it is connected. Investigate only if the user asks.

An automatic greeting cannot read admin-only status, so omit Slack bot setup there; check on the first human reply instead. Never use a remembered setup state as a live check, and never ask regular users to provision it. Personal Slack or Composio access does not install the separate bot. Continue onboarding if setup is declined or blocked.

The web checklist includes the walkthrough and written instructions. Do not embed a second GIF alongside it. On other surfaces, use this walkthrough with the admin skill's instructions; on surfaces without inline images, share its link:

Image: Generate and copy a Slack app configuration access token

The walkthrough uses a demo workspace and shows generation and copying. Have them select their own workspace and paste the access token only into QM's secure setup form, never into chat.

Personal connections

Check Composio availability through GET /v1/composio/toolkits on the authenticated QM API. When available, load the composio skill with the skills tool, discover available apps, and use its consent flow for the user's choices. Reuse their connected accounts after checking identity and permissions; a project key is not proof that a personal account is connected. Do not ask them to create OAuth apps for connections this source already provides. Do not infer that Composio is unavailable from an empty direct OAuth list or a native provider-not-configured error. Explicit app restrictions and account permissions still apply; never switch credentials to evade a denial.

For direct OAuth, the live Connected apps block is the complete allowlist of providers configured by the admin. Offer direct OAuth links only for that list. If it is empty and no other authorized access path is available, skip account connection without advertising unsupported apps. Do not turn onboarding into provider configuration: do not ask for a Composio project key, new OAuth apps, or per-app auth configs just because access is missing. Continue with useful work; help configure a new source only if they ask. Otherwise ask which available services they use and present the returned connectUrl values together:

curl -sS -X POST "$AGENT_API_URL/v1/connectors/oauth/consent/mint" \
  -H "X-Agent-Capability: $AGENT_OAUTH_CONSENT_TOKEN" \
  -H "content-type: application/json" \
  -d '{"provider":"<configured-provider>"}'

Never construct the URL yourself. Omit providers that return oauth_not_configured. The user must tap the links; continue after asking them to approve the services they use. Mention a machine-local login only when the live Your logins block lists it.