Convert the marketing prompt workflows you've already written

How Claude Skills outperform Custom GPTs and prompt docs

Like a Skill, the tree continues to grow. Photo by author David E. Sweenor

Last Tuesday, I was chatting with Claude Code and wanted to write a new B2B messaging prompt workflow.^[1] Then I vaguely recalled writing one last year, so I searched Substack and realized I had a couple of them sitting there since 2025, just waiting and wanting to be used again.

That caught me. When I’m going in circles with Claude Code, Gemini CLI, or Codex, my first inclination is to write yet another prompt workflow. Most marketers I know do the same thing, and that instinct was right a year ago. It isn’t anymore.

I’ve published more than 100 articles on AI, marketing, and prompt workflows on insights.tinytechguides.com since early 2025. Each one was useful the day it went live. Most of them are sitting in the inventory right now, ready for reuse, and many of them are doing more than that. They’ve formed the basis for the 60+ Claude Skills I use regularly today.

Two weeks ago, I wrote about the four-component stack that makes Claude reliable for marketing work.^[2] Skills do the work, and three supporting pieces, CLAUDE.md, memory, and MCPs, make the Skills compound. That post explained why each component, on its own, falls apart. This post answers the question I kept getting in the inbox afterward.

You don’t need more prompt workflows. You need to package, refine, and continually improve the ones you have. The conversion is faster than writing a new workflow from scratch, and it’s what the rest of this piece is about. On the continual improvement side, the /reflect skill and napkin.md are for a future post.

A prompt workflow is a one-shot, whereas a Skill compounds.

A prompt workflow is linear. You paste it into a chat window, fill in the variables, and run it.^[3] You copy the output somewhere useful and close the tab. Run the same workflow next month, and it forgets everything that you fixed last time. The model has no memory of which variant you settled on, which phrasings you cut, or which output format your client preferred. Was it a deck? A Google doc or a webpage?

Stack a hundred of those together, and you have a prompt library. A library is the right starting point. Each entry was useful the day that you wrote it, and each one is one trigger away from working again. Unfortunately, none of them know about each other’s capabilities, and the library essentially acts as a drawer full of sticky notes.

“A library of prompt workflows is dormant inventory. A library of Skills compounds every time you use it.”

— David Sweenor, Founder/CEO, TinyTechGuides

When most of us started writing prompt workflows, Claude Skills barely existed, and we were still enamored with ChatGPT. Everyone was talking about prompt libraries, prompt engineering, organizational context, and Custom GPTs. We wrote workflows, reused them, and shared Custom GPTs. That was the toolkit at the time. The tech has evolved, and the work hasn’t been lost. Every saved prompt workflow is raw material for a Skill.

A Skill is a different unit, a folder that Claude loads when you invoke it with a slash command. Loaded into a project that has its own CLAUDE.md, its own memory folder, and a few MCP connectors, the Skill stops being a recipe in a drawer. It becomes a recipe in a kitchen, with a smart pantry that knows your preferences and appliances wired into your accounts. The next time you run it, the kitchen remembers the corrections that you made the last time.

The next ten workflows I write won’t move the needle, but the ones I convert into skills will.

What a Skill adds that a prompt workflow can’t

A prompt workflow is a recipe. A Skill is a recipe plus three things a recipe alone never had.

The first is a trigger. A workflow lives in a doc somewhere. To run it, you have to find the doc, copy the prompts, paste them into a chat window, and orchestrate the steps yourself. Custom GPTs are a little better. You can fire one off without having to hunt for the doc. They’re a pain in the butt to update, though, because every tweak means logging back into the GPT builder to edit the instructions and hoping nothing else broke. A Skill solves that update problem because every correction lands in the conversation, not in a separate builder window.

A Skill is a slash command. Type /review-article and the workflow runs. The Skill is a verb you can say to the project, not a script you have to fetch.

The second is inheritance. A Skill reads the project’s CLAUDE.md and your memory folder every time it runs. The variables you filled in by hand were your product name, your client’s industry, and your usual output format. Now, they all come pre-filled from files that already exist. One Skill works across many projects without reconfiguration. Run the same /review-article Skill in two different client projects, and you get two different reviews of the same draft, both correct, because each project’s rulebook carries its own voice.

The third is tool access. A workflow that ends with “now go pull the latest win-loss notes from HubSpot or Salesforce and bring them back” asks you to do half the work. A Skill wired to a Model Context Protocol (MCP) server goes and gets the notes. Per Anthropic’s documentation, Skills are organized folders that load only when relevant, and they live next to the tools they need.^[4]

“A Skill is the recipe that remembers where the pantry is.”

— David Sweenor, Founder/CEO, TinyTechGuides

The second run of a workflow is identical to the first, except for a new set of variables. The second run of a Skill inherits everything that the project learned the first time, and the third run inherits everything from the first two. The work that you put in once does more work each time you call it.

From workflow to Skill

The Strategic Battlecard workflow is one of the more popular ones I’ve published at TinyTechGuides.^[5] It’s a 10-step prompt workflow that produces a single-page battle card for a single competitor. You enter the competitor’s name, your product, and your industry. Then you add the proof points the workflow asks for, such as win themes from recent deals, and Gong call analysis. It’s the kind of doc you reach for when sales complains they don’t know how to position effectively against a competitor.

In its published form, the workflow is a long doc. To run it for a new competitor, you copy each prompt into a chat window in order and fill in the variables by hand, then copy the output between steps and stitch the final battlecard together yourself. About 40 minutes of orchestration on top of the 20 minutes of strategic thinking that the workflow is supposed to produce.

The same workflow as a /build-battlecard Skill takes about 4 minutes, and the Skill has grown beyond what the published version does. I type two arguments at runtime, the client name and the competitor name, and the Skill does the rest. It reads the client’s CLAUDE.md and messaging files, so positioning and differentiators come pre-filled. From there, it pulls fresh competitor intel from a /competitive-site-monitor Skill that runs on a schedule, plus win rate and pipeline-at-risk numbers from a /run-win-loss-analysis Skill that ran the last quarter’s deals. None of those inputs existed in the original workflow because it asked you to paste them in by hand.

When the Skill finishes, it writes two output files (a 2-page AE quick reference and a detailed deal-strategy version) and pushes both into Notion under the Competitive Center. Then it updates a tracker database (or spreadsheet) so the competitive coverage status stays honest. The published workflow produces one doc. The Skill produces a competitive system.

Converting a workflow into a Skill doesn’t require you to learn SKILL.md syntax. Open Claude and paste it into your workflow, then ask it to convert it into a Skill you can call with a slash command. Or sketch what you want the Skill to do, then paste the existing workflow as source material. Either direction lands you in roughly the same place. Save the file that Claude generates into .claude/skills/, and you’re done. If you’re migrating from ChatGPT Custom GPTs, the same path works. Paste the GPT’s instructions instead of a workflow doc and ask Claude the same question.

The next time you run the Skill, you can tweak it on the fly. Spot a phrase that you don’t like in the output? Tell Claude in the same window. Want a different output format for this client? Mention it. The Skill picks up the correction, and the next run inherits it. A workflow in a doc can’t do that, because every edit is a manual re-save.

I’ll walk through the line-by-line conversion in a future post. The pattern repeats across every Skill I’ve built. My /build-content-calendar Skill grew the same way. It started as a workflow doc. Now it reads the canonical Google Sheet through an MCP and writes the next week’s content row without me touching the chat window.

Pick ten. Don’t write any new ones this month.

If you’ve got a bunch of workflows you’ve written over the past year or two, you don’t need to convert all of them. Pick ten and let the rest stay in the inventory until you need them. Four criteria help you decide which ten go first.

The one you’ve run more than five times: Reuse signal beats novelty signal. The workflow that you keep coming back to is the workflow that pays off when it compounds.
The one that takes the most copy-paste orchestration to run: The more steps between typing the prompt and getting the output, the more the conversion saves you per run.
The one your team or your clients also run: Shared infrastructure beats individual heroics. A Skill that runs the same way for three people is worth converting three times faster than a Skill that only one person uses.
The one that touches a system you’d rather not export data from: The workflow that ends with “now go pull the latest deal notes from Gong” or “paste in the last week’s web traffic from GA4” is the workflow with the highest MCP payoff.

“Ten Skills running across three clients is thirty workflow runs a week. The library becomes the process moat.”

— David Sweenor, Founder/CEO, TinyTechGuides

The ten I convert this quarter become infrastructure. The other workflows wait in the inventory, fine where they are, ready for the next time I need one. If you’re stuck on where to start, pick the workflow tied to the angle that your readers can’t get anywhere else. The ten you pick are the ones that turn your library into a process moat.^[6]

The library you already have

Your library of prompt workflows is one conversion away from compounding. The next workflow you write can wait. Pick ten of the ones that you’ve already published and start there.

The full inventory of more than 100 prompt workflows lives at insights.tinytechguides.com. Pick ten this month and convert them. Don’t want to be writing new prompts six months from now? Subscribe, and the next post lands in your inbox.

Frequently asked questions

What’s the difference between a prompt workflow and a Claude Skill?

A prompt workflow is a linear sequence of prompts that you paste into a chat window, fill in variables for, and run step by step. A Claude Skill is the same workflow packaged into a folder that Claude can invoke with a single slash command. Skills inherit context from the project’s CLAUDE.md and your memory folder, pull data through MCP servers, and pick up corrections from one run to the next. A prompt workflow is one-shot; a Skill compounds.

What is a Claude Skill?

A Claude Skill is a folder of instructions, scripts, and resources that Claude loads when you invoke it with a slash command. Per Anthropic’s documentation, Skills are organized folders that load only when relevant. A Skill typically contains a SKILL.md file describing what the Skill does, optional templates or examples, and pointers to the MCP servers it needs. When you call a Skill in a project, Claude reads the project’s CLAUDE.md and memory folder to fill in context before running the workflow.

How do I convert a prompt workflow into a Skill?

Open Claude, paste your existing workflow, and ask Claude to turn it into a Skill you can call with a slash command. Or start with a sketch of what you want the Skill to do, then paste the workflow in as source material. Either direction lands you in roughly the same place. Save the file that Claude generates into your project’s .claude/skills/ folder. You don’t need to learn SKILL.md syntax by heart; Claude builds the file structure for you.

Which prompt workflows should I convert to Skills first?

Four criteria help you pick. First, the one you’ve run more than five times, because the reuse signal beats the novelty signal. Second, the one that takes the most copy-paste orchestration to run, because the bigger the orchestration, the more the conversion saves per run. Third, the one your team or your clients also run, because shared infrastructure beats individual heroics. Fourth, the one that touches a system you’d rather not export data from manually, because that’s where the MCP payoff is highest.

How are Claude Skills different from Custom GPTs?

Custom GPTs improved on prompt docs by letting you trigger a workflow without needing to find the source file. Skills go further. A Skill reads your project’s CLAUDE.md and memory folder every time it runs, so variables come pre-filled per project. A Skill can call the MCP servers to pull data from Gmail, Sheets, or a CRM. When you spot something you want to change mid-run, you tell Claude in the same window, and the Skill picks up the correction. Updating a Custom GPT requires logging back into the GPT builder.

Why is a library of Skills a process moat?

A library of prompt workflows is dormant inventory. Each entry is one trigger away from working, but nothing compounds across runs. A library of Skills is a process infrastructure. Each Skill inherits from CLAUDE.md and memory, calls tools via MCPs, and carries over corrections into the next run. Ten Skills running across three clients produce thirty workflow runs a week without writing new prompts. The library becomes Hamilton Helmer’s Process Power applied to a marketing function.

About David Sweenor

David Sweenor is a Top 25 AI thought leader, author, and founder of TinyTechGuides. He spent the first half of his career as a practitioner at IBM, working in data science, business intelligence, and data warehousing. In the second half, he led product marketing teams at SAS, Dell Software, Quest, TIBCO, Alteryx, and Alation, covering advanced analytics, AI, and B2B marketing transformation. He writes about AI for marketers, Claude Skills, prompt workflows, and B2B operator depth at TinyTechGuides.

Books

Follow David on Twitter @DavidSweenor and connect with him on LinkedIn.

Footnotes

^[1]Sweenor, David. “The Marketer’s Case for Claude Code.” TinyTechGuides, May 8, 2026. https://tinytechguides.com/blog/the-marketers-case-for-claude-code/

^[2]Sweenor, David. “The Four Layers of a Claude Stack (and why Skills alone fall apart).” TinyTechGuides, May 13, 2026. https://tinytechguides.com/blog/four-components-claude-stack/

^[3]Sweenor, David. “Marketing Mad Libs: Prompt Variables for Smarter Content Automation.” TinyTechGuides, February 17, 2025. https://tinytechguides.com/blog/marketing-mad-libs-prompt-variables-for-smarter-content-automation/

^[4]Anthropic. “Extend Claude with skills.” Claude Code Documentation, accessed May 15, 2026. https://docs.anthropic.com/en/docs/claude-code/skills.

^[5]Sweenor, David. “Strategic Battlecard Workflow for Competitive Wins.” TinyTechGuides Insights, July 14, 2025. https://insights.tinytechguides.com/p/strategic-battlecard-workflow-for

^[6]Sweenor, David. “The Marketing Moat Nobody Is Talking About in 2026.” TinyTechGuides, May 7, 2026. https://tinytechguides.com/blog/marketing-moat-2026/