6 Months of Claude and Cursor, Part 1: Building Skills in Claude to Use with Cursor

With skills, you teach the AI to behave according to your project, your source code and the way you work. Let’s see this in Claude and Cursor.

Image generated with AI

In this post, I want to share an evolution in how I have been working with AI over the past six months, one that genuinely changed the way I use generative AI: skills.

I’m not talking about human skills. I’m talking about instruction files. Many developers who use Cursor, Claude and other tools are already familiar with the concept. The idea is to teach the AI to behave according to your project, your source code and the way you work.

In January 2026, I started a new chapter. I already knew Cursor existed. I’d been using Claude since 2025. But I had no idea what would happen when I decided to use both together, let alone that six months later I’d be building layers of instruction so the AI could understand me as a software engineer.

The Starting Point: January 2026

The first time I used Cursor, what impressed me most was the ability of the AI agent to navigate across projects in a workspace. That part is well known, nothing new there. But there were things it simply didn’t know.

It didn’t know that my system doesn’t use Entity Framework Core. It didn’t know that the .tsx files inside it are templates, not final components. It didn’t know that a C# method generating strings is, in fact, a React code generator. And above all, it didn’t know when not to touch anything.

I discovered the real potential of the two tools when I built a prompt with Claude to send to Cursor. But Claude got confused, and because the files generated by the system contained the generation class inside the generator itself, a prompt was fired to modify the generator through Cursor. Until that point, only I had ever changed those files, with great care.

But Cursor did the work. And from that moment on, I started shaping both Claude and Cursor so commands would be executed correctly. The result: in just four days, I went from 28% branch coverage in automated tests to 79%. A jump from 8,000 to 17,000 tests in a single project, tests good enough to expose quality improvements that had been hidden, from database structure to security, like using int type instead of long in the code base.

At the same time, I began using Claude as a thinking partner. I asked about architecture, requested template reviews and discussed product strategy. And I noticed that Claude had the same problem: in every new conversation, I had to re-explain everything: the stack, the template rules, the context.

That is when I realized: the bottleneck wasn’t the AI. It was the absence of persistent context.

That isn’t a new insight. But how I got there is the point.

What Is a Skill, Exactly?

A skill, in the context of Claude, is a Markdown file that is automatically stored and loaded in each relevant conversation. It works like structured memory: you define who you are, how you work, what the rules of your project are and when the skill should be activated.

In Cursor, the equivalent is the .mdc files inside .cursor/rules. These are behavioral rules that the AI agent reads before executing any task.

The fundamental difference between using AI with and without skills is the same as the difference between hiring a consultant and briefing a consultant.

Without the briefing, the AI improvises. With it, the AI executes.

The First Skill: The System Identity

The first skill I created was the most obvious and the most transformative. It was a description of the system for Cursor: what it is, how it works, what must never be changed.

I defined that it was a SaaS generator platform written in C# .NET 10. That it doesn’t use Dapper or EF Core. The templates are C# methods that generate output strings for .tsx, .cs, .css and .ps1 files. Those two repositories are always open alongside the MDS project, which is the canonical reference model. That configuration comes from internal .env files per platform.

The effect was that Cursor stopped suggesting Entity Framework and stopped trying to create migrations. When I asked for tests, it already knew the standard was FluentAssertions with Moq and xUnit, and that mocks had to respect the System interfaces. A single skill eliminated weeks of friction.

The Strategy: Skills as Layers of Intelligence

After the first one, skills began to multiply organically. Every time I identified a recurring processing pattern, I created a skill to guide its future use.

The critical insight was realizing that skills are not static. They evolve. When Cursor made a new kind of mistake, the corresponding skill gained a new rule.

Skills are living code. They document the learning that emerges from the partnership between human and machine.

What I Recommend for Those Starting Out

If you are thinking about using Cursor or any AI-powered code editor, don’t start with the prompt. Start with the skill.

Before asking the AI for anything, document who you are as a developer. Document your project: what it does, how it’s organized, what the sacred rules are that nobody can break. Document your patterns: how you name variables, how you structure tables, how you organize folders.

Then iterate. Whenever the AI makes a specific type of mistake, update the skill. Every time it gets something right in a useful way, reinforce the pattern.

Within a few weeks, you’ll have an agent that knows your code almost as well as you do.

Next Post

In Part 2, I’ll show you the skeleton of a skill.md file for coding purposes.