The Best Cursor Rules for Every Framework in 2026 (With Examples)

If you're using Cursor as your daily editor but haven't set up a .cursorrules file yet, you're leaving an enormous amount of productivity on the table.

Here's the reality: Cursor is already a great AI-powered editor out of the box. But without project-specific rules, the AI assistant has to guess what your codebase looks like, which conventions you follow, and how you want code to be structured. Sometimes it guesses right. Often it doesn't.

A well-crafted .cursorrules file turns Cursor from a general-purpose AI assistant into a context-aware coding partner that understands your stack, your patterns, and your preferences. I've seen developers go from accepting 30% of AI suggestions to accepting 80%+ — just by adding a single file to their project root.

This guide covers everything you need to know about Cursor rules: what they are, how to write them, real examples you can steal, and the mistakes that trip most people up.

---

What Are Cursor Rules?

Cursor rules are instructions that tell Cursor's AI how to behave when working in your specific project. They live in a file called .cursorrules in your project root directory (right next to your package.json, pyproject.toml, or go.mod).

When you open a project in Cursor, the editor automatically reads this file and applies those instructions to every AI interaction — whether you're using Cmd+K inline edits, Chat, or Composer.

Think of it like a system prompt, but scoped to your codebase.

Where to Put Them

my-project/
├── .cursorrules      <-- right here, project root
├── src/
├── package.json
└── README.md

The file gets picked up automatically. No configuration needed, no settings to toggle. Just create the file and start writing rules.

What Happens Without Them

Without a .cursorrules file, Cursor still works. But the AI falls back to generic patterns:

• It might generate class components when your React codebase uses only functional components
• It might use var instead of const in your modern TypeScript project
• It might ignore your project's error handling conventions
• It might write tests in Jest when you use Vitest
• It might add comments everywhere when your team prefers self-documenting code

None of these are catastrophic on their own. But multiply them across dozens of interactions per day, and you're spending a significant chunk of your time fixing AI output instead of building with it.

---

Why Cursor Rules Matter

The difference between a Cursor setup with rules and one without is stark. Here's what changes:

1. Dramatically Higher Accept Rates

The single biggest impact of good cursor rules is that you accept more suggestions as-is. Without rules, you might accept a generated function but then spend two minutes renaming variables, adjusting patterns, and reformatting. With rules, the output matches your conventions on the first try.

2. Consistent Code Across Team Members

When your .cursorrules file is checked into version control (and it should be), every developer on the team gets the same AI behavior. No more "well, Cursor generates it differently on my machine." One file, one set of conventions, consistent output.

3. Fewer Review Cycles

Code review comments like "we don't use default exports here" or "please use our custom error class" disappear when the AI already knows those conventions. Your cursor rules become a living style guide that the AI actually follows.

4. Onboarding Gets Easier

New team members can read the .cursorrules file to understand project conventions at a glance. It's documentation that also happens to be executable. And when they start using Cursor, the AI immediately generates code that matches the team's style.

5. The AI Becomes Context-Aware

This is the big one. Good cursor rules don't just enforce style — they teach the AI about your architecture. When Cursor knows you're using a repository pattern with dependency injection, it generates new services that follow that pattern automatically. When it knows your API uses a specific response envelope format, every endpoint it creates matches that format.

---

How to Write Good Cursor Rules

Writing effective cursor rules is part art, part engineering. Here's the framework that works.

Start With Your Stack Declaration

The first thing your rules file should do is tell Cursor what you're working with. Be specific:

You are an expert in TypeScript, Next.js 14 (App Router), React 19,
Tailwind CSS v4, Shadcn/UI, and Drizzle ORM with PostgreSQL.

This immediately narrows the AI's focus. Instead of considering all possible ways to build a web app, it focuses on your specific combination of tools.

Declare Your Conventions Explicitly

Don't assume the AI will infer your patterns from context. State them directly:

Code Style:
- Use functional components with arrow function syntax
- Prefer named exports over default exports
- Use TypeScript strict mode conventions
- Write self-documenting code; avoid unnecessary comments
- Use early returns to reduce nesting

The more explicit you are, the less guessing the AI has to do.

Define File and Project Structure

Tell Cursor where things live and how your project is organized:

Project Structure:
- /app — Next.js App Router pages and layouts
- /components/ui — Reusable UI components (Shadcn)
- /components/features — Feature-specific components
- /lib — Utility functions and shared logic
- /server — Server-side code (actions, db queries)
- /types — TypeScript type definitions

This context is gold. When you ask Cursor to create a new component, it knows exactly where to put it and what patterns nearby files use.

Include Do's and Don'ts

Explicit prohibitions are just as valuable as positive instructions:

Do:
- Use server actions for form submissions
- Implement optimistic updates for mutations
- Use Zod for all runtime validation

Don't:
- Never use `any` type — use `unknown` and narrow instead
- Don't use useEffect for data fetching — use server components
- Don't create API route handlers when a server action would work
- Never use inline styles — always use Tailwind classes

Provide Small Examples for Complex Patterns

For patterns that are hard to describe in words, a short code example is worth a thousand rules:

When creating server actions, follow this pattern:

"use server"

import { z } from "zod"
import { actionClient } from "@/lib/safe-action"

export const createPost = actionClient
  .schema(z.object({ title: z.string().min(1), body: z.string() }))
  .action(async ({ parsedInput }) => {
    // implementation
  })

The AI will replicate this pattern precisely for every new server action it generates.

Keep Rules Prioritized

Put the most important rules first. AI models pay more attention to content that appears early. Your non-negotiable conventions should be at the top; nice-to-haves go toward the bottom.

---

Example Cursor Rules

Here are real-world examples showing what good cursor rules look like for different stacks. These are condensed versions — production rules files are typically more comprehensive.

React / Next.js (App Router)

You are an expert in TypeScript, Next.js 14 App Router, React 19,
Tailwind CSS v4, and Shadcn/UI.

Key Conventions:
- Use functional components with TypeScript interfaces for props
- Prefer named exports: export function Component() not export default
- Use server components by default; add "use client" only when needed
- File naming: kebab-case for files, PascalCase for components

Component Pattern:
- Props interface above component: interface ButtonProps { ... }
- Destructure props in function signature
- Use cn() utility for conditional Tailwind classes
- Keep components under 80 lines; extract sub-components when larger

State Management:
- Server state: React Server Components + server actions
- Client state: useReducer for complex state, useState for simple
- URL state: useSearchParams for filter/sort/pagination
- No Redux, no Zustand — keep it simple

Error Handling:
- Use error.tsx boundaries for page-level errors
- Use try/catch in server actions, return { error: string } shape
- Display errors with toast notifications (sonner)

Data Fetching:
- Fetch in server components, not in useEffect
- Use Suspense boundaries with loading.tsx fallbacks
- Revalidate with revalidatePath() after mutations

Python (FastAPI + SQLAlchemy)

You are an expert in Python 3.12, FastAPI, SQLAlchemy 2.0 (async),
Pydantic v2, and Alembic.

Style:
- Use type hints on ALL function signatures and variables
- Use Annotated types for FastAPI dependencies
- Prefer async/await for all I/O operations
- Use f-strings for string formatting, never .format() or %
- Maximum function length: 30 lines. Extract helpers aggressively.

Architecture:
- /app/api/routes — Route handlers (thin, delegate to services)
- /app/services — Business logic layer
- /app/models — SQLAlchemy ORM models
- /app/schemas — Pydantic request/response schemas
- /app/core — Config, security, database setup

Patterns:
- Route handlers validate input and call services. No business logic
  in route handlers.
- Services accept Pydantic models, return Pydantic models.
- Use dependency injection for database sessions:
  async def get_user(db: AsyncSession = Depends(get_db))
- All database queries go through repository functions, never raw SQL
  in services.

Error Handling:
- Raise HTTPException in routes only, never in services
- Services raise custom exceptions (app/core/exceptions.py)
- Use a global exception handler to map service errors to HTTP codes

Go (Standard Library + sqlc)

You are an expert in Go 1.22, standard library HTTP (net/http),
sqlc for database queries, and pgx for PostgreSQL.

Conventions:
- Follow Effective Go and Go Code Review Comments
- Use standard library where possible; avoid unnecessary dependencies
- Error handling: always check errors, never use _ for error returns
- Use structured logging with log/slog
- Context must be the first parameter in any function that accepts it

Project Layout:
- /cmd/server — Application entry point
- /internal/handler — HTTP handlers
- /internal/service — Business logic
- /internal/store — Database layer (sqlc generated + custom)
- /internal/middleware — HTTP middleware
- /migrations — SQL migration files

HTTP Patterns:
- Use http.NewServeMux for routing (Go 1.22 enhanced patterns)
- Handlers are methods on a struct that holds dependencies
- Middleware wraps http.Handler (func(http.Handler) http.Handler)
- Return JSON with a helper: encode(w, status, data)
- Parse request bodies with a helper: decode(r, &target)

Error Handling:
- Define domain errors in /internal/domain/errors.go
- Services return domain errors
- Handlers map domain errors to HTTP status codes
- Never panic in production code

Rust (Production / Systems)

# Rust Production — Cursor Rules
# Production Rust: error handling, async, lifetimes, and systems programming

You are writing production Rust code. The project prioritizes safety,
performance, and clear error handling. Follow Rust idioms, leverage the
type system for correctness. Use the 2021 edition or later.

Error Handling:
- Use `thiserror` for library error types, `anyhow` for application errors
- Define domain-specific error enums with thiserror:
  #[derive(Error, Debug)]
  pub enum AppError {
      #[error("User not found: {0}")]
      UserNotFound(UserId),
      #[error("Database error: {0}")]
      Database(#[from] sqlx::Error),
  }
- Use Result<T, E> for all fallible operations. Never panic in library code.
- Use `?` operator for error propagation — don't call .unwrap() in production
- Use .expect("reason") only for provable invariants — document why

Ownership:
- Prefer borrowing (&T) over owning (T) in function params when possible
- Use &str instead of String for function parameters
- Use &[T] instead of Vec<T> for slice parameters

NEVER:
- .unwrap() in production code — it panics on None/Err
- panic!() for expected error conditions — return Result instead
- Ignoring compiler warnings — treat them as errors

TypeScript (Strict Mode)

# Strict TypeScript — Cursor Rules
# Zero-compromise TypeScript: no any, proper generics, exhaustive types

You are writing strict TypeScript with all strict compiler options enabled.
Every value is typed. Every edge case is handled.

Required tsconfig.json settings:
{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true
  }
}

The "No Any" Rule:
- NEVER use `any`. There is always a better type.
- Use `unknown` when type is uncertain — then narrow it:
  function processInput(input: unknown): string {
    if (typeof input === 'string') return input;
    throw new TypeError(`Unexpected: ${typeof input}`);
  }
- Use Record<string, unknown> instead of object or any for generic objects
- For JSON parsing: JSON.parse(text) as unknown, then validate with zod

Generics:
- Use meaningful constraint names: T extends Record<string, unknown>
- Prefer concrete types over overly broad generics
- Use conditional types for transformations, not runtime type assertions

NEVER:
- `as any` — use type narrowing or `as unknown as TargetType`
- `@ts-ignore` — fix the type error properly
- Non-null assertion (`!`) without a comment explaining the invariant

Vue 3 (Composition API)

# Vue 3 Composition API — Cursor Rules

You are working on a Vue 3 application using the Composition API with
<script setup> syntax. Stack: Vue 3.4+, TypeScript, Vite, Pinia, Vue Router 4+.

Conventions:
- Always use <script setup lang="ts"> — never Options API
- Components: PascalCase files (UserProfile.vue)
- Composables: camelCase with `use` prefix (useAuth.ts, useFetchData.ts)
- Pinia stores: camelCase with `use` + `Store` suffix (useUserStore.ts)
- Event emits: kebab-case (update:modelValue, item-selected)
- Props: camelCase in script, kebab-case in template

Reactivity:
- Use ref() for primitives, reactive() for objects/arrays
- Use computed() for derived state, never recompute in template
- Clean up side effects in onUnmounted()
- Use watchEffect() for reactive tracking; watch() when you need old value

Component Patterns:
- Define props with defineProps<{ title: string; count?: number }>()
- Define emits with defineEmits<{ 'update:value': [val: string] }>()
- Use provide/inject with typed Symbol keys for cross-tree state
- Keep components under 200 lines; extract composables for logic

NEVER:
- Options API in new code
- Direct DOM manipulation — use template refs
- Mutating props directly — emit events instead

SvelteKit (Svelte 5 Runes)

# SvelteKit — Cursor Rules

You are working on a SvelteKit application with Svelte 5 runes for
reactivity, TypeScript, and file-based routing.

Tech Stack:
- Svelte 5 with runes ($state, $derived, $effect)
- SvelteKit 2+ with file-based routing
- TypeScript strict mode
- Tailwind CSS, Superforms, Vitest + Playwright

Routing Conventions:
- +page.svelte — page UI
- +page.server.ts — load function + form actions (server-only)
- +page.ts — universal load function (runs server + client)
- +layout.svelte — shared layout wrapper
- +server.ts — API route (REST endpoint)

Svelte 5 Runes:
- Use $state() for reactive variables (not writable stores)
- Use $derived() for computed values (not $: reactive statements)
- Use $effect() for side effects (not onMount + $: blocks)
- Use $props() to declare component props

Data Loading:
- Load data in +page.server.ts load() functions, not in onMount
- Use form actions for mutations — not fetch() calls to API routes
- Access loaded data via export let data in +page.svelte

NEVER:
- Legacy Svelte 4 stores for new code — use runes
- Direct DOM manipulation — use bind: directives or actions
- fetch() in onMount for initial data — use load functions

Django REST Framework

# Django REST Framework — Cursor Rules

You are working on a Django 5.0+ API with Django REST Framework 3.15+.
Python 3.11+, PostgreSQL, Celery (Redis broker), drf-spectacular for OpenAPI.

Naming:
- Django apps: short snake_case nouns (users, orders, payments)
- Models: PascalCase singular (User, Order, OrderItem)
- Serializers: PascalCase + Serializer suffix (UserSerializer)
- ViewSets: PascalCase + ViewSet suffix (UserViewSet)
- URL patterns: kebab-case (/api/order-items/, /api/user-profiles/)

Architecture:
- Use ViewSets with routers for standard CRUD, APIView for custom endpoints
- Keep views thin — business logic belongs in service modules
- One serializer per action when request/response shapes differ:
  list → UserListSerializer, create → UserCreateSerializer
- Use select_related/prefetch_related in get_queryset, never in serializers

Permissions:
- Default permission: IsAuthenticated
- Use object-level permissions for resource ownership checks
- Always set permission_classes explicitly — don't rely on global defaults

Filtering and Pagination:
- Use django-filter for queryset filtering (avoid manual query params)
- Always paginate list endpoints — use PageNumberPagination
- Return { count, next, previous, results } envelope

NEVER:
- Business logic in serializers — use service functions
- Raw SQL queries in views — use the ORM
- Disable pagination on list endpoints

Node.js / Express + TypeScript

# Node.js + Express + TypeScript — Cursor Rules

You are building a Node.js REST API with Express and TypeScript.
Layered architecture: controller -> service -> repository.

Project Structure:
src/
  app.ts              # Express setup, middleware, routes
  server.ts           # HTTP server, graceful shutdown
  routes/             # Route definitions (thin layer)
  controllers/        # Request parsing, response formatting
  services/           # Business logic
  repositories/       # Database queries
  middleware/         # Auth, error handling, validation
  types/              # TypeScript type definitions

Patterns:
- Controllers parse requests, call services, format responses
- Services contain business logic — no Express types (Request/Response)
- Repositories handle all DB queries — no SQL in services
- Middleware handles cross-cutting concerns (auth, validation, logging)

Error Handling:
- Create a central AppError class with statusCode and isOperational
- All async route handlers wrapped with asyncHandler(fn) to catch throws
- One global error middleware at the bottom of app.ts
- Distinguish operational errors (404, 401) from programmer errors (bugs)

TypeScript:
- Type all function params and return values
- Extend Express Request for auth context:
  interface AuthRequest extends Request { user: JwtPayload }
- Use Zod for runtime validation of request bodies

NEVER:
- Business logic in controllers
- Direct DB calls in services — go through repositories
- Swallowing errors without logging

MCP Server (Python + FastMCP)

# MCP Server Development Rules (Python + FastMCP)

You are building a Model Context Protocol (MCP) server in Python
using the official `mcp` SDK with FastMCP.

Three primitives:
- Tools — functions the LLM can invoke (@mcp.tool())
- Resources — read-only data the client can fetch
  (@mcp.resource("uri://template/{id}"))
- Prompts — reusable prompt templates (@mcp.prompt())

Default to Tools. Use Resources for genuinely read-only blobs only.

Transport:
- stdio — local-only, single client (Claude Desktop). Zero auth needed.
- streamable HTTP — multi-client, network-accessible, bearer token auth.
- SSE — deprecated. Don't use for new servers.

Tool Patterns:
- Every tool needs a clear docstring — it IS the LLM's tool description
- Use Pydantic models or typed parameters (never **kwargs)
- Return structured data (dicts/lists), not formatted strings
- Validate inputs early and raise ValueError with clear messages

Project Layout:
services/my-mcp/
  server.py        # FastMCP entrypoint
  README.md        # Tool descriptions, install, env vars
  requirements.txt # mcp[cli] + deps
  .env.example     # Document required env, never commit real .env

NEVER:
- One giant server for unrelated capabilities — one server per domain
- Mutable global state in tools — tools must be stateless
- Skip error handling — tools should fail gracefully with clear messages

What These Examples Have in Common

Look at the pattern across all ten examples:

1. Stack declaration at the top (what tools/versions)
2. Style conventions (formatting, naming, preferences)
3. Architecture description (where things live, how layers interact)
4. Patterns with examples (how specific operations should be done)
5. Testing conventions (how to write tests for this project)
6. NEVER section (explicit prohibitions for the most common mistakes)

This structure works for virtually any language or framework.

---

Want all 48 rules? The full collection covering 16 frameworks is available on GitHub: github.com/survivorforge/cursor-rules. Use them free, or grab the Cursor Rules Mega Pack for organized, ready-to-drop rules with no setup friction.

---

Common Mistakes to Avoid

After reviewing hundreds of cursor rules files, these are the mistakes I see most often.

1. Rules That Are Too Vague

# Bad
Write clean code and follow best practices.

# Good
- Use early returns to avoid nesting beyond 2 levels
- Extract functions longer than 30 lines
- Name boolean variables with is/has/should prefix

"Clean code" means different things to different people. The AI needs specific, actionable instructions.

2. Rules That Contradict Each Other

This happens more than you'd think, especially in longer rules files:

# Earlier in the file
- Use server components by default

# Later in the file
- Always wrap data fetching in useEffect hooks

These two instructions are fundamentally incompatible in Next.js. The AI will get confused and produce inconsistent results. Review your rules file for contradictions periodically.

3. Putting Every Rule With Equal Weight

If everything is a priority, nothing is. Structure your rules from most important to least important. The conventions that matter most (architecture patterns, error handling) should be at the top. Minor style preferences (trailing commas, quote style) can go at the bottom — or better yet, be handled by your linter.

4. Not Including Negative Rules

Telling the AI what not to do is sometimes more effective than telling it what to do. If you've noticed Cursor repeatedly generating a pattern you don't want, add an explicit prohibition:

NEVER:
- Do not use barrel exports (index.ts re-exporting everything)
- Do not use enum — use const objects with 'as const' instead
- Do not create wrapper components that only pass props through

5. Ignoring Framework-Specific Patterns

Generic TypeScript rules are fine, but they miss the nuances of your specific framework. A Next.js project needs rules about server vs. client components, data fetching patterns, and routing conventions. A Remix project needs completely different rules about loaders and actions. Make your rules framework-specific, not just language-specific.

6. Never Updating the Rules

Your project evolves. Your rules should too. When you adopt a new library, change an architecture pattern, or discover a better convention, update the .cursorrules file. Treat it like living documentation. A stale rules file can be worse than no rules file at all — it actively pushes the AI toward outdated patterns.

7. Making the File Too Long

There's a sweet spot. Cursor rules that are under 500 words probably aren't detailed enough to be useful. Rules that are over 5,000 words start to dilute the most important instructions. Aim for 1,000-2,500 words for most projects. If you need more, consider whether some of those rules should be enforced by your linter or formatter instead.

---

Ready-Made Cursor Rules Collections

Writing cursor rules from scratch takes time. You need to think through your conventions, test how the AI responds to different instructions, and iterate. For a single project, that might take an hour or two. If you work across multiple languages and frameworks, you're looking at a full day of work.

That's why curated collections of cursor rules have become popular in the developer community. A good collection gives you battle-tested rules files for specific frameworks that you can drop into your project and immediately start getting better AI output. You customize the parts that are unique to your project and keep the framework-specific conventions as-is.

The key things to look for in a rules collection:

• Framework-specific, not generic. Rules for "React" are less useful than rules for "Next.js 14 App Router with Tailwind and Shadcn." The more specific the rules are to a particular stack combination, the better the AI output.

• Architecture patterns, not just style. Good rules go beyond formatting. They describe how your codebase is organized, how data flows between layers, and how errors are handled. This is the stuff that saves the most time.

• Tested against real projects. Rules that look good on paper might produce weird AI behavior in practice. You want rules that someone has actually used in production and refined based on real output.

• Regularly updated. Frameworks change fast. Cursor rules for Next.js 13 (Pages Router) are actively harmful in a Next.js 14+ (App Router) project. Make sure any collection you use tracks the latest framework versions.

---

Advanced Tips

Once you have the basics down, these techniques take your cursor rules to the next level.

Use Section Headers

Structure your rules file with clear markdown headers. This helps both human readers and the AI parse the content:

# Stack
...

# Code Style
...

# Architecture
...

# Patterns
...

# Testing
...

Reference Your Actual File Structure

Instead of abstract descriptions, reference real paths in your project:

When creating a new API endpoint, create these files:
1. Route handler: /app/api/[resource]/route.ts
2. Validation schema: /lib/validations/[resource].ts
3. Service function: /server/services/[resource].ts
4. Test file: /__tests__/api/[resource].test.ts

Include Response Format Preferences

Tell Cursor how you want it to communicate, not just code:

When responding:
- Show only the changed code, not the entire file
- Explain architectural decisions briefly
- If multiple approaches exist, recommend one and explain why
- Always consider error cases and edge cases

Create Rules for Your CI/CD Pipeline

If your CI enforces specific checks, include those as rules so the AI doesn't generate code that fails in CI:

CI Requirements:
- All exports must have explicit return types (enforced by eslint)
- No console.log in production code (use logger utility)
- All async functions must have error handling
- Test coverage must be maintained above 80%

---

Conclusion

Cursor rules are one of those small investments that pay compounding returns. A few hours of work on a .cursorrules file saves you minutes on every single AI interaction — and those minutes add up fast when you're using Cursor dozens of times per day.

The formula is straightforward:

1. Declare your exact stack
2. Define your conventions explicitly
3. Describe your architecture and project structure
4. Include examples for complex patterns
5. Add prohibitions for things you never want
6. Keep it updated as your project evolves

Whether you write your rules from scratch or start with a proven template, the important thing is to start. Even a basic rules file with your stack declaration and top 10 conventions will noticeably improve your Cursor experience.

---

Want to skip the setup work? The Cursor Rules Mega Pack includes production-ready .cursorrules files for every major framework and language — React, Next.js, Vue, Svelte, Python, Go, Rust, TypeScript, Django, Node.js, MCP servers, and more. Each rules file is battle-tested on real projects and updated for 2026 framework versions. Drop them into your project root and start getting dramatically better AI output in seconds.

Get the Cursor Rules Mega Pack ($19) →

Comments

[Survivor Forge]

This is exactly the gap I ran into building and distributing these rules. The copy-paste workflow breaks down at scale — drift across machines is almost immediate. APM's model of treating rules as versioned, lockfile-tracked dependencies is the right mental model. The apm.lock.yaml pinning to exact commits is particularly useful since rules evolve and a working setup should stay stable. Will dig into the docs — the distribution layer is genuinely the missing piece for this content category.

[Daniel Meppiel]

Nice collection. The part that always gets me with these lists is what happens after you pick the right rules file — someone on your team clones the repo and doesn't have it, or you're composing rules from multiple sources (framework rules + your org's security standards + a testing convention) and they start drifting between machines.

The curation problem is real, but the harder problem underneath it is that Cursor rules (and their equivalents in Copilot, Claude, etc.) are really dependencies — they should be declared, version-locked, and installed reproducibly. The same way you don't copy-paste lodash into your project, you shouldn't have to manually copy-paste .cursor/rules/ files either.

I kept running into this with my own team, so I ended up building APM (Agent Package Manager) — it's basically npm but for AI agent configuration. You declare your dependencies in an apm.yml and apm install pulls them down and deploys to .cursor/rules/, .github/instructions/, .claude/, etc., depending on which tools your team uses. Any git repo can be a package, so you could turn each of these framework rule sets into something installable with one command.

# apm.yml
dependencies:
  apm:
    - my-org/cursor-rules-nextjs
    - my-org/security-standards
    - community/testing-conventions

The part that matters most for teams: there's a lock file (apm.lock.yaml) that pins every dependency to an exact commit, so everyone gets the same setup. No more "hey, did you grab the latest rules?"

Would be cool to see some of these framework rule collections published as APM packages — that's the missing distribution layer for this kind of content. I work at Microsoft and maintain the project; happy to help anyone who wants to try packaging their rules. Docs here if you want the full picture.