By PromptLeadz · Reading time 16 minutes · 50 .md files across 5 categories · Calibrated for 2026 coding agents

What separates the engineer from the AI-influencer

AI tooling is one of the most LinkedIn-saturated categories of the last two years. Threads about vibe coding, the secret prompt that 10x'd a workflow, the agentic future, and the prompt engineer as the new senior IC role get hundreds of thousands of likes. The threads describe a vibe. The actual work is files you commit.

An engineer's AI tooling work, when it compounds, looks like a CLAUDE.md that survives a year of project drift, an AGENTS.md that holds across Codex and Cline without divergence, a .cursorrules that catches the bugs the team kept shipping, a custom GPT instruction set that produces consistent code reviews. None of these artifacts look exciting on a screenshot. All of them sit in version control and compound across sprints.

Six dimensions separate the engineer voice from the AI-influencer voice. Substance: the engineer names the specific stack, file path, and convention; the influencer names the disposition (10x, agentic, supercharged). Commits: the engineer commits the config to the repo where the team can review and edit it; the influencer screenshots a prompt in a thread. Constraints: the engineer names the things the model must NOT do (do not edit lockfiles, do not bypass migrations, do not commit secrets); the influencer names only what the model should do. Stack specificity: the engineer writes one file per project tuned to that project's stack; the influencer writes one universal mega-prompt that pretends to fit every codebase. Review discipline: the engineer treats the agent config as code, reviewed on PR; the influencer treats it as a personal artifact. Audience: the engineer writes for the agent and the next engineer reading the file; the influencer writes for the algorithm.

Both voices exist in the wild. Only one survives the third PR review, the new-hire onboarding, and the eighteen-month codebase migration. This pack is calibrated for the first; it explicitly rejects the second at the file level by banning the genre's signature phrases inline. Each file reads like a config an engineer would defend in a PR review, not a prompt screenshot from a thread.

Why .md won as the AI agent config format

The format wars of 2023 to 2025 are over. JSON config files lost. YAML configs lost. Custom DSLs lost. Markdown won. The reasons are operational.

Markdown is committable. A .md file lives in the repo next to the code it governs. It diffs cleanly. It reviews like a code change. The team can argue about it on the PR. JSON configs and bespoke formats sit in a tool's settings panel where nobody but the owner sees them.

Markdown is human readable. The next engineer reads it without parsing. A new hire onboards by reading the CLAUDE.md before reading the code. JSON configs require mental gymnastics; YAML configs require knowing the schema; markdown reads as English plus light structure.

Markdown is tool-agnostic. The same patterns transfer across Claude Code, Codex CLI, Cursor, Cline, Aider, Continue, and the open-source frontier. The AGENTS.md spec exists precisely to harmonize the convention across tools. JSON configs are tool-specific by definition.

Markdown is escape-free. Writing a JSON system prompt requires escaping every quote, every newline, every special character. Markdown ships as-is. The escape tax on JSON configs was a real productivity drag that nobody admitted out loud.

Five categories. The 50 files end to end.

The five categories map to the five surfaces where engineers configure AI agents in 2026. CLAUDE.md covers Claude Code project memory, the dominant pattern for the Anthropic frontier model in the developer surface. AGENTS.md covers the cross-tool standard that Codex CLI, Cline, and the open-source community converged on. .cursorrules covers Cursor IDE's directive register, where rules tend to be terser and more enforcement-flavored. ChatGPT system prompts covers the role-based custom GPT instructions that power task-specific agents independent of the IDE. Specialized configs covers the long tail: SKILL.md for Anthropic Skills, .aider.conf.yml for Aider, Continue rules for VSCode, Cline custom instructions, and the JetBrains AI Assistant surface.

Most engineers who fail to get value from AI tools do so by skipping the file-level discipline: no CLAUDE.md, generic .cursorrules copied from a thread, ChatGPT custom GPTs with one-line instructions. The thread-genre engineer skips these because they look unsexy; the engineer who gets value writes them because they are the leverage.

1. CLAUDE.md for a TypeScript monorepo (Turborepo + pnpm)

# Project: acme-platform (TypeScript monorepo)

## Stack
- pnpm workspaces, Turborepo for orchestration
- apps/web (Next.js 15), apps/api (NestJS), packages/ui, packages/db
- Postgres via Prisma, Redis for queues, OpenTelemetry traces

## Commands
- pnpm dev      # all apps in watch mode
- pnpm test     # vitest across packages
- pnpm lint     # eslint + prettier in fix mode
- pnpm db:migrate name=add_orders

## Conventions
- Shared code lives in packages/. No deep imports across apps.
- Public packages export from index.ts only.
- Database migrations require a paired rollback file.

## Never do
- Do not edit pnpm-lock.yaml by hand. Use pnpm install.
- Do not bypass Prisma to write raw SQL.
- Do not commit secrets. Use .env.local and the CI secrets manager.

2. CLAUDE.md for a Next.js 15 app router project

# Project: marketing-site (Next.js 15 app router)

## Stack
- Next.js 15 (App Router, React Server Components default)
- TypeScript strict, Tailwind v4, shadcn/ui
- Sanity CMS, Vercel hosting, Plausible analytics

## Routing
- All routes under app/. Group routes via (marketing) and (legal).
- Server Components default. "use client" only for interactivity.
- Every dynamic segment ships loading.tsx and error.tsx.

## Data fetching
- CMS data via lib/sanity/client.ts on the server.
- Cache with revalidate, not React Query, for public content.

## Never do
- Do not use the Pages Router in this repo.
- Do not put secrets in NEXT_PUBLIC_ env vars.
- Do not add a CSS framework on top of Tailwind.

3. CLAUDE.md for a Python FastAPI microservice

# Project: orders-api (FastAPI service)

## Stack
- Python 3.12, FastAPI, Pydantic v2, async SQLAlchemy 2.x
- Postgres 16 via asyncpg, Alembic migrations
- uvicorn behind nginx, pytest + httpx for tests

## Commands
- make dev                  # uvicorn with reload on :8000
- make test                 # pytest with coverage
- make migrate name=NAME    # generate Alembic migration
- make lint                 # ruff + mypy strict

## Conventions
- One router per resource in app/routers/.
- Business logic in app/services/. ORM models in app/db/models/.
- All endpoints return Pydantic response models, never ORM models directly.

## Never do
- Do not use Flask conventions. This is FastAPI.
- Do not commit .env. Copy from .env.example.
- Do not run migrations against prod from a local machine. CI only.

4. CLAUDE.md for a Go HTTP service (chi + sqlc)

# Project: payments-svc (Go HTTP service)

## Stack
- Go 1.23, chi router, sqlc for typed Postgres queries
- Postgres 16, slog structured logging, OpenTelemetry traces
- Single static binary, distroless container in prod

## Commands
- go run ./cmd/server          # local dev on :8080
- go test ./... -race          # full suite with race detector
- sqlc generate                # regenerate query code
- golangci-lint run

## Conventions
- Handlers thin. Business logic in internal/service/. Persistence in internal/repo/.
- Errors wrapped with fmt.Errorf("operation: %w", err).
- Context flows through every layer. Never stored in a struct.

## Never do
- Do not panic in request handlers. Return typed errors.
- Do not use a global DB handle outside cmd/server.
- Do not import internal/ packages from another module.

5. CLAUDE.md for a Rust CLI tool (clap + tokio)

# Project: dbctl (Rust CLI for database operations)

## Stack
- Rust 1.80, clap v4 for argument parsing, tokio for async
- sqlx for compile-time checked Postgres queries
- anyhow for application errors, thiserror for library errors

## Commands
- cargo run --bin dbctl -- migrate
- cargo test
- cargo clippy --all-targets -- -D warnings
- cargo fmt --check

## Conventions
- Commands in src/cmd/. Each command is a module with a run() fn.
- All pub fns return Result. Document errors in rustdoc.
- Async via tokio::main on the entry point. No blocking in async fns.

## Never do
- Do not unwrap in non-test code. Use anyhow context.
- Do not add a feature flag without a default.
- Do not add a dependency without checking license and maintenance.

6. CLAUDE.md for a React component library (Storybook + Vitest)

# Project: acme-ui (React component library)

## Stack
- React 19, TypeScript strict, Vite bundler
- Storybook 8 for development and visual review
- Vitest + Testing Library for unit tests, Playwright for visual regression

## Commands
- pnpm storybook              # dev server on :6006
- pnpm test                   # vitest
- pnpm test:visual            # playwright visual regression
- pnpm build:lib              # tsup library build

## Conventions
- One component per directory: index.ts, Component.tsx, Component.stories.tsx, Component.test.tsx.
- Props interfaces named ComponentProps and exported.
- All components support a className prop and forward refs where applicable.

## Never do
- Do not add a runtime dependency without library-size review.
- Do not import from src/internal in published components.
- Do not ship a component without a Storybook story.

7. CLAUDE.md for a Django REST framework backend

# Project: portal-api (Django + DRF)

## Stack
- Python 3.12, Django 5.x, Django REST Framework
- Postgres 16, Redis for cache and Celery broker
- pytest-django for tests, factory_boy for fixtures

## Commands
- python manage.py runserver     # dev on :8000
- python manage.py migrate
- pytest                          # full test suite
- python manage.py makemigrations APP_NAME

## Conventions
- One app per bounded context (orders, billing, accounts).
- Serializers in serializers.py per app. Views are ViewSets in views.py.
- All endpoints permission-checked. Use DjangoModelPermissions or custom classes.

## Never do
- Do not use AllowAny in production endpoints without explicit review.
- Do not write business logic in views. Use service modules.
- Do not skip migrations to fix data drift. Write a data migration.

8. CLAUDE.md for a Terraform infrastructure module

# Project: infra-aws-prod (Terraform)

## Stack
- Terraform 1.9, AWS provider 5.x
- Remote state in S3 with DynamoDB locking
- Atlantis for PR-driven plan and apply

## Commands
- terraform init -backend-config=backend/prod.tfbackend
- terraform plan -var-file=prod.tfvars
- terraform fmt -recursive
- tflint --recursive

## Conventions
- One module per resource group in modules/.
- Environments in env/prod, env/staging, env/dev. Shared modules under modules/.
- All resources tagged with Owner, Environment, CostCenter.

## Never do
- Do not apply directly to prod from a local machine. Atlantis only.
- Do not commit .tfstate or .terraform.lock.hcl conflicts unresolved.
- Do not add a new provider without security review.

9. CLAUDE.md for a Kubernetes Helm chart

# Project: charts/api (Helm chart for the api service)

## Stack
- Helm 3, Kubernetes 1.30+
- Argo CD for GitOps deployment
- Prometheus ServiceMonitor for metrics, Loki for logs

## Commands
- helm lint .
- helm template . -f values-prod.yaml
- helm upgrade --install api . -f values-prod.yaml --dry-run
- ct lint --chart-dirs charts/

## Conventions
- All values documented in values.yaml with comments.
- Probes (liveness, readiness, startup) defined for every container.
- Resource requests and limits required. No best-effort pods in prod.

## Never do
- Do not hardcode image tags in templates. Use .Values.image.tag.
- Do not set imagePullPolicy: Always in prod.
- Do not ship a chart without a values-prod.yaml override file in the repo.

10. CLAUDE.md for an ML training pipeline (PyTorch Lightning)

# Project: ranker-training (PyTorch Lightning)

## Stack
- Python 3.11, PyTorch 2.4, PyTorch Lightning 2.x
- Weights and Biases for experiment tracking, DVC for data versioning
- Hydra for config management, Ray for distributed training

## Commands
- python train.py +experiment=ranker_v3
- python eval.py checkpoint_path=runs/ranker_v3/best.ckpt
- dvc pull data/
- pytest tests/                    # data and model contract tests

## Conventions
- All experiments under conf/experiment/. Override via Hydra.
- Data loaders in src/data/. Models in src/models/. Training loops minimal in train.py.
- Every commit that changes the model architecture bumps MODEL_VERSION in src/version.py.

## Never do
- Do not hardcode hyperparameters in train.py. Use the Hydra config.
- Do not commit checkpoints. Use the model registry.
- Do not skip a seed in a comparison run. Reproducibility is the discipline.

11. AGENTS.md for a Node.js Express API (Postgres + Knex)

# AGENTS.md

## Project
Node.js 22, Express 5, Postgres via Knex query builder. REST API for the storefront.

## Setup
- npm ci
- npm run db:migrate
- npm run dev          # nodemon on :3000

## Tests
- npm test             # jest, must pass before commit
- npm run test:int     # integration tests against test db

## Rules for the agent
- Use Knex query builder for all DB access. No raw SQL strings.
- All async work returns promises explicitly. No callback-style handlers.
- New endpoints require a corresponding test file in tests/routes/.
- Logging via pino. Never console.log in committed code.

## Never modify
- knex_migrations and knex_migrations_lock tables.
- The package-lock.json by hand.
- Files in dist/ or coverage/.

12. AGENTS.md for a Ruby on Rails 7 monolith (Hotwire)

# AGENTS.md

## Project
Ruby 3.3, Rails 7.1, Postgres, Sidekiq, Hotwire (Turbo + Stimulus) for the frontend.

## Setup
- bundle install
- bin/rails db:setup
- bin/dev               # foreman runs web + worker + asset watch

## Tests
- bin/rails test
- bin/rails test:system    # capybara system tests against real browser

## Rules
- Use Rails idioms. ActiveRecord scopes, not raw SQL.
- Controller actions stay thin. Push logic into models or service objects in app/services/.
- New views use Turbo Frames where partial updates apply. No ad-hoc fetch calls.
- Strong parameters required on every create and update action.

## Never modify
- db/schema.rb directly. Use migrations.
- Gemfile.lock without bundle update.
- config/credentials.yml.enc without re-encrypting via rails credentials:edit.

13. AGENTS.md for a Spring Boot Java service (JPA + Flyway)

# AGENTS.md

## Project
Java 21, Spring Boot 3.3, JPA via Hibernate, Flyway for migrations, Postgres.

## Setup
- ./mvnw clean install
- ./mvnw spring-boot:run        # local on :8080

## Tests
- ./mvnw test
- ./mvnw verify                 # includes integration tests with Testcontainers

## Rules
- Layered architecture: Controller -> Service -> Repository.
- DTOs separate from JPA entities. MapStruct generates mappers.
- All public service methods annotated @Transactional with explicit propagation.
- Validation via jakarta.validation annotations on request DTOs.

## Never modify
- Flyway migration files that have run in any environment. Add a new V__ file.
- src/main/resources/application-prod.yml without security review.
- pom.xml dependency versions without checking CVE database.

14. AGENTS.md for a React Native mobile app (Expo)

# AGENTS.md

## Project
React Native via Expo SDK 51, TypeScript strict, Zustand for state, TanStack Query for data.

## Setup
- pnpm install
- pnpm expo start              # Metro on default port
- pnpm expo run:ios            # iOS simulator (mac only)
- pnpm expo run:android        # Android emulator

## Tests
- pnpm test                    # jest + react-native-testing-library
- pnpm test:detox              # E2E on simulator

## Rules
- Screens in app/. Components in components/. Hooks in hooks/.
- Navigation via expo-router file-based routes.
- Platform-specific code lives in .ios.tsx and .android.tsx files when divergence is required.
- API calls go through hooks in hooks/api/ that wrap TanStack Query.

## Never modify
- ios/ and android/ native folders unless adding a config plugin.
- The Expo SDK version without testing across iOS, Android, and Web targets.
- App.tsx without confirming the navigation tree still mounts.

15. AGENTS.md for a Flutter mobile app (Riverpod)

# AGENTS.md

## Project
Flutter 3.24, Dart 3.5, Riverpod 2 for state, GoRouter for routing, Dio for HTTP.

## Setup
- flutter pub get
- flutter run                  # current device
- flutter run -d chrome        # web target

## Tests
- flutter test
- flutter test integration_test/
- dart analyze

## Rules
- Feature-first folder structure: lib/features//{data,domain,presentation}.
- State managed via Riverpod providers. No setState in screens.
- Models generated via freezed and json_serializable.
- All async work in providers, not in widget build methods.

## Never modify
- pubspec.lock by hand. Use flutter pub get.
- Generated files (*.freezed.dart, *.g.dart). Re-run build_runner.
- ios/Podfile or android/build.gradle without confirming build still passes.

16. AGENTS.md for a GraphQL API (Apollo Server + Postgres)

# AGENTS.md

## Project
TypeScript, Apollo Server 4, schema-first GraphQL, Postgres via Prisma, DataLoader for N+1 batching.

## Setup
- pnpm install
- pnpm db:migrate
- pnpm dev               # tsx watch on :4000

## Tests
- pnpm test              # vitest unit tests
- pnpm test:e2e          # supertest against the GraphQL endpoint

## Rules
- Schema in src/schema/*.graphql. Resolvers in src/resolvers/.
- One DataLoader per join. Define in src/loaders/, register in context.
- All mutations require an authenticated context. Use directives to enforce.
- Error codes use ApolloError subclasses, never raw throws.

## Never modify
- prisma/migrations/ files that have run in any environment.
- The schema.graphql files without regenerating types via pnpm codegen.
- src/context.ts without auth review.

17. AGENTS.md for a SvelteKit app (Drizzle ORM)

# AGENTS.md

## Project
SvelteKit 2, Svelte 5 with runes, Drizzle ORM, Postgres, Lucia for auth.

## Setup
- pnpm install
- pnpm db:push           # drizzle-kit push for dev
- pnpm dev               # vite dev server on :5173

## Tests
- pnpm test              # vitest
- pnpm test:e2e          # playwright

## Rules
- Route files in src/routes/. +page.svelte for components, +page.server.ts for SSR loaders.
- Database access only in .server.ts files. Never expose the DB to the client.
- Forms use SvelteKit form actions, not client-side fetch where SSR is possible.
- Use runes ($state, $derived, $effect). Avoid legacy stores in new code.

## Never modify
- drizzle/ migrations after they have run.
- src/lib/server/db.ts to expose connection details.
- svelte.config.js to disable CSRF protection.

18. AGENTS.md for a WebSocket real-time service (Socket.IO)

# AGENTS.md

## Project
Node.js 22, Socket.IO 4, Redis adapter for horizontal scaling, JWT for socket auth.

## Setup
- pnpm install
- pnpm dev                # nodemon on :3001
- docker compose up redis  # required for adapter

## Tests
- pnpm test               # vitest + socket.io-client

## Rules
- Namespaces per feature (chat, presence, notifications).
- Authenticate on connection via JWT in handshake auth. Disconnect on invalid token.
- All emits typed via shared TypeScript interfaces in packages/protocol.
- Use rooms for group messaging. Never broadcast to all sockets.

## Never modify
- The Redis adapter config without testing horizontal scale.
- JWT secrets or expiration without security review.
- The connection limit settings in production config.

19. AGENTS.md for a Stripe payments integration project

# AGENTS.md

## Project
Node.js + TypeScript, Stripe API integration, Postgres for idempotency records, webhook receiver.

## Setup
- pnpm install
- pnpm db:migrate
- stripe listen --forward-to localhost:3000/webhooks/stripe   # dev webhook proxy

## Tests
- pnpm test              # vitest with stripe-mock
- pnpm test:webhooks     # signature verification tests

## Rules
- All Stripe calls go through src/lib/stripe.ts. Single client, single config source.
- Every mutation that talks to Stripe has an idempotency_key stored in DB before the API call.
- Webhook handlers must verify the signature and return 200 on duplicate event IDs.
- Amounts always stored as integer cents. Never floats.

## Never modify
- Webhook signing secrets without rotating them in Stripe dashboard.
- The idempotency table schema without a backfill plan.
- The Stripe API version without testing the full webhook surface.

20. AGENTS.md for an open source npm library

# AGENTS.md

## Project
TypeScript library published to npm. Tsup for build, Changesets for versioning, GitHub Actions for CI and release.

## Setup
- pnpm install
- pnpm build
- pnpm dev               # tsup watch mode

## Tests
- pnpm test              # vitest
- pnpm test:types        # tsc --noEmit
- pnpm lint              # eslint + prettier

## Rules
- Public API exported from src/index.ts only.
- Every public function has a JSDoc comment with @example.
- Breaking changes require a major version bump via changeset.
- No runtime dependencies without library-size justification.

## Never modify
- The exports field in package.json without testing in CJS and ESM consumers.
- CHANGELOG.md by hand. Generated by Changesets.
- The npm tag during release. Use changeset publish.

Most AI tooling advice circulating on LinkedIn is content marketing. The work that actually compounds is the file you commit to the repo.PromptLeadz .md Agent Pack

21. .cursorrules for TypeScript strict mode discipline

# TypeScript strict mode rules

The project uses TypeScript with strict: true. Enforce these rules.

- Never use `any`. Use `unknown` with a type guard, or define the proper type.
- Never use non-null assertions (`!`). Narrow with a guard or refactor.
- Prefer `type` for unions and primitives, `interface` for object shapes that may be extended.
- Function parameters and return types are always explicit on exported functions.
- Use `readonly` on arrays and object properties that should not be mutated.
- Discriminated unions use a `kind` field, not `type` (avoid keyword clash).

When suggesting code, run the type-check in your head first. Output that fails strict mode is a bug.

22. .cursorrules for React hooks and component conventions

# React conventions

- Functional components only. No class components in new code.
- Hooks at the top of the function, before any conditional logic.
- Custom hooks named `use*`. They return objects when there are multiple values, arrays only for tuple semantics (like useState).
- Effects must have a cleanup if they subscribe to anything.
- Props use destructuring with explicit types. Default values via destructuring defaults, not defaultProps.
- Memoization (useMemo, useCallback) only when profiler shows a measurable improvement. No speculative memoization.
- No `useEffect` for derived state. Compute it inline.

When suggesting a hook, name the dependency array completely. Missing deps is a real bug, not a style preference.

23. .cursorrules for Python type hints and Ruff enforcement

# Python conventions (Python 3.12+)

- All public functions have type hints. Use the modern syntax (list[int], dict[str, str], X | None).
- Ruff is the formatter and linter. Configuration in pyproject.toml. Never disable rules inline without a comment explaining why.
- mypy strict mode is enabled. Output that fails mypy --strict is a bug.
- Use dataclasses or Pydantic models for structured data. No bare dicts for typed records.
- Async functions only where async I/O happens. Don't wrap sync code in async unnecessarily.
- Imports sorted by isort (handled by Ruff). Use absolute imports from the project root.

When suggesting code, prefer composition over inheritance. Inheritance is for is-a relationships only.

24. .cursorrules for SQL migration safety

# SQL migration rules

The project uses migrations to evolve the database schema. Migrations are run automatically in CI.

- Every migration must be reversible. Down migrations are required.
- ALTER TABLE on large tables (>1M rows) must use online migration patterns (pg_repack, batched updates, dual-write + backfill).
- NOT NULL columns added to existing tables must be added without a default first, then backfilled, then have NOT NULL applied. Three migrations.
- Index creation on large tables uses CONCURRENTLY. Migrations using CONCURRENTLY cannot run inside a transaction.
- DROP COLUMN is rare. Default to renaming and deprecating before drop.
- Foreign keys require explicit ON DELETE behavior named. No default behavior.

When suggesting a migration, name the operational risk. Migrations that lock the table for more than 5 seconds are unacceptable in production.

25. .cursorrules for test-first development

# Test-first conventions

- New behavior requires a failing test before the implementation. The agent writes the test first.
- Test names describe the behavior, not the implementation. Format: `it("returns 404 when the user is not found")`, not `it("calls findUser")`.
- One assertion per test where possible. Multiple assertions only when they verify the same behavior.
- Test data uses factories (factory-bot, factory_boy, fishery) or fixtures, never inline ad-hoc objects.
- Integration tests hit real databases (Testcontainers or local Docker), never mocked DBs.
- Mocks only for external services we do not control (Stripe, SendGrid, etc.). Internal code is integration-tested.

When suggesting code, suggest the test first. If the test cannot be written, the behavior is not well-defined.

26. .cursorrules for security review of auth code

# Security rules for authentication and authorization code

- Passwords hashed with argon2id or bcrypt with cost factor 12+. Never SHA, never MD5.
- Session tokens are 256-bit random values, stored hashed in the DB. Never stored plaintext.
- All session cookies HttpOnly, Secure, SameSite=Lax (or Strict for non-OAuth flows).
- Authorization checks happen at the controller or middleware layer, not in views or templates.
- Permission checks use deny-by-default. Explicit allow for each endpoint, not implicit through routing.
- CSRF tokens required on every state-changing request. Verify on the server, not just by setting a header.
- Rate limiting on login and password reset endpoints. Track by IP and by account.

When suggesting auth code, name the threat model. Code without a stated threat model is a vulnerability waiting to ship.

27. .cursorrules for API endpoint conventions

# REST API conventions

- Resource URLs are plural nouns (/users, /orders), not verbs.
- Use HTTP status codes correctly: 200 success with body, 201 created with Location header, 204 no content, 400 client error, 401 unauthenticated, 403 unauthorized, 404 not found, 409 conflict, 422 validation, 429 rate-limited, 500 server error.
- Request and response bodies use snake_case JSON keys. Convert at the serialization boundary.
- Errors return a consistent shape: { error: { code, message, details? } }.
- Pagination uses cursor-based, not offset. Cursor opaque, base64 of (sort_field, id).
- Versioning via Accept-Version header, not URL prefix.
- All list endpoints require a max limit (typically 100). Reject requests with limit beyond max.

When suggesting an endpoint, name the contract first. Schema before code.

28. .cursorrules for Git commit message format

# Conventional Commits enforcement

All commits follow the Conventional Commits spec. The agent generates commit messages in this format.

Format: type(scope): description

Types used in this repo:
- feat: new user-facing functionality
- fix: bug fix in committed behavior
- perf: performance improvement with no behavior change
- refactor: code change with no behavior change
- test: adding or fixing tests
- docs: documentation only
- chore: tooling, deps, build (no app code change)
- ci: CI configuration only

Rules:
- Description starts with imperative mood ("add", not "adds" or "added").
- Description under 72 characters.
- Breaking changes use "!" after the scope: feat(api)!: rename endpoint
- Multi-line commits use a blank line then a body explaining the why.
- Reference issues in the footer: Closes #123, Refs #456.

29. .cursorrules for logging and observability

# Logging and observability

- Structured logging only. JSON output in production, human-readable in dev. Use pino, slog, structlog, or the language-native equivalent.
- Every log line includes: timestamp, level, service, request_id (if applicable), and event-specific fields.
- Log levels: error for failures requiring action, warn for unexpected but recoverable, info for state changes worth alerting on volume, debug for development.
- Never log secrets, tokens, passwords, full PII. Hash or redact at the logging layer.
- Use OpenTelemetry spans for cross-service tracing. Span names follow the convention `service.operation` (e.g., `orders.create`).
- Metrics: request count, request duration histogram, error rate. Exposed via Prometheus or OpenTelemetry.

When suggesting code, add a log line at the decision point or error path, not at the entry of every function. Noisy logs hide real signal.

30. .cursorrules for performance review of hot paths

# Performance rules for hot paths

- Hot path is defined as code in the critical request path of a user-facing endpoint or a job processed at scale (>1000/min).
- Hot paths use no allocations in tight loops where possible. Reuse buffers.
- Database queries in hot paths are reviewed for N+1 patterns. Use DataLoader, eager loading, or batch queries.
- No synchronous I/O in async hot paths. Block-detector should be enabled in dev.
- Caches added with explicit TTL and invalidation strategy. No "forever caches" that grow unbounded.
- Profile before optimizing. Speculative optimization is a bug.
- Latency budget per endpoint documented in a comment at the handler. Optimizations below the budget are out of scope.

When suggesting a hot path change, name the metric and the budget. Performance work without a number is theater.

31. Code Reviewer GPT (correctness, security, design)

# Code Reviewer

You review code diffs for correctness, security, and design. You are not the author. Your job is to find issues the author missed.

## Review order
1. Correctness: does the code do what the PR description says it does. Name the specific line if it does not.
2. Security: are there auth, injection, secret-handling, or data-exposure risks. Quote the line.
3. Design: does the change fit the existing architecture or does it create a new pattern. Name the existing pattern it should have used.
4. Tests: are the tests testing the behavior or the implementation. Are edge cases covered.
5. Style: only if it impacts readability. Skip nit-style comments.

## Output format
For each issue: severity (blocker, major, nit), the file:line, the issue stated factually, the suggested fix.

## Refuse to
- Approve a PR without naming what is good and what is risky.
- Say "LGTM" without specific evidence.
- Comment on style if no real issue exists.

32. PR Summarizer for changelog entries

# PR Summarizer

You summarize a PR diff into a one-line changelog entry and a short release note.

## Input
A git diff, the PR title, and the PR description.

## Output
- One-line entry in Conventional Commits format: type(scope): description.
- Short release note (under 200 chars) describing user-visible impact.
- Tag the change as breaking, deprecation, or backward-compatible.

## Rules
- Lead with the user impact, not the implementation.
- Skip refactors that have no user-visible impact (still output an entry but flag as internal).
- If the diff includes multiple unrelated changes, output one entry per change, not one merged entry.
- Never invent a feature that the diff does not actually implement.

33. Bug Triage agent for issue intake

# Bug Triage

You triage incoming bug reports. Decide severity, area, and the first investigation step.

## Input
A bug report (user-submitted, often informal).

## Output
- Severity: P0 (down, data loss), P1 (broken feature), P2 (degraded experience), P3 (nit).
- Area: the code area or service likely involved.
- Reproducibility: steps to reproduce, or what is missing if the report is incomplete.
- First investigation step: the specific log, metric, or query to check.
- Owning team: the team that should investigate.

## Refuse to
- Triage without a reproduction or a clear symptom. Ask for what is missing.
- Default to P1 when the severity is ambiguous. Push back on the reporter.
- Assign an owner without evidence. Suggest, do not assign.

34. Security Auditor for auth flows

# Security Auditor

You audit authentication and authorization code for security issues.

## Scope
- Password handling, session management, token issuance and verification.
- Authorization checks (route guards, permission checks).
- CSRF, CORS, cookie configuration.
- Rate limiting on auth endpoints.

## Output
For each finding:
- Severity (critical, high, medium, low).
- The vulnerability named (e.g., timing-attack on password comparison, missing CSRF token, weak session ID generation).
- The specific code that has the issue.
- The fix (specific, not generic).
- The threat model context (who can exploit, what they gain).

## Refuse to
- Approve auth code without an explicit threat model.
- Sign off on "security through obscurity" patterns (custom crypto, secret URLs, etc).
- Say "looks fine" without naming what you checked.

35. Database Query Optimizer

# Database Query Optimizer

You review SQL queries and suggest optimizations.

## Input
A SQL query, the schema (CREATE TABLE statements), and ideally the EXPLAIN ANALYZE output.

## Output
- The query plan summary (what indexes are used, what scans happen).
- The performance bottleneck named (full table scan, missing index, suboptimal join order, etc.).
- The optimization (add index, rewrite query, denormalize, materialize a view) with the specific DDL or rewritten query.
- The expected improvement (rough order of magnitude).
- The trade-off (write performance, storage, complexity).

## Refuse to
- Suggest an index without naming the queries it helps.
- Recommend denormalization without naming the read-vs-write trade-off.
- Approve a query that returns more rows than needed (missing WHERE or LIMIT).

36. API Documentation Writer

# API Documentation Writer

You write API reference documentation from a route handler and its types.

## Input
A route handler (any language), the request and response types, and the route configuration (method, path, auth requirements).

## Output
- Endpoint description (one paragraph, user-facing).
- Method, path, auth requirements.
- Request schema with each field documented (type, required/optional, description, example).
- Response schema with each field documented.
- Error codes returned with conditions.
- A curl example that works.
- A code example in TypeScript and Python (using a typed client if applicable).

## Refuse to
- Document a behavior the handler does not implement.
- Skip the error cases. Every documented endpoint lists its errors.
- Use vague descriptions ("returns user data"). Name the specific fields.

37. Unit Test Writer with edge cases

# Unit Test Writer

You write unit tests for a given function or class.

## Approach
1. Identify the inputs (parameters, configuration, external state).
2. Identify the outputs (return value, side effects, exceptions).
3. List the edge cases: empty input, null, max value, min value, off-by-one, concurrent access, malformed input.
4. List the failure cases: external dependency failures, invalid state transitions.
5. Write the test for each case.

## Output
- Tests in the test framework the project already uses.
- One assertion per test where possible.
- Test names describe the behavior, not the implementation.
- Use the project's fixture/factory conventions.
- Include negative tests (expected failures).

## Refuse to
- Write tests that only verify happy path. Always cover edge and failure cases.
- Write tests that depend on test execution order.
- Use real external services. Mock at the boundary.

38. Refactoring Assistant with scope limits

# Refactoring Assistant

You refactor code without changing behavior.

## Rules
- The refactor preserves behavior. The test suite passes before and after with no changes.
- Scope is stated upfront. You refactor exactly the named scope, not adjacent code.
- Big refactors are split into reviewable chunks. Each chunk passes tests independently.
- You do not mix refactor and feature changes in the same diff.
- You name the trade-offs of the refactor (readability vs performance, abstraction cost, etc.).

## Output
- The refactored code.
- A summary: what was renamed, what was extracted, what was inlined.
- The risks: places where the refactor might have broken something subtle.
- The test gaps: cases not covered by existing tests that the refactor relies on.

## Refuse to
- Refactor code without a passing test suite. Write tests first.
- Expand scope mid-refactor ("while I was in there..."). Stop and propose a follow-up.
- Change a public API while refactoring. That is a separate change.

39. Database Migration Planner

# Database Migration Planner

You plan a database schema change as a sequence of reviewable migrations.

## Input
The current schema, the target schema, the production size of affected tables, and any constraints (zero-downtime requirement, scheduled window, etc.).

## Output
- The sequence of migrations (numbered, each one runnable independently).
- The data backfill plan if a column is added with NOT NULL.
- The rollback plan for each migration.
- The expected lock duration for each migration.
- The deployment sequence (when each migration runs relative to the code change).
- The verification steps (queries to run before, during, after).

## Refuse to
- Plan a migration without naming the table size and lock implications.
- Combine schema change and data change in one migration on a large table.
- Suggest a destructive migration (DROP COLUMN, DROP TABLE) without a deprecation window.

40. Commit Message Generator (Conventional Commits)

# Commit Message Generator

You generate commit messages from a staged diff.

## Output format
type(scope): subject

body (optional, wrapped at 72 chars)

footer (optional: Closes #N, BREAKING CHANGE: ...)

## Rules
- Subject under 72 chars, imperative mood ("add", "fix", not "added", "adds").
- Type is one of: feat, fix, perf, refactor, test, docs, chore, ci, build, style.
- Scope is the area of the codebase (auth, api, db, ui, etc.). Optional but encouraged.
- Body explains the why and the what, not the how (code shows the how).
- Breaking changes use "!" after scope and a BREAKING CHANGE footer.
- Reference issues in the footer when the change closes or relates to an issue.

## Refuse to
- Generate a message that combines multiple unrelated changes. Ask to split the commit.
- Use vague subjects ("update code", "fix stuff"). Always name the specific change.
- Skip the body when the change is non-obvious.

A good CLAUDE.md gets reviewed on the PR. A good .cursorrules catches the bug the team kept shipping. A good custom GPT produces a code review you can defend. The job is files you commit. The threads about the job are not.PromptLeadz .md Agent Pack, Section 5

41. SKILL.md for an Anthropic Skill (finance close skill)

---
name: finance-close
description: Use this skill when the user is working on monthly financial close, reconciliations, variance analysis, or close acceleration. Triggers include: GL review, journal entries, intercompany, accruals, close calendar, flux analysis.
---

# Finance Close Skill

## What this skill does
Produces close-grade artifacts: variance analysis memos, journal entry packages, intercompany reconciliations, close calendars, flux explanations. Output is calibrated for audit review and finance leadership.

## When to invoke
- User asks about closing the books for a period.
- User asks for a variance memo, flux analysis, or accrual review.
- User mentions specific finance close artifacts (GL, journal entry, accrual, intercompany).

## Output discipline
- Numbers always sourced. Cite the system of record (GL, sub-ledger, schedule).
- Variance memos include the cause column. Never variance without cause.
- Journal entries balanced and tied to a supporting calculation.

## Never
- Invent numbers. If the data is not given, ask.
- Mix close and forecast work. Close is historical only.

42. SKILL.md for a customer escalation skill

---
name: customer-escalation
description: Use this skill when handling customer escalations including renewal at-risk, churn signals, executive sponsor disengagement, performance disputes, and save play sequencing.
---

# Customer Escalation Skill

## What this skill does
Produces save plans, escalation memos, and structured response artifacts for at-risk accounts. Output is calibrated for CS leadership review and executive sign-off.

## When to invoke
- User describes an at-risk renewal, churn signal, or escalation.
- User asks for a save plan or executive response.
- User mentions specific escalation triggers (sponsor change, performance dispute, vendor consolidation).

## Output discipline
- Every save plan names the dollar value at risk.
- Action items have a named owner and a date.
- Kill criteria stated explicitly (when do we stop trying to save).

## Never
- Promise commercial terms without naming the approver.
- Use "trusted advisor" framing. Use specific decisions and actions.
- Skip the executive sponsor question. Always name the path back to the sponsor.

43. .aider.conf.yml for a Python data project

# .aider.conf.yml

model: claude-opus-4-7
edit-format: udiff
auto-commits: false
dirty-commits: false

read:
  - README.md
  - CLAUDE.md
  - pyproject.toml

test-cmd: pytest -x
lint-cmd:
  python: ruff check --fix . && ruff format .

attribute-author: false
attribute-committer: false

# Repository conventions
# - Code in src/. Tests mirror structure in tests/.
# - Type hints required on public functions.
# - All notebooks in notebooks/ are exploratory. Production code is .py files.
# - Data files are not committed. Pull via dvc.

# Aider, when modifying code, follow these rules:
# - Run the test command after edits.
# - If tests fail, fix the test or the code, do not suppress.
# - Do not commit. Show the diff and stop.

44. .aider.conf.yml for a Rails monolith

# .aider.conf.yml

model: claude-opus-4-7
edit-format: diff
auto-commits: false

read:
  - README.md
  - CLAUDE.md
  - Gemfile
  - config/routes.rb
  - config/database.yml.example

test-cmd: bin/rails test
lint-cmd:
  ruby: bundle exec rubocop -a

# Repository conventions
# - Rails 7.1, Ruby 3.3, Postgres. Hotwire (Turbo + Stimulus) for the frontend.
# - Controller actions stay thin. Business logic in models or app/services/.
# - Strong parameters on every create/update.
# - System tests cover happy paths. Model tests cover edge cases.

# Aider rules:
# - Use Rails idioms. ActiveRecord scopes, not raw SQL.
# - When adding a new endpoint, add the controller, route, view, and test in one diff.
# - Never edit db/schema.rb directly. Use a migration.

45. Continue rules file for VSCode

# .continue/config.yaml rules

name: TypeScript Backend Service

rules:
  - When suggesting code in this repo, use the existing patterns.
  - All async functions must explicitly return Promise.
  - Use the Logger from src/lib/logger.ts. Never console.log.
  - Errors thrown from the API layer extend ApiError from src/errors.ts.
  - When adding a new endpoint, add the route handler, the request/response types in src/types/, and the integration test in tests/integration/.
  - When suggesting a database query, use the existing Knex query builder pattern. Never raw SQL strings.
  - When refactoring, do not change behavior. Tests should pass before and after.
  - Suggest the minimum change that solves the problem. No speculative abstractions.

refuse:
  - Adding a new dependency without justification.
  - Modifying files in node_modules/, dist/, or coverage/.
  - Disabling lint rules inline without a comment explaining why.

46. Cline custom instructions file

# Cline Custom Instructions

## About this project
Full-stack TypeScript app: Next.js 15 frontend, NestJS backend, Postgres via Prisma. Deployed on Fly.io.

## How you should work
- Read the existing code before suggesting changes. Use the file browser tool first.
- When implementing a new feature, propose the file structure before writing code.
- Run the test suite (pnpm test) after every meaningful change.
- Use the Prisma client for database access, never raw SQL.
- For new API endpoints, use the existing NestJS module pattern.
- For new UI components, use the existing shadcn/ui components from src/components/ui.

## What to never do
- Do not commit code. The user reviews and commits.
- Do not modify .env files. Suggest the change and let the user apply.
- Do not install new packages without asking. Suggest the package and reason.
- Do not refactor code outside the scope of the current task.

## Communication
- When a task is ambiguous, ask before implementing.
- When you encounter an unexpected pattern, ask before changing it.
- Summarize what you did at the end of each task.

47. Cody context file for a TypeScript project

# .sourcegraph/cody.json (project context)

{
  "context": {
    "description": "TypeScript monorepo for the acme-platform product. Five apps and three shared packages. Used by the backend team for API services and the frontend team for the web app.",
    "primaryLanguages": ["TypeScript", "SQL"],
    "frameworks": ["NestJS", "Next.js", "Prisma", "Vitest"],
    "conventions": [
      "All shared code in packages/. Apps import via workspace deps, not relative paths.",
      "Database access via Prisma. No raw SQL outside of migrations.",
      "Tests live next to source: foo.ts and foo.test.ts in the same directory.",
      "Public APIs documented with JSDoc comments. Private functions need not be."
    ],
    "avoid": [
      "Suggesting code that uses CommonJS require. ESM only.",
      "Suggesting changes that span multiple apps in one PR.",
      "Recommending libraries already replaced (e.g., moment.js is replaced by date-fns)."
    ]
  }
}

48. Sourcegraph Cody agent config

# cody.agents.yaml

agents:
  - id: pr-reviewer
    description: Reviews PRs for the acme-platform repo. Comments on correctness, security, and design.
    triggers:
      - on: pull_request.opened
      - on: pull_request.synchronize
    context:
      - file: CLAUDE.md
      - file: .sourcegraph/cody.json
    rules:
      - Focus comments on blockers and majors. Skip nits.
      - Cite the file:line in every comment.
      - For each comment, state the issue and the suggested fix.
      - Do not approve. Leave approval to humans.

  - id: changelog-writer
    description: Generates changelog entries from merged PRs.
    triggers:
      - on: pull_request.merged
    output:
      file: CHANGELOG.md
      format: keep-a-changelog

49. AWS Q Developer config (.aws-q/rules.md)

# AWS Q Developer Rules

Project: acme-cloud-infra (Terraform for AWS).

## Defaults
- Region: us-east-1 (primary), us-west-2 (DR).
- All resources tagged: Owner, Environment, CostCenter, ManagedBy=terraform.
- VPC CIDRs from the address-plan in docs/network.md. Do not invent new CIDRs.

## Resource rules
- S3 buckets are private by default. Public access requires explicit review.
- IAM policies follow least privilege. No wildcard actions on production resources.
- RDS instances are Multi-AZ in prod. Backups retained 30 days minimum.
- Security Groups: inbound rules restricted to specific source SGs or CIDRs, never 0.0.0.0/0 except for ALBs.
- Lambda functions: explicit memory and timeout, no defaults.

## Q rules
- When suggesting infra, output Terraform HCL only, not CloudFormation.
- When suggesting a new service, name the cost order of magnitude.
- Never suggest disabling encryption at rest or in transit.

50. JetBrains AI Assistant project config

# .idea/ai-assistant.md

Project: acme-backend (IntelliJ IDEA Ultimate, Kotlin + Spring Boot).

## Language and framework conventions
- Kotlin 2.0, Spring Boot 3.3, Gradle (Kotlin DSL).
- JPA via Hibernate with Kotlin null-safety extensions.
- Coroutines for async. Avoid CompletableFuture in new code.

## Patterns to follow
- Controller -> Service -> Repository layers.
- DTOs separate from JPA entities. Mapped via MapStruct.
- All public service methods have explicit @Transactional with readOnly = true for queries.
- Tests use JUnit 5, MockK for mocks, Testcontainers for integration.

## When suggesting code
- Use data classes for DTOs.
- Prefer val over var.
- Use sealed classes for finite type hierarchies.
- Idiomatic Kotlin: scope functions (let, also, apply, run, with) where they clarify intent.

## When refactoring
- Run the test suite before claiming completion.
- Do not change public method signatures without a deprecation cycle.
- Do not modify build.gradle.kts dependency versions without checking compatibility.

How the files fit a real engineer week and quarter

On a new project: the first commit after the repo init is the CLAUDE.md or AGENTS.md. The file gets reviewed on the first PR alongside the initial code structure. The .cursorrules file follows if Cursor is in the toolchain.

Weekly: the CLAUDE.md gets edited when conventions evolve. Treat it as a living document. Most repos see 5 to 15 edits in the first quarter, then stabilize.

Per PR: if the change introduces a new pattern (new auth flow, new caching layer, new service boundary), the PR adds a line to the CLAUDE.md. If the change deprecates a pattern, the PR removes the line.

Monthly: review the custom GPT system prompts against the actual outputs they produce. If a GPT keeps producing bad code reviews, the system prompt is wrong, not the model.

Quarterly: re-read every config file in the repo. Files that have not been edited in 90 days and the team has not referenced are usually stale. Update or delete.

Annually: when a major model version ships, re-test the system prompts against the new model. The prompts that worked on Sonnet 4 may need refinement for Opus 4.7 or the next frontier model.

Five mistakes that wreck .md AI agent files

1. The universal mega-prompt. One CLAUDE.md or AGENTS.md that tries to cover every project the engineer might touch. The result is generic guidance that fits nothing. Each project gets its own file tuned to that project's stack and conventions.

2. The forever file that never gets edited. CLAUDE.md gets committed in the first week and never touched again. Six months later it describes a codebase that no longer exists. Treat the file as code. It belongs in the PR review checklist when conventions change.

3. The implicit conventions document. A CLAUDE.md that says "follow our conventions" without naming them. The agent has no idea what the conventions are. Name the specific patterns: "use Knex query builder, not raw SQL", not "follow our DB access conventions".

4. The missing never-do section. The file documents what to do but not what to never do. The model is most useful when it knows the boundaries: never edit lockfiles, never commit secrets, never bypass migrations. The negative space is where the value is.

5. The screenshot-and-share pattern. The .md file that gets shared as a screenshot in a Slack channel or a thread. Files belong in version control, not in screenshots. Once a config leaves the repo, it stops being maintained and starts being a stale snapshot.

Sources and further reading

The pack draws on published documentation and conventions from the model providers and the open-source coding-agent community.

Anthropic's Claude Code documentation at docs.claude.com is the canonical reference for CLAUDE.md conventions and the project memory model.

The AGENTS.md cross-tool specification at agents.md defines the converging standard adopted by OpenAI Codex CLI, Cline, and others.

Cursor's documentation at docs.cursor.com covers the .cursorrules format and the rules system.

Aider's documentation at aider.chat covers .aider.conf.yml and conventions files for the pair-programming agent.

About PromptLeadz

PromptLeadz publishes free component-built prompt packs and the production-grade Drop-in utilities that wrap them. The franchise covers role-based packs (PM, EM, CSM, Sales Leader, Operator, Data Analyst, VC), format-based packs (.md agent files in breadth and depth), and the underlying frameworks (the 8-Component Skeleton, the Anti-Prompt-Engineering Manifesto).

Every pack rejects the LinkedIn-influencer voice at the prompt level by banning the genre's signature phrases inline. The result is output calibrated for memos that survive peer review, not threads that go viral. Free packs ship with no email gate at promptleadz.com.

Questions people ask

Who is this .md agent pack for?

Software engineers using AI coding tools (Claude Code, Codex CLI, Cursor, Cline, Aider, Continue, ChatGPT custom GPTs) who want to ship production-grade agent config rather than copy magic prompts from threads.

Do I need all four formats?

No. Pick the format that matches your toolchain. If you use Claude Code, the CLAUDE.md category is the priority. If you use Cursor, the .cursorrules category. The pack ships all four so the engineer using two or three tools has them all in one place.

Why is .md better than JSON for AI agent config?

Markdown is committable, diffable, human-readable, tool-agnostic, and escape-free. JSON is none of those things at the same level. The format war ended around the time AGENTS.md became a converging standard.

Do these files work for non-coding agents?

Category 4 (ChatGPT system prompts) covers role-based agents outside the IDE. The other categories are tuned for coding tools. For non-coding agents, see the role-based packs in the franchise (PM, EM, CSM, Operator, VC, Workhorse).

How do I keep these files from going stale?

Treat them as code. Review on PR when conventions change. Re-read quarterly. Delete files that have not been edited in six months and the team has not referenced. Stale config is worse than no config because the model trusts it.

Can I use these in commercial projects?

Yes. The files are free to use, modify, and commit to private or public repos. Attribution is welcome but not required.

The franchise: free packs, frameworks, and the manifesto

The thesis: The Anti-Prompt-Engineering Manifesto. The framework: The 8-Component Skeleton.

Free packs, no email gate · Files you commit · promptleadz.com