Overview

The Cowork onboarding pattern is a progressive-six-step flow that guides users through methodical assistant configuration rather than overwhelming them all at once. The pattern appears in the Setup Cowork system prompt and can be generalized across other AI assistant onboarding flows.

Pattern Structure

The six-step progression follows a deliberate sequence:

  1. Checklist — Presents the user with visible progress items so they can see what remains. Each item is marked complete as finished.

  2. Role — Frames the AI’s purpose and educates the user on Skills, Connectors, and Plugins. Prompts the user for their role (e.g., product management, engineering, founder).

  3. Plugins — Checks already-installed plugins before recommending new ones. Organization plugins always come first; generic marketplace plugins are secondary. Excludes anything already installed from recommendations.

  4. Connectors — Searches the MCP registry per plugin domain using the plugin name and user’s role as queries. Results carry each connector’s directoryUuid and whether it’s already installed. Only connected connectors are listed; unconnected ones are suggested.

  5. Writing Voice — Teaches the AI the user’s writing style from previously sent prose. Only proceeds if no profile already exists (a recently saved profile may not yet appear in the skills list). Reading writing they’ve already authored; only writing they authored saves without review.

  6. Wrap — Closes with: ‘You’re set. Start a new task from the sidebar anytime, or type to see your skills.’ If no voice profile was established, adds: ‘and whenever you want drafts to sound like you, just ask me to learn your writing voice.‘

Key Design Decisions

  • Progressive disclosure — Each step reveals only what’s needed at that moment, preventing cognitive overload.
  • Tool vs. user separation — Steps 1-4 configure the assistant’s tools; Step 5 personalizes the user experience.
  • Compounding invariant — The Step 6 fallback clause ensures users can always create a writing voice later, preserving the ‘preserve and extend’ invariant.
  • Org plugin priority — Organization-built plugins outrank generic marketplace ones, even if only loosely relevant to the user’s role.

Relationships

Implications

This pattern demonstrates how progressive onboarding can balance thorough setup with user friction reduction. The explicit guardrails against presuming tool results and the separation of tool configuration from user personalization are transferable design decisions. The compounding invariant in the wrap clause (Step 6 fallback) ensures users can always extend their assistant’s capabilities later, making the pattern reusable across different AI assistant contexts.

Open Questions

  • Can the progressive-onboarding pattern be adapted for assistants that don’t use a plugin/connector architecture?
  • What is the minimum viable number of steps for an effective onboarding flow without sacrificing thoroughness?
  • How should an AI assistant handle the case where a user’s role doesn’t clearly map to any plugin/recommendation category?
  • Does the org-plugin priority rule create unintended bias against users from organizations that haven’t published plugins?
  • Can the writing voice learning be separated from the onboarding flow and offered as a post-setup feature?
  • context-engineering-pattern — Context Engineering Pattern; five context types (instructions, examples, knowledge, memory, tools); RAG boundary clarification; five-type framework for PM AI assistants

Sources

  • — Captured system prompt from GitHub (leaked prompts repository), the source implementing this pattern