Stop Repeating Yourself: Use Rules and Skills to Level Up Your AI Agent

Do you find yourself typing the same instructions into every new project chat? Or noticing that your agent consistently struggles in certain areas like frontend design, testing, or API patterns? Rules and skills solve exactly that.

Both are markdown files that provide persistent instructions for your agent, so you don't have to re-explain your preferences on every run. When triggered, the agent reads them automatically and incorporates them into its output.

Rules

Rules come in two flavors: global and workspace. Global rules apply across every workspace in your IDE. Workspace rules are scoped to a single project, useful for team conventions or framework-specific patterns. Workspace rules usually override or specialize global behavior.

Each rule also has a trigger type:

• Manual: you invoke it explicitly when needed
• Always on: the agent references it on every single run
• Model decision: the agent decides for itself whether the rule is relevant
• Glob: the rule activates only for files matching a pattern, like **/*.go for Go files or **/*.{js,ts,jsx,tsx} for a JS/TS project

Here's an example RULES.md I use for JS/TS projects:

---
trigger: glob
globs: **/*.{js,ts,jsx,tsx}
---

## TypeScript / JavaScript
- TypeScript is the default — never introduce plain `.js` files unless explicitly asked
- Strict mode always: `"strict": true` in tsconfig
- No `any` — use `unknown` and narrow it, or model the type properly
- Prefer `const` over `let`; never use `var`
- Use named exports over default exports
- Async/await over raw Promises; avoid `.then()` chains
- No barrel files (`index.ts` re-exporting everything) unless the project already uses them
- Avoid large synchronous operations on the main thread; prefer streaming over buffering where possible
- Unit tests live alongside source files as `*.test.ts`; E2E/integration tests may live in a dedicated folder.

Skills

Skills are more targeted than rules. When triggered, the agent reads the full skill file and uses it to guide its approach before responding. Each one lives in its own folder under a skills/ parent directory and provides deep guidance on a specific capability. The description you write for each skill is what the agent uses to decide when to invoke it, so it's worth being precise.

Here is a snippet of a frontend skill I use, based on one of Anthropic's Claude skills.

---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
---

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

## Design Thinking

Before coding, understand the context and commit to a BOLD aesthetic direction:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Commit to a distinct direction: brutally minimal, maximalist chaos, luxury/refined, lo-fi/zine, dark/moody, soft/pastel, editorial/magazine, brutalist/raw, retro-futuristic, handcrafted/artisanal, organic/natural, art deco/geometric, playful/whimsical, industrial/utilitarian, etc. There are infinite varieties to start from and surpass. Use these as inspiration, but the final design should feel singular, with every detail working in service of one cohesive direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it vigorously. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.

Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
- Production-grade, functional, and responsive
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail
...

How to get set up

Setting everything up is easy and only takes a few minutes. Most coding tools have a rules and skills section in their settings UI. For Windsurf, it's available under the three dots in the top right of the agent chat. Alternatively, you can create the files directly in the right location.

Skills - each skill is a SKILL.md file inside a named folder:

• Windows: C:/Users/[username]/.codeium/windsurf/skills/[skill-name]/SKILL.md
• Mac/Linux: ~/.codeium/windsurf/skills/[skill-name]/SKILL.md

Global rules - a single file:

• Windows: C:/Users/[username]/.codeium/windsurf/memories/global_rules.md
• Mac/Linux: ~/.codeium/windsurf/memories/global_rules.md

Workspace rules - stored in your project folder:

.windsurf/[rule-name].md

A couple of things to remember when creating files manually:

• Rules files need a trigger block at the top (see the example above)
• Skill files need a name and description in their frontmatter - that's how the agent knows when to use them

You can also find many pre-written rules and skills online, like this GitHub repo. Most modern coding agents support some variation of rules and reusable skills/prompts, though the exact format and triggering behavior differs between tools.

Pitfalls to keep in mind

• Too many always-on rules dilute adherence. If every rule is always active, the agent's context fills up fast and it starts glossing over instructions. Be selective — reserve "always on" for truly universal conventions and use glob or manual triggers for everything else.
• Conflicting rules create inconsistent outputs. If your global rules say "prefer functional components" and a workspace rule says "use class components for stateful logic," the agent will make a judgment call — and it won't always be the one you want. Audit your rules occasionally to make sure they don't contradict each other.
• Overly specific skills can reduce creativity. A skill that prescribes every decision leaves no room for the agent to adapt to context. Aim to set direction and constraints, not a step-by-step recipe — the best skills explain why something matters, not just what to do.
• Huge skill files increase context usage and latency. Every time a skill is invoked, its full content is loaded into the agent's context window. A 5,000-word skill file is expensive. Keep skills focused on one capability and trim anything that doesn't directly affect output.
• Agents sometimes cargo-cult rule text instead of reasoning. This is the subtle one. An agent that's told "always use named exports" might apply that rule mechanically in situations where it doesn't make sense, without understanding the tradeoff. Phrasing rules with brief rationale ("...because default exports make refactoring harder") helps the agent apply judgment rather than just pattern-match.

Good agents aren’t just about model quality anymore. A big part of the experience comes from the environment you build around them: rules, skills, context, and constraints. A few well-written files can dramatically change the consistency and quality of outputs across an entire project.

Thanks for reading! Rules and skills are one of those small setup investments that pay off fast, especially on longer projects where consistency matters. If you have any skills or resources worth sharing, drop them in the comments below!