Build Your First Claude Cowork Workflow Step by Step

Reading about Claude Cowork's capabilities is one thing; building a workflow that actually runs every morning without you babysitting it is another. This walkthrough is the hands-on version. We'll take a single realistic task — "every Monday, pull last week's support tickets, summarize the themes, and draft a status note" — and build it into a Cowork plugin you can run on demand. Along the way you'll touch every moving part: the connector, a skill, the prompt scaffolding, and a verification pass. Follow it in order and you'll have a template you can reshape for almost any recurring knowledge task.

Step 1: Scope the task before you touch anything

The most common reason early Cowork projects stall is starting with tools instead of the task. Before configuring a single connector, write the task as a precise sentence with explicit inputs and outputs. Ours: input is the support tickets created in the last seven days; processing is grouping them into themes and counting each; output is a one-page status note in our standard format. Writing this down forces you to notice you need exactly one data source and one formatting convention — not the dozen connectors you might have reached for.

This scoping step also tells you what success looks like, which you'll need for the verification pass at the end. A good rule: if you can't describe the finished artifact in two sentences, the task is too broad to automate cleanly yet. Split it first.

Step 2: Connect the one data source you need

Now wire the connector. In Cowork, connectors are MCP servers that expose your tools; for our task that's the support system. Add only that connector for now. Resist the urge to attach your CRM, calendar, and docs "just in case" — every extra tool adds schema text to context and gives the model more ways to wander. Connect the ticket source, confirm Claude can list and read tickets, and stop there.

Verify the connection with a tiny probe before building anything on top of it. Ask Cowork directly: "List the support tickets created in the last seven days and show me the fields available on each." If that returns clean, structured data, your connector is healthy. If it returns a wall of unfiltered JSON or an opaque error, fix that now — a noisy connector will sabotage every later step, and it's far cheaper to discover here.

flowchart TD
  A["Scope task to one sentence"] --> B["Connect single MCP source"]
  B --> C["Probe: list last 7d tickets"]
  C --> D{"Clean structured data?"}
  D -->|No| E["Fix connector / filtering"] --> C
  D -->|Yes| F["Add formatting skill"]
  F --> G["Write the run prompt"]
  G --> H["Add verification pass"]
  H --> I["Save as plugin & run weekly"]

Step 3: Add a skill for the output format

The grouping logic and the data come from the model and connector; the shape of the output should come from a skill. Create a skill folder with a clear description — "format the weekly support status note: theme table, top three issues, and a one-paragraph trend summary" — and a body that spells out the exact section order, the table columns, and tone. Keep the body tight; a skill that rambles will bloat context every time it loads.

The reason to encode format as a skill rather than cramming it into your run prompt is reuse and consistency. Next quarter when you build a similar note for a different team, you reuse the format skill and only change the prompt. It also means the model loads those formatting instructions only when this kind of task is active, instead of carrying them everywhere. Test the skill by asking Cowork to format a fake three-line dataset and checking it produces the right structure.

Step 4: Write the run prompt that ties it together

Now write the prompt that orchestrates the whole thing. Make it explicit about sequence and stopping conditions: "Pull tickets created in the last seven days from the support connector. Group them into themes; for each theme give a count and a one-line description. Identify the top three by volume. Then apply the weekly support status note format. If fewer than five tickets exist, say so and stop." Notice the guardrails — a small-data escape hatch and an unambiguous order of operations.

Resist writing the prompt as a vague wish ("summarize support and make it nice"). The model will fill gaps with guesses, and on a recurring job those guesses drift week to week. Concrete instructions produce stable, repeatable output, which is the entire point of building a workflow rather than chatting. Run it once end to end and read the result critically against your Step 1 success criteria.

Step 5: Add a verification pass

Before you trust this unattended, add a check. The cheapest version is a final instruction in the prompt: "Before finishing, verify every count in the theme table matches the ticket list you pulled, and flag any theme with zero supporting tickets." For higher stakes, spawn a sub-agent whose only job is to re-derive the counts from the raw data and compare. Either way, you're catching the failure mode where the model's summary quietly diverges from the source.

Verification is what separates a demo from a workflow you can stop watching. It's also where you encode the institutional knowledge that makes the output trustworthy — "ignore tickets tagged spam," "never report a theme with one ticket as a trend." Bake those rules into the check so they apply every single run, not just when you happen to remember them.

Step 6: Save it as a plugin and schedule it

Bundle the connector, the format skill, and the run prompt into a plugin so the whole thing is one reusable unit. Now it's portable: a teammate can install the same plugin and get the same behavior, and you can run it on a weekly cadence without rebuilding context each time. This packaging step is what turns a clever one-off into shared infrastructure your team relies on.

Once it's stable, iterate deliberately. Change one thing at a time — tighten the skill, add a second connector, adjust a count threshold — and re-run against last week's data to confirm you didn't regress. Treating the plugin like versioned software, rather than constantly re-prompting from scratch, is what keeps a Cowork workflow reliable over months.

Frequently asked questions

How long should my first Cowork workflow take to build?

Plan for an afternoon. Scoping and connector wiring are quick; the time goes into writing a tight run prompt and a verification pass, then testing against real data. Resist scope creep — ship the one-sentence task first, then extend.

Should formatting rules live in the prompt or a skill?

In a skill, almost always. Skills are reusable across workflows, load only when relevant, and keep your run prompt focused on orchestration. The prompt says what to do; the skill says how the output should look.

When do I need a sub-agent versus a final check in the prompt?

A prompt-level check is fine for low-stakes verification like matching counts. Spawn a sub-agent when the check needs its own substantial context — re-reading source documents, cross-referencing many records — that you don't want polluting the main run.

How do I keep the workflow stable week to week?

Make the prompt explicit about sequence and edge cases, encode rules in skills and the verification pass, and change one thing at a time when iterating. Vague prompts drift; concrete, versioned plugins stay consistent.

Bringing agentic AI to your phone lines

This same build-it-once-then-run-it-forever pattern is how CallSphere ships voice and chat agents that pull live data mid-call, follow a defined workflow, and book work 24/7 without supervision. See a working example at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.