Claude Skills Explained: My Workflow for Creating Reusable AI Agents with Cursor and Claude Code

The useful artifact in my Claude Skills workflow is not the markdown file itself. It is the moment when Claude sees a raw changelog pasted into chat and automatically turns it into a customer-ready newsletter without a special command, copied prompt, or manual setup. The skill disappears into the workflow, which is exactly the point.

In this episode of How I AI, I explain the structure of Claude Skills, test Anthropic’s built-in skill creator, then build and validate reusable skills locally with Cursor and Claude Code before uploading one to Claude’s web app.

I tested Anthropic’s new Claude Skills system in three ways: by reverse engineering Anthropic’s own built-in skill creator, by rebuilding the process locally with Cursor and Claude Code, and by packaging finished skills for the Claude web app. Across all three approaches, the same pattern emerged. A good skill is a repeatable task with recognizable input and output, plus enough instructions and examples to keep the model consistent over time.

The actual object is just a folder

One of the biggest sources of confusion in Anthropic’s documentation was surprisingly basic: what exactly is a Claude Skill?

So a CLA skill, the actual object, the thing that you make is a folder.

Inside that folder is a required `SKILL.md` file containing metadata and instructions. The folder can also include templates, examples, reference files, or executable Python scripts. Claude Code can use the folder directly from a local machine, while Claude’s web and desktop apps expect the folder to be zipped and uploaded.

That packaging model matters because it shifts AI workflows away from giant prompts pasted into chat windows. Instead of storing reusable prompts in Google Docs or scattered markdown files, I treat skills as modular assets with their own structure, dependencies, and validation logic.

The distinction becomes clearer when I compare skills to Claude Projects or custom GPTs. Projects keep a persistent context loaded into every conversation. Skills are dynamic and task specific. Claude decides when to invoke them based on the conversation itself.

I strongly preferred this natural-language approach over rigid workflow builders. Rather than defining brittle if-this-then-that automations, the instructions remain human-readable markdown that the model interprets contextually.

What Anthropic’s own skill creator revealed

Anthropic ships Claude with a built-in "create skill" capability. I used it less as a production workflow and more as a way to inspect how Anthropic itself structures high-quality skills.

I started simply by typing:

Help me create skills.

Then I asked Claude to generate a PRD-writing skill. Watching the process unfold gave me a useful mental model for how Anthropic expects skills to behave.

The generated skill was surprisingly elaborate. Claude appeared to reference example skills internally, inspect supporting examples, and then construct a large instruction package with multiple layers of guidance.

The resulting `SKILL.md` file included:

• Metadata describing the skill name and purpose
• Instructions defining when the skill should be used
• Decision trees for handling different PRD scenarios
• Output templates
• Best-practice writing guidance
• Clarifying questions for missing information
• Keywords intended to help skill invocation
• Links to example documents and supporting resources

One detail I found particularly useful was the inclusion of clarifying questions. Instead of forcing the model to immediately draft a PRD, the skill explicitly instructed Claude to gather missing information first. I would not have naturally included that interaction pattern in my own prompt engineering.

The exercise also exposed the limitations of Anthropic’s built-in flow. The generated package ballooned to roughly 12 files when I believed only five were actually necessary. Claude created extras like a license file and quick-reference guide that added complexity without improving the workflow.

Then the download failed entirely.

That failure pushed me toward a more inspectable local workflow. But the built-in creator still served an important purpose: it demonstrated what Anthropic considers a "complete" skill, including triggers, examples, templates, and structured instructions.

Building a reusable skill factory in Cursor

My preferred setup was dramatically simpler. I created an empty local folder called `claude-skills`, opened it in Cursor, and asked Cursor itself to generate a reusable meta-skill capable of creating future skills.

Create me a agent/skill for creating Claude skills. Here are the docs: https://docs.anthropic.com/claude/docs/skills-overview

Instead of relying on Anthropic’s hidden implementation, I directly supplied the public documentation and let Cursor construct the skill locally.

The result arrived in about three minutes. Cursor created a `create_skill` folder containing:

• A concise `SKILL.md` file
• Example skills
• Template files
• YAML metadata
• A Python validation script

Compared with the web creator, the local version was leaner and easier to inspect. The reusable meta-skill workflow keeps every generated file visible, editable, and easy to validate before reuse.

The validation script was one of the more interesting additions. Cursor generated a `validate_skill.py` file that checked metadata formatting, file references, and content structure.

I viewed the validator as useful but intentionally limited. It could confirm whether the skill package was structurally correct, but not whether the outputs were actually good. The script enforced consistency, not judgment.

That distinction became important later when the generated newsletter sounded wrong despite technically valid formatting.

The changelog-to-newsletter test

The first real production use case I chose was a weekly workflow I already performed manually for ChatPRD: converting technical changelog entries into customer-facing product updates.

Inside Claude Code, running from the local skills directory, I typed:

Use the create_skill Skill to create a skill for turning change log entries into a user facing newsletter.

Claude Code automatically discovered the local `create_skill` package, followed its instructions, generated a new `changelog-to-newsletter` skill, and validated the result with the Python script.

Unlike the oversized PRD generator from the web app, this skill was compact. It mainly relied on a single instruction file instead of a sprawling supporting bundle.

The more interesting behavior came next. I pasted a real changelog into chat without explicitly invoking the skill.

I literally just said, here's a change log, and it inferred what I wanted based on the skills available in my folder.

That automatic invocation is one of the strongest arguments for Claude Skills over copy-pasted prompts. The system recognized the context and selected the appropriate workflow itself.

The resulting newsletter draft was functional but flawed. I immediately noticed the tone leaned too heavily on emojis. That gave me a concrete editing target. Instead of endlessly tweaking prompts in a chat thread, I could revise the underlying skill itself and improve future outputs systematically.

This iterative loop is where the local workflow becomes powerful. The skill package acts like reusable infrastructure. You test against real examples, observe the failure modes, adjust the instructions, and rerun the workflow.

The Claude Code skill workflow covers the command-line loop I used to generate, inspect, validate, and refine the package locally.

Why executable scripts matter

I repeatedly returned to one technical capability I think is underrated: skills can bundle executable Python scripts.

That matters because AI-generated code is inherently variable. If Claude writes a fresh validation script every time, the behavior may drift subtly across runs. Packaging stable scripts inside the skill removes that uncertainty.

In my examples, Python handled validation checks. But the same pattern could apply to data cleaning, analysis, formatting, or implementation tasks where consistency matters more than creativity.

The model still orchestrates the workflow through natural language instructions, but deterministic operations can be delegated to code that stays fixed.

This hybrid model is part of why I see skills as more flexible than traditional workflow automation tools. The instructions stay conversational and adaptable, while the stable operations live in scripts and structured files.

Packaging a local skill for the Claude web app

After building and testing skills locally, I demonstrated how to move them into Claude’s hosted interface.

The process itself was simple: compress the skill folder into a zip file and upload it into Claude’s skills UI. But even here, the constraints of the system shaped the workflow.

My first upload failed because the skill name violated Anthropic’s naming rules. The metadata required lowercase, hyphenated names.

After renaming the package to `demo-to-follow-up`, re-zipping the folder, and uploading again, the skill loaded successfully.

That skill transformed customer demo notes into personalized follow-up emails. I demonstrated the upload and activation flow rather than a complete production pipeline, but the pattern was clear: build locally where iteration is fast, then package the finalized workflow for broader use inside Claude’s web app.

Once a skill is stable locally, the Claude.ai upload workflow shows how to package the folder, upload it, and verify that Claude invokes it on the intended task.

Where this workflow actually fits

The strongest use cases I showed all shared the same structure. The inputs were recognizable, the outputs were predictable, and the workflow benefited from consistency over time.

Weekly changelog summaries, PRD generation, and demo follow-up emails all fit that pattern. They are repetitive enough to justify setup effort, but nuanced enough that rigid automation systems often become brittle.

Skills are less compelling for highly exploratory work where the task changes dramatically each time. They also require judgment during refinement. The validator can confirm the YAML is correct, but only a human notices when a newsletter sounds awkwardly enthusiastic or overloaded with emojis.

The reusable lesson from my workflow is not "create more AI agents." It is narrower and more practical. Start by identifying repeated language tasks with stable structure. Package the instructions, examples, and checks into a local folder. Test the workflow against real inputs. Revise the skill whenever the output misses tone, structure, or intent. Then move the stable version into a portable package you can reuse across environments.

The important constraint is that the task itself must already be reasonably well understood by the human using it. Claude Skills make repeatable judgment easier to reuse. They do not eliminate the need for judgment in the first place.