AI Safety

AI Rule Frameworks

Why project instructions, skills, and public rule packs should be treated and reviewed like code.

Version: 2026-06-05

Summary

  • AI rules are not harmless text; they influence agent behavior.
  • Public rule packs may be used as inspiration, not installed blindly.
  • No unreviewed activation of foreign rules, skills, commands, or MCP access.
  • Project-specific AI rules belong in the repository and review process.
  • Local convenience rules may exist, but must not override project safety.
  • AI rules belong in development and review, not in production artifacts.
  • Rule changes are treated like security, CI/CD, or tool configuration changes.

Topic

AI rule frameworks, agent instructions, Cursor rules, Codex instructions, Claude project instructions, IDE rules, project prompts, MCP/tool rules, and public rule packs.

Starting Point

Many tools support reusable rules, skills, prompts, and tool definitions. They can improve consistency and reduce repeated explanations.

At the same time, rules steer tool behavior. A rule can grant broad permissions, weaken review, leak context, or instruct the agent to trust external material.

Risk

A team may install public rule packs or local convenience rules without review. That imports behavior into the project that nobody has approved.

Recommendation

Treat AI rules like code. Keep project rules small, versioned, reviewed, and project-specific. Public rule packs can be read and adapted, but not copied wholesale into a customer project.

Local rules are allowed for editor convenience, but they must not change project security boundaries, command permissions, deployment behavior, or data exclusions.

Review Checklist

  • Are project AI rules stored in the repository?
  • Are they short enough to review?
  • Do they grant tool access or weaken controls?
  • Are public rules used only as source material?
  • Are rule changes visible in pull requests?
  • Are AI-only files excluded from production artifacts where needed?

Wall rules

AI rules are code: review, limit, version.

External rule packs are an idea source, not an installation package.

Local convenience rules do not override project safety.

Rule changes are security changes.

AI rules belong in review, not production.

Open questions for a project

  • Which rule files are official for the project?
  • Who reviews changes to them?
  • Which local rules are acceptable?
  • How are public rule packs evaluated?