Building Your First Claude Cowork Pipeline
Close this guidebook with something running.
The instinct is to pick your hardest problem. Don't. The first workflow should be small enough to ship and important enough to matter.
Three rules for picking well.
- Pick something you do at least weekly. A workflow you only run once a quarter is a bad first build. You won't have enough reps to learn what's working.
- Pick something with a clear input and output. "Generate a content brief from this topic" is good. "Help us improve our marketing" is not.
- Pick something where being wrong is recoverable. First builds break. Pick work where the cost of a bad output is low and the cost of trying again is low.
For most CPG marketing teams, the right first build is one of these. A content brief generator. A PDP audit on a single page. A weekly performance summary. Pick whichever you'd run first thing tomorrow.
For the rest of this chapter, the example will be the content brief generator. The same pattern applies to whichever workflow you pick.
Step 1: Spin Up a Project
Open Claude. Create a new Project for your brand or team. Give it a name that's obvious six months from now ("Brand Name - Content Operations" is better than "Marketing Stuff").
Upload your most-used reference documents to the Project's knowledge base. For a content brief generator, that means a few specific things.
- Your brand voice and tone guide.
- One or two of your best past briefs (so Claude has a model to follow).
- Your target persona documents.
- The current content wave or campaign brief, if there's an active one.
Resist the urge to upload everything. Five well-chosen documents beat thirty cluttered ones. The Project is context, not storage.
Step 2: Write the Custom Instructions
The custom instructions field at the top of your Project is where you turn Claude into a specialist. This is the highest-leverage piece of writing in the whole stack. Spend twenty minutes on it.
Cover four things.
- Who you are. "We're a CPG brand in [category]. We sell [product] to [audience]."
- How we write. Reading grade level, tone, words you never use, phrases that signal not us.
- Standing rules. "Never use em dashes." "Always include a hook angle." "Cite all stats with verified sources."
- Approval flow. "Drafts go to me for review before delivery." "Briefs are approved by the strategy lead before they go to writers."
Strong custom instructions reduce the number of times you have to correct Claude's output later. Weak custom instructions force you to re-explain context every single conversation.
Step 3: Build or Install One Skill
Now you need the procedure. The Skill.
You have two options. Either install one of Anthropic's pre-built Skills if it matches your need (the skill-creator Skill can walk you through building one). Or write your own from scratch.
For a content brief generator, the Skill might look like this in plain English.
- Take the raw topic and identify the target keyword.
- Run SEMRush to confirm search volume and difficulty.
- Analyze the top 10 ranking results for that keyword.
- Draft three hook angle options.
- Build a 5-section outline with key points per section.
- Save the draft to Notion or Airtable.
That's the Skill. Write it as a SKILL.md file with those steps spelled out clearly, plus examples of what a good brief looks like for your team. The skill-creator Skill will scaffold the file structure for you.
Don't over-engineer. The Skill is iterative. Ship version one. Improve it the second time you run it.
Step 4: Connect One MCP Server
Pick the system where your output needs to land. For a content brief generator, that's probably Notion or Airtable.
Install the MCP server, authorize the connection in Claude, and test that Claude can read and write to the right space. Start with read access only. Add write access once you're confident the Skill is producing the right output.
Don't connect five MCP servers at once. Pick one. Get it working. Build trust before stacking the next.
Step 5: Run It Manually First
Before you let Cowork run this autonomously, run it manually in Chat three times.
This isn't about the output. It's about watching where the Skill breaks. The first run will surface something you didn't anticipate. The second run will refine it. The third run is the one that earns Cowork.
Pay attention to a few specific things on each run.
- Where does Claude make assumptions you didn't expect?
- Where does the output need a human eye?
- Which steps could you tighten by adding to the Skill?
Update the Skill based on what you find. Update the Project's custom instructions if a recurring correction shows up. By the third run, the workflow should produce output close to "ready to ship" without you intervening on every step.
Step 6: Hand It to Cowork
Open Cowork. Point it at the same workflow. Give it the one-paragraph brief that describes what you want.
"For each topic in this list, run the brief-generator Skill. Pull SEMRush data for the target keyword, draft the title and hook angles, build the 5-section outline, and save the brief to the Content Briefs database in Airtable."
Watch the first run. Cowork should now be doing what you did manually, end-to-end, without you driving each step.
For the first week, verify every output. Don't trust the pipeline yet. Spot-check the keyword choice. Read the briefs. Check the Airtable records are clean. After a week of consistent good output, you can ease off the verification cadence. Spot-check periodically and keep watching for the jagged frontier moments where Cowork's confident output is also wrong.
Step 7: Iterate
The first workflow is never the final workflow. Plan to refine it weekly for the first month.
Three things to watch for as you iterate.
- Outputs that consistently need the same correction. That correction belongs in the Skill or the custom instructions, not in your manual edits.
- Steps that take longer than they should. Cowork may be doing unnecessary work, or the Skill may be ambiguous.
- New requirements from the team. The marketing lead wants briefs to include a CTA recommendation? Update the Skill.
By month three, the workflow should be running cleanly and rarely need attention. That's your signal to build the next one.
Common Failure Modes
A few patterns we see fail more than once.
- Skipping the Project step. Teams try to build the Skill first and end up re-explaining brand context every run. Build the Project first. Everything else compounds off it.
- Building before testing in Chat. Cowork amplifies what's in the Skill. If the Skill produces bad output in Chat, it produces bad output faster in Cowork. Test manually before automating.
- Connecting everything at once. Permissions become a mess. Start with one MCP server. Add the next only when the first is solid.
- Over-trusting the first runs. Spot-check for two weeks before you stop reviewing every output. The cost of a bad brief getting to a writer is low. The cost of a bad client-facing document going out the door is high.
- Building the hardest workflow first. First builds should be small enough to ship. Save the ambitious stuff for build three or four.
The teams that succeed treat the first workflow as practice. They learn the rhythm. Then they build the next four with that rhythm in hand.
Where to Go Next
You've now got a Cowork pipeline running. The next workflows will go faster because you know the pattern. The Project is already there. The team's Skills library is starting to grow. Your MCP connections are warming up.
The compounding starts now. Each new Skill gets used by the next workflow. Each new MCP connection unlocks new pipelines. Each new Project teaches you what to do differently on the next one.
A few practical next steps from here.
- Pick the next workflow from the five in Chapter 5, or pick something specific to your team's pain points.
- Audit which Chat conversations you're having repeatedly. Those are Skills waiting to be built.
- Talk to your team about which manual processes are eating their week. Those are the next pipelines.
- Set a quarterly check-in. Are the pipelines still doing what you need? Has the model gotten better? Are there new MCP servers worth adding?
The teams getting real leverage from Claude didn't build it all in a week. They built one piece, then the next, then the next. Each piece earned the right to the next one.
You closed this guidebook with infrastructure in place. The hard part is over. The interesting part starts now.