Part of Mechanisms of Vibe Coding

Mechanism: Rules & Skills as Memory

One-sentence definition

Rules and skills as memory means storing stable project conventions in files the agent loads every session — so you do not re-type the same constraints, anchors, and guardrails in every chat.

The problem

Every new chat you repeat: pnpm not npm, no new deps, tests before commit, don’t touch legacy. By message three you forget one line. The agent forgets too — it only sees what is in this window.

Chat is amnesiac. Persistent rules are the project’s long-term memory for agents.

Symptoms:

• Re-explaining stack and conventions daily
• Inconsistent agent behavior across sessions
• Rules living in your head, not in repo
• .cursor/rules bloated with one-off task notes that never expire

How it works

Separate memory tiers:

1. Always-on rules — short, stable: package manager, test command, PR norms, negative space for frozen paths.
2. Skills / task playbooks — how to run a release, how to add a route — loaded when relevant.
3. Session prompt — today’s goal, constraints, acceptance criteria.

  Rules (persistent, repo-wide)
       +
  Skills (persistent, task-type)
       +
  Session prompt (this job only)
       │
       ▼
  Agent behavior aligned with team memory

Good rules are short and enforceable. “Run tests with pnpm test” beats “write good code.”

Bad rules duplicate anchors — point to README instead of copying it.

When to use it

• Team repos with repeated agent use
• Conventions that caused real incidents when violated
• Constraints and anchors that apply to most sessions
• Onboarding: rules document how the team vibes

When not to use it

• One-off task instructions — put those in the session prompt only
• Rules longer than a screen — split into linked docs
• Contradicting rules — resolve conflicts; agents follow random rule when confused

Failure modes

Rule sprawl — 40 rules, none read. Fix: Audit quarterly; merge and delete.

Session in rules — “Fix health bug today.” Fix: Rules = timeless; goals = chat.

Contradiction — Rule says format all; negative space says don’t touch unrelated files. Fix: Clarify scope in rules.

Stale rules — Still says yarn after pnpm migration. Fix: Update with stack changes.

Rules without verify — “Always test” without command. Fix: Name the exact verify command.

Minimal example

Context: Node API team using Cursor.

.cursor/rules (excerpt):

- Package manager: pnpm. Never suggest npm or yarn.
- Tests: pnpm test. Health route tests in health.test.ts.
- Do not add dependencies without explicit user approval.
- Do not edit src/legacy/** or Dockerfile without explicit request.
- Before claiming done, cite test command output from this session.

Session prompt adds today’s goal and slice — not repeated in rules.

Done when: A new team member’s first agent session matches conventions without oral briefing.

Tool instances (optional deep-dive)

Portable idea above; this section is tool-specific. Date: June 2026.

Cursor

• Project rules — .cursor/rules, AGENTS.md, team rules in dashboard.
• Skills — packaged playbooks for repeatable workflows (deploy, add API route).
• User vs project rules — project for team truth; user for personal prefs only.
• Keep always-on rules under ~50 lines; link to docs for depth.

Other tools

CLAUDE.md, Copilot instructions, custom system prompts in CLI tools — same memory tier.

Related mechanisms

• Anchor files — rules often point to anchors
• Constraints — session-level; rules are standing constraints
• Negative space — frozen paths belong in rules

Try it yourself

Exercise: Add or trim five lines in your project rules file. Each line must be checkable or actionable — no platitudes.

You need: .cursor/rules or equivalent; five minutes

Done when: Each line prevented a real mistake you’ve seen before.