Turn your prompt workflows into Claude skills
A 30-minute tutorial for marketers with a reusable prompt library
The workflow you already wrote is probably enough
Earlier this month, I went looking for a prompt workflow that I knew I had written. That’s usually a bad sign. The workflow already existed, the thinking was solid, and the structure still made sense, but I still had to find the post, copy the correct pieces, paste them into Claude, and move the outputs somewhere else.
That’s where most prompt libraries start to break down. The prompt usually holds up. The operating model around it breaks first, because a good workflow trapped in a post, Google Doc, or Notes still asks you to coordinate too much by hand.
I have more than 100 prompt workflows sitting inside the TinyTechGuides inventory. Some are useful references. A smaller number deserve promotion into something I can run without hunting through old posts. For this tutorial, I’m using one of the buying-committee workflows from the lead magnet project, Hidden Objection and Risk Surface Analysis. It already has the bones of a Skill because it defines the inputs, follows a repeatable process, and gives a PMM or sales team an output worth running more than once.
The goal here is not enterprise automation nirvana. I want to take one workflow that already works, package it so Claude can run it cleanly, and make the next run easier than the last one. The thinking is already done, so the job is to stop rebuilding it by hand every time.
The example: hidden objections
The Hidden Objection workflow is built for a problem that most PMMs recognize. Sales teams prepare for the objections that buyers say out loud, such as price, timing, integrations, or missing features. The deals that disappear into silence usually die somewhere else, when someone sees career risk, political risk, implementation risk, or budget risk and decides that doing nothing feels safer.
That makes it a strong workflow for this exercise. It is not a one-line prompt that asks Claude to brainstorm objections. The analysis starts with inputs, moves through six steps, and ends with a risk surface map that marketing and sales can use. It also asks for the same inputs that a Skill should collect, such as product, market, deal size, committee context, sales notes, and win-loss data.
The steps already behave like a process. It surfaces hidden objections by stakeholder role, maps the “no decision” incentive structure, looks for organizational risk triggers, and builds a mitigation plan. A final pass turns the analysis into content recommendations and a usable sales-facing deliverable.
What makes this workflow convertible
Not every prompt workflow deserves to become a Skill. Some prompts are better left as one-off thinking aids. A naming brainstorm or rough first-draft helper probably does not need a folder, a command name, and a maintained instruction file.
The workflows that deserve conversion have a few traits in common. You run them more than once, they ask for structured inputs, and their output needs to look consistent every time. They also carry enough judgment that you do not want each user improvising the process from scratch.
The Hidden Objection workflow passes that test. A slash command could be /hidden-objection-analysis. Its required inputs already live in Step 0, the reasoning path follows the six-step sequence, and the output can always include a risk surface analysis, content recommendations, and a short executive summary.
Expectations matter as much as those criteria. A first Skill does not need to connect to Salesforce, Gong, and every other system in the company on day one. The first version should do what the original workflow already did, with fewer chances to lose the thread.
Strip the workflow down to its operating parts
The easiest way to convert a workflow is to stop treating it as prose. An article explains the idea and gives the reader context. A Skill needs the operating parts.
In this workflow, the operating parts are easy to spot. Step 1 asks Claude to act as a senior B2B sales psychologist and buying committee analyst. It gives the business context, then Claude identifies the surface objection, hidden objection, root fear, behavioral signal, and trigger event for each stakeholder.
That is the old prompt structure hiding in plain sight. Role. Context. Task. Format. Tone. I still like that structure because it forces the hard thinking before the model starts generating, but it is not the finished product.
For a Skill, those pieces become reusable instruction blocks. The role gives the Skill its perspective, and the context becomes required inputs. The task becomes the process. Format becomes the output contract, while tone keeps the analysis direct instead of generic.
Each part has a direct translation:
- Role: who the Skill should act as
- Context: the inputs the Skill must collect before running
- Task: the ordered process the Skill should follow
- Format: the required output sections and tables
- Tone: the quality standard for the finished deliverable
That mapping is most of the conversion. Separate durable operating instructions from one-time article copy, then make those instructions easy for Claude to invoke.
Turn those parts into SKILL.md
Claude Code Skills are built around a SKILL.md file. Anthropic describes Skills as reusable instructions that Claude can load when relevant or when you invoke them directly with a slash command.[1] The file does not need to be complicated. It needs to tell Claude when to use the Skill, what inputs it needs, what process to follow, and what output to produce.
For the Hidden Objection workflow, a finished SKILL.md looks like this:
description: Build a hidden-objection risk surface analysis for a B2B buying committee. Use when the user wants to diagnose why enterprise deals stall, go quiet, or end in no decision.
argument-hint: “[company] [product] [solution_category]”
---
## Required inputs
Before running, collect or infer:
- Company and product
- Solution category
- Target industry and target organization size
- Typical deal size
- Existing personas or committee map
- Sales observations, win-loss notes, or stalled-deal patterns
If any required input is missing, ask for it before producing the analysis.
## Process
1. Identify the likely buying committee roles.
2. Surface hidden objections by stakeholder role.
3. Map the no-decision incentive structure.
4. Identify urgency accelerators and risk amplifiers.
5. Build a risk mitigation plan.
6. Recommend content and messaging that preempts the highest-risk objections.
## Output format
Return:
1. Executive summary
2. Hidden-objection table by stakeholder
3. No-decision incentive analysis
4. Risk trigger map
5. Mitigation plan
6. Content and messaging recommendations
## Quality bar
Write like a senior B2B product marketing advisor. Be candid, specific, and grounded in buying-committee behavior. Do not produce generic persona language.
That snippet is the compressed operating system for the workflow. The original prompt doc can still live as a reference file, especially if you want Claude to load the full step-by-step version when needed. The main SKILL.md should stay concise because the loaded Skill text stays in context once the Skill runs.[2] You can type that file out by hand, but it is faster to have Claude draft it from the workflow you already wrote, then check the draft against the shape above.
Have Claude draft the first version
Paste the prompt workflow into Claude and ask it to produce that structure for you:
I want to convert this prompt workflow into a Claude Skill.
Review the workflow below and create:
1. A concise `SKILL.md`
2. A clear description and argument hint
3. Required inputs
4. Core process steps
5. Expected output format
6. Quality rules
7. Any reference files that should sit beside the Skill instead of inside `SKILL.md`
8. A recommendation on whether this should be one Skill, several smaller Skills, or one orchestration Skill that points to companion Skills
Do not copy the workflow directly. Compress it into durable operating instructions.
Here is the workflow:
[PASTE WORKFLOW]
The first draft will probably be too literal, and that is fine. Ask Claude which parts are durable instructions, which details belong in a reference file, what inputs are required, where the Skill should ask clarifying questions, which steps can be combined, and what tends to break.
Atomization is the judgment call here. Do not split a workflow into separate Skills just because the original article had separate steps. Split it only when a subtask can stand alone and will be reused in other workflows. In the PMM stack, buying committee mapping, hidden-objection analysis, and committee-aware messaging could each become separate Skills over time, with a higher-level Skill telling Claude when to use those companion workflows and how to assemble the final deliverable.
Portability starts to matter once the workflow becomes part of the operating system. I am using Claude because it is where I run this marketing stack today. Codex and Gemini CLI now support agent skills built around SKILL.md, and both have project-context files that play a similar role to CLAUDE.md.[3] The names change by tool, but the operating idea holds. Repeated instructions belong in reusable workflow files, not in a prompt you keep pasting from a browser tab.
What changes when it becomes a Skill
You feel the difference the first time you run it. A prompt workflow says, “Here is how to do the work.” A Skill says, “Run this job.” With the old workflow, you open the source post, copy the prompt, paste the inputs, run the step, move the output forward, and keep going until the final analysis comes together.
With the Skill, the orchestration moves into the instruction file. You type something like /hidden-objection-analysis “Acme Analytics” “Decision intelligence platform” “enterprise analytics” and Claude knows what job to run. It can ask for missing inputs and return the output in the agreed format.
Each manual step has a Skill equivalent:
- A prompt workflow step becomes a SKILL.md instruction
- Pasting variables by hand becomes a required-input list
- Copying outputs across steps becomes a Skill-managed process
- A final doc assembled by hand becomes a standard output format
- A one-off chat run becomes a reusable slash command
The Skill gets better when it reads the rest of the project context. CLAUDE.md can tell it the company positioning, voice rules, output conventions, and where source files live. Memory can preserve recurring preferences. MCP connectors can eventually pull sales notes or account context instead of asking you to paste everything into chat.[4]
You do not need all of that on day one. The first useful version removes the copy-paste coordination. Later versions can read project context or reach into tools when the workflow deserves that extra plumbing.
The conversion pass I’d run first
If I were converting this workflow in a client project, I would start with one focused pass and stop when the Skill can produce a credible first output. The perfect version can wait.
Pick the slash command name. Use a verb phrase that describes the job, not the source document. /hidden-objection-analysis is better than /workflow-10 because it names the problem.
Pull the Step 0 variables into a required-input list. The workflow already has the correct inputs; they just live in article form instead of an input contract.
Compress the six workflow steps into process instructions. Keep the order, but cut the repeated setup. The Skill does not need six separate role blocks.
Lock the output format. For this workflow, I would require an executive summary, a stakeholder table, a no-decision analysis, a risk trigger map, and content recommendations. Readers trust the Skill when the shape stays stable.
Test it on one real stalled deal. A real opportunity exposes whether the Skill asks for the right inputs, notices the right stakeholder risks, and produces something sales would use.
That is the first 30 minutes. The next pass can add examples, reference files, scripts, or MCP access. Aim first for a repeatable instruction file that runs without you babysitting each step.
Promote the best workflows
Prompt workflows were the right unit for the first wave of AI marketing work. They forced marketers to define the role, context, task, format, and tone before asking the model to produce anything, and that discipline still matters.
The useful workflows now need a promotion path. Some can stay as posts, some belong in a gated PDF, and a smaller number should become Skills because they represent work you want to run repeatedly and improve over time. That last group is why the lead magnet matters. The PMM’s Prompt Playbook gives readers 11 workflows that solve real product marketing problems, and the next step is to choose the first one to convert, name the command, and make it easier to run the second time.
Start with the workflow that already gets reused, package it as a Skill, then run it once, fix what breaks, and let the next run inherit the improvement.
The prompt library was the raw material. The Skill is the operating procedure.
Frequently asked questions
What is a Claude Skill?
A Claude Skill is a reusable instruction folder that Claude Code can load when relevant or when you call it with a slash command. The core file is usually SKILL.md, which tells Claude when to use the Skill, what inputs it needs, what process to follow, and what output to produce. For marketers, a Skill turns a repeatable prompt workflow into something closer to an operating procedure, part of the broader move from chatbots toward agentic AI systems that plan work and act across tools.[5]
How do I convert a prompt workflow into a Claude Skill?
Paste the existing workflow into Claude and ask it to draft a concise SKILL.md with a description, argument hint, required inputs, process steps, output format, quality rules, and supporting reference files. Claude will often copy too much from the source on the first pass, so your job is to compress it into durable instructions and test it on a real example.
Should every prompt workflow become a Skill?
No. Convert workflows that you run more than once, require structured inputs, produce a stable output, and carry judgment that should not be reinvented each time. A brainstorming prompt, summary helper, or rough first-draft prompt can stay in your library.
Should one workflow become one Skill or several Skills?
Start with one Skill unless a subtask can stand on its own and will be reused elsewhere. Splitting a six-step article into six Skills usually creates more overhead than value. In a PMM stack, buying committee mapping, hidden-objection analysis, and committee-aware messaging could each support other workflows, so a higher-level Skill can orchestrate them as companions.
Do Codex and Gemini CLI support a similar idea?
Yes. Codex and Gemini CLI both support agent skills built around SKILL.md, and both have project-context files that work like a project rulebook. The file names and implementation details differ, but the operating principle is the same. Repeated instructions belong in reusable workflow files that the agent can load when needed.
What should I ask Claude after it drafts the Skill?
Ask which instructions are durable, which details should move into a reference file, what inputs are required, where the Skill should ask clarifying questions, which steps can be combined, what tends to break, and how to test it on a real stalled deal. The first draft is a starting point, not the final asset.
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 in data science, business intelligence, and data warehousing. The second half he led product marketing teams at SAS, Dell Software, Quest, TIBCO, Alteryx, and Alation across advanced analytics, AI, and B2B marketing transformation. He writes about AI for marketers, Claude Skills, prompt workflows, and B2B operator depth at TinyTechGuides.
Books
- Artificial Intelligence: An Executive Guide
- Generative AI Business Applications
- The Generative AI Practitioner’s Guide
- The CIO’s Guide to Adopting Generative AI
Follow David on Twitter @DavidSweenor and connect with him on LinkedIn.
Footnotes
[1]Anthropic. “Extend Claude with skills.” Claude Code Docs. Accessed June 16, 2026. https://docs.anthropic.com/en/docs/claude-code/skills.
[2]Anthropic. “Extend Claude with skills.” Claude Code Docs. Accessed June 16, 2026. https://docs.anthropic.com/en/docs/claude-code/skills.
[3]OpenAI. “Agent Skills.” Codex Manual. Accessed June 16, 2026. https://developers.openai.com/codex/codex-manual.md. Google. “Agent Skills.” Gemini CLI Docs. Accessed June 16, 2026. https://geminicli.com/docs/cli/skills/. Google. “Provide context with GEMINI.md files.” Gemini CLI Docs. Accessed June 16, 2026. https://geminicli.com/docs/cli/gemini-md/.
[4]Anthropic. “Connect Claude Code to tools via MCP.” Claude Code Docs. Accessed June 16, 2026. https://docs.anthropic.com/en/docs/claude-code/mcp.
[5]Purdy, Mark. “What Is Agentic AI, and How Will It Change Work?” Harvard Business Review, December 12, 2024. https://hbr.org/2024/12/what-is-agentic-ai-and-how-will-it-change-work.