Rules and skills are both configuration artifacts, but they serve different purposes. Mixing them creates bloated rules that should be skills, or skills that are just reference material. Here's how to know which to use.

Configuring Your AI Assistant series

The Configuration Chaos

Without clear guidelines, developers create:

  • 600-line "rules" that are really workflow guides
  • "Skills" that are just prompt templates
  • Always-on rules that should be conditional
  • Context windows stuffed with unused guidance

Result: Slow responses, high costs, confused AI behavior.

The fix is simple: understand what each artifact type is for.

The Core Distinction

Artifact Purpose Content Type Activation
Rules What and When Passive reference Automatic (always-on or glob)
Skills How Active workflow Explicit invocation

Rules tell the AI what to notice. They're loaded into context automatically.

Skills tell the AI what to do. They're invoked when needed.

Rules: What and When

Rules are passive reference material. The AI reads them and knows something—no action required.

What Belongs in Rules

  • Schemas and formats: "JSON responses must have this structure"
  • Conditions and triggers: "When working with auth code, consider..."
  • Standards and constraints: "Never commit secrets"
  • Decision support: "Use PostgreSQL for transactional, Redis for cache"

Activation Patterns

Rules activate automatically via:

  • alwaysApply: true — Every conversation
  • globs: [...] — When matching files are open
  • Description matching — When AI deems relevant

Example Rule

---
description: "API response standards"
globs: ["**/api/**", "**/routes/**"]
alwaysApply: false
---

## Response Format

All API responses must follow this structure:

{
  "data": <result>,
  "error": null | { "code": string, "message": string },
  "meta": { "requestId": string }
}

## Status Codes

- 200: Success
- 400: Client error (validation, bad request)
- 401: Authentication required
- 403: Forbidden (authenticated but not authorized)
- 500: Server error

The AI reads this and knows the format. It doesn't need to do anything—the rule informs future decisions.

Skills: How

Skills are active workflows. The AI reads them and does something—multi-step procedures that produce results.

What Belongs in Skills

  • Multi-step procedures: "To create a PR: 1. Check status, 2. Stage, 3. Commit..."
  • File creation workflows: "Create these directories, add these files..."
  • Complex operations: "Debug by: reproduce, isolate, fix, verify..."

Activation Patterns

Skills activate via:

  • Explicit invocation: /skill-name
  • Description matching: User intent matches skill description

Example Skill

---
name: ship
description: |
  Ship code via PR. Review, commit, push, create PR.
  Triggers: "ship", "deploy", "create PR", "push", "ready to merge"
---

# Ship Code

## Instructions

When invoked:

1. **Review changes**
   - Run /review if not already done
   - Check for lint errors
   - Verify tests pass

2. **Commit**
   - Stage relevant files
   - Generate commit message (conventional commits)
   - Create commit

3. **Push**
   - Push to remote
   - Create tracking branch if needed

4. **Create PR**
   - Generate PR title and description
   - Link relevant issues
   - Request reviewers if configured

## Output

Show PR URL and summary of changes.

This is a procedure. The AI follows steps and produces output.

The Decision Framework

Quick Test

Question If Yes →
Is it reference material for editing? Rule
Is it a multi-step workflow? Skill
Does it create or modify files? Skill
Is it > 100 lines of "how to"? Skill
Is it needed in EVERY conversation? Maybe Rule

Content Type Mapping

Content Type Belongs In Example
Schemas, formats Rule "API responses use this structure"
Standards, constraints Rule "Never commit .env files"
When/if decisions Rule "Use UTC for all timestamps"
Multi-step workflows Skill "To ship: review → test → commit → PR"
File creation Skill "Create .ctx/ directory structure"
Complex procedures Skill "Debug: reproduce, isolate, fix"

Token Economics

Context isn't free. Every line you load is attention you spend.

The Cost of Rules

Every rule loaded into context consumes:

  • Tokens = money (API costs per conversation)
  • Tokens = attention (model has finite capacity)
  • Tokens = speed (more context = slower responses)

Why This Matters

A rule with alwaysApply: true loads in every conversation—even when someone asks "what's 2+2?"

If you have 20 always-on rules averaging 100 lines each, that's 2,000 lines of context consumed before the conversation even starts.

Size Guidelines

Artifact Target Max
Rule (alwaysApply) < 50 lines 100 lines
Rule (glob-triggered) < 100 lines 200 lines
Skill SKILL.md < 150 lines 300 lines
Skill references/ Unlimited -

Skills only load when invoked. Rules load based on activation. Choose wisely.

Soft Routing: Rules Can Mention Skills

Rules can reference skills, but this is guidance, not invocation:

# In a rule

## Workflows

For complex operations, use the appropriate skill:

- Create project structure: `/init-project`
- Ship code: `/ship`
- Debug issues: `/debug`

Important: This doesn't make the skill run. It tells the AI (and humans) that the skill exists.

Why It's "Soft"

Skills are discovered via description matching, not rule references. The rule text is a hint, not a command.

# In skill frontmatter - THIS is what enables discovery
description: |
  Initialize project structure. Create directories and config files.
  Triggers: "init project", "set up project", "create structure"

The AI finds skills by matching user intent to skill descriptions, not by reading rule text.

Worked Examples

Example 1: Code Formatting

Wrong: 200-line skill with formatting rules

Right: Rule with standards, skill for reformatting

# rules/formatting/RULE.md (40 lines)

---

description: "Code formatting standards"
globs: ["*.ts", "*.js"]

---

- 2 spaces indentation
- Single quotes for strings
- Trailing commas in multiline
# skills/format/SKILL.md (60 lines)

---

## description: "Reformat code. Fix formatting issues."

## Instructions

1. Identify files with formatting issues
2. Apply standards from @formatting rule
3. Run prettier/eslint
4. Report changes

The rule says what. The skill says how.

Example 2: PR Creation

Wrong: 150-line rule with PR workflow steps

Right: Skill for the workflow

# skills/ship/SKILL.md (100 lines)

---

## description: "Ship code via PR. Review, commit, push, create PR."

## Instructions

1. Review changes with /review
2. Run tests
3. Create atomic commit
4. Push to remote
5. Create PR with description

No rule needed—this is pure workflow.

Example 3: API Response Format

Wrong: Skill that "generates API responses"

Right: Rule with the format standard

# rules/api/RULE.md (80 lines)

---

description: "API standards"
globs: ["**/api/**", "**/routes/**"]

---

## Response Format

{
"data": <result>,
"error": null | { "code": string, "message": string }
}

No skill needed—this is reference, not workflow.

Migration Guide

Audit Your Rules

Look for:

  • Rules > 100 lines (candidate for splitting)
  • Rules with step-by-step instructions (should be skills)
  • alwaysApply rules that could be glob-triggered

Audit Your Skills

Look for:

  • Skills that are just prompt templates (should be rule or asset)
  • Skills that don't have workflows (should be rules)
  • Skills with minimal descriptions (won't be discovered)

Migration Steps

  1. Identify bloated rules: wc -l rules/*.mdc | sort -rn
  2. Extract workflows to skills
  3. Add rich descriptions to skills for discovery
  4. Convert alwaysApply to globs where possible
  5. Delete redundant artifacts

Common Misconceptions

"Rules can invoke skills"

Reality: Rules can mention skills. They cannot invoke them. The AI decides whether to use a skill based on description matching.

"More rules = smarter AI"

Reality: More rules = more tokens = slower, more expensive, potentially confused AI. Quality over quantity.

"Skills need rules to be found"

Reality: Skills are found via description field matching. Rich descriptions > rule references.

"alwaysApply is the default"

Reality: alwaysApply should be exceptional. Most rules should use globs or rely on description-based activation.

Key Takeaways

  1. Rules for reference, skills for action. Rules tell the AI what to know. Skills tell it what to do.

  2. Context has cost. Every line loaded consumes tokens, attention, and speed.

  3. Skills need rich descriptions. The AI can't use a skill it can't find.

  4. alwaysApply is expensive. Use globs instead when possible.

  5. If it has step-by-step instructions, it's probably a skill.

What's Next

The next post digs into the specific cost of alwaysApply rules—with real numbers from an audit that found 22 always-on rules totaling 2,700 lines loaded in every conversation.

Next: The alwaysApply Tax — The hidden cost of always-on rules