Updated October 2026. Searching system prompt templates for coding agents? Soft “be helpful” instructions burn credits. Hard system prompts — living files like CLAUDE.md, Cursor Rules, and agent instruction docs — tell the model how your repo works, what it must never invent, and how to prove a change. This post is a swipe file: full copy-paste templates, claude.md examples for projects, cursor rules examples that work, and coding agent system prompt best practices you can drop into a real codebase today.
If your day-to-day briefs are mushy, tighten them with the Crisp-E prompt method. When generation fails, use the debugging prompts rescue kit. For greenfield scaffolds, keep the copy-paste scaffold prompt pack open. Editor vs terminal agent still matters — see Claude Code vs Cursor. When you need guardrails instead of speed, switch posture with vibe coding vs vibe engineering. After the agent ships a diff, run how to review AI-generated code before you merge.
Voice check: Free Code Hustle / Mazhar Ali style — builder-first. Paste a template. Customize bracketed nouns. Click the happy path. Refuse mystery APIs. This article is about how to write instructions for ai coding agents so they behave like careful juniors with a checklist, not improvisers with confidence.
Table of contents
- What a coding-agent system prompt actually is
- Best practices that survive real repos
- Full CLAUDE.md template (copy-paste)
- Project-specific CLAUDE.md examples
- Cursor Rules templates that work
- Cursor .cursorrules / project rules examples
- Shared rules vs task prompts (do not confuse them)
- Maintenance checklist for living instruction files
- FAQ
- Soft CTA: install one hard rule today
What a coding-agent system prompt actually is
A chat prompt is a one-shot job. A system prompt template for coding agents is durable context: stack conventions, forbidden shortcuts, test commands, review gates, and the shape of acceptable output. Claude Code reads CLAUDE.md (and nested variants). Cursor applies project Rules / .cursorrules / rule files in .cursor/rules. Other agents have their own instruction files. The filename changes; the job does not.
Bad system prompts sound like HR: “Write clean code. Be secure. Follow best practices.” Good ones sound like a senior onboarding doc: “App Router only. No new state libraries. Auth lives in middleware.ts. After every data change, run npm test -- --run. Never invent endpoints not listed in /docs/api.md.”
That difference is why people searching claude.md examples for projects and cursor rules examples that work keep bouncing between tools — they need structure, not another pep talk. The templates below steal Crisp-E energy (Context, Role, Instruction, Specification, Performance, Example) and freeze it into a file the agent loads every session.
Best practices that survive real repos
These coding agent system prompt best practices matter more than clever wording:
- Prefer files over chat memory. If a rule matters twice, it belongs in
CLAUDE.md/ Cursor Rules, not in your head. - Name blast radius. Tell the agent which folders it may touch and which are sacred (migrations, billing, auth).
- Demand evidence. Require commands run, files read, and acceptance checks — same energy as debugging prompts.
- Ban invention. Explicitly forbid new dependencies, fake APIs, and “helpful” refactors outside the task.
- Keep it short enough to read. A 4,000-line manifesto gets ignored. Aim for scannable sections under ~200–400 lines total, with links to deeper docs.
- Separate always-on rules from task prompts. System instructions = standing orders. Chat = this ticket.
- Version the file. When conventions change, update the prompt the same day you update the README.
If your team argues about style endlessly, encode the decision once. Agents do not care who won Slack — they care what the file says.
Full CLAUDE.md template (copy-paste)
Drop this at the repo root as CLAUDE.md. Replace bracketed sections. Keep the structure.
# CLAUDE.md — [Project Name]
## Mission
You are a senior engineer helping ship [one-sentence product]. Prefer small, reviewable diffs over rewrites.
Default posture: careful junior with a checklist — show work, then patch.
## Stack (do not invent alternatives)
- Language / runtime: [TypeScript / Node 20]
- Framework: [Next.js App Router]
- UI: [Tailwind + shadcn/ui]
- Data: [Postgres + Prisma / Drizzle]
- Auth: [Clerk / Supabase Auth / Auth.js]
- Tests: [Vitest + Playwright]
- Package manager: [pnpm]
## Repo map (read before editing)
- App routes: `[app/]`
- UI components: `[components/]`
- Data access: `[lib/db/]` or `[server/]`
- Auth / middleware: `[middleware.ts]`
- Docs: `[docs/]` — API contracts live here; do not invent endpoints
## Standing orders
1. Read relevant files before editing. Quote paths you relied on.
2. One task = one purpose. Do not "while I'm here" refactor.
3. No new dependencies unless the user explicitly asks.
4. Do not invent APIs, env vars, or tables. If missing, ask or stop.
5. Match existing patterns (imports, error shape, naming) before introducing new ones.
6. Prefer server components / server actions where the codebase already does.
7. Secrets stay in env. Never hardcode tokens or paste secrets into chat logs.
## Change policy
- Allowed without asking: fix bugs in the named files, add tests for the change, improve types at the call site.
- Ask first: schema migrations, auth changes, billing, deleting public APIs, dependency upgrades.
- Forbidden: rewriting the app, adding a second state library, drive-by renames across the tree.
## Definition of done
For every non-trivial change, output:
1) Goal in one sentence
2) Files read
3) Files changed (and why)
4) Commands run + results
5) Manual acceptance checks (click or curl)
6) Risks / follow-ups
## Commands
- Install: `[pnpm install]`
- Dev: `[pnpm dev]`
- Unit: `[pnpm test]`
- Typecheck: `[pnpm typecheck]`
- E2E smoke: `[pnpm test:e2e]`
After data-layer edits, run unit + typecheck before claiming done.
## Code style (project law)
- [No default exports for shared utils]
- [Errors: Result type / typed HTTP errors — match existing]
- [Logging: use existing logger, no console.log in prod paths]
- [Dates: UTC in DB, format at edges]
## Security & tenancy
- Every query must respect [tenant/user] scope already used in the codebase.
- Never disable auth middleware "temporarily."
- Validate inputs at boundaries; do not trust client bodies.
## When stuck
If evidence is missing, ask for ONE artifact (log, failing test, screenshot text) instead of guessing.
If the task conflicts with this file, stop and surface the conflict.
## Examples of good vs bad patches
Good: fix null guard in `getInvoice`, add test, leave unrelated files alone.
Bad: rename half the module tree while "cleaning up" a null crash.
That block is the core of how to write instructions for ai coding agents: mission, stack, map, standing orders, change policy, definition of done. Everything else is flavor.
Project-specific CLAUDE.md examples
Here are shorter claude.md examples for projects you can append under the template — or use as thin files for focused packages in a monorepo.
Example A — Next.js SaaS (App Router)
## Product constraints
- Screens in scope: marketing, login, invoice list, invoice detail, settings.
- Primary entity: Invoice { id, clientName, amountCents, dueDate, status, notes }.
- Non-goals: multiplayer, AI chat widget, custom billing portal rebuild.
## App Router rules
- Use `app/` routes only. No Pages Router.
- Mutations via server actions in `app/**/actions.ts` unless a route handler already exists.
- Client components only when interactivity requires it; mark with `"use client"`.
## Data rules
- All invoice queries filter by `organizationId` from the session.
- Soft-delete with `deletedAt`; never hard-delete user data in agents' default patches.
Example B — Python API service
## Stack
- FastAPI + SQLAlchemy 2.x + Alembic + pytest
- Lint: ruff; types: mypy on `src/`
## Standing orders
- Add Alembic migrations for schema changes; never edit prod DB by hand.
- Pydantic models at the edge; domain models inside.
- Every new endpoint needs: request/response models, auth dependency, test in `tests/api/`.
## Forbidden
- Catch-all `except Exception` that swallows errors
- Committing `.env` or rotating secrets in code
Example C — Monorepo package note
## Scope for this package (`packages/ui`)
- You may edit components and Storybook stories here.
- Do not change `packages/api` or root deploy configs without an explicit ask.
- Public exports go through `packages/ui/src/index.ts` only.
Nested CLAUDE.md files work well when different packages have different blast radii. Keep the root file for global law; keep package files for local law.
Cursor Rules templates that work
Cursor Rules are the standing system prompt for Composer / agent mode. Whether you use a root .cursorrules file or multiple files under .cursor/rules/, the content pattern matches: short, imperative, testable. These are cursor rules examples that work because they constrain tools, not personalities.
Template — root project rules
# Project Rules — [App Name]
You are editing a [Next.js App Router + TypeScript] codebase.
## Always
- Read existing neighbors before writing new files.
- Prefer editing existing modules over creating parallel utilities.
- Keep diffs small; explain non-obvious choices in 2-4 bullets.
- Run `[pnpm typecheck]` and relevant tests after substantive edits.
## Never
- Never add dependencies without asking.
- Never commit secrets or rewrite auth/billing without an explicit request.
- Never invent API routes; check `docs/api.md` or existing handlers first.
- Never disable ESLint/TS errors with blanket ignores.
## Output format for agent tasks
1. Plan (3 bullets max)
2. Patch
3. Verification commands + results
4. Manual checks
## Style
- Match file's existing import style and naming.
- Tailwind utility classes; no new CSS frameworks.
- Components: colocate small helpers; shared UI goes in `components/ui`.
Template — focused rule file (e.g. `.cursor/rules/api.mdc`)
---
description: API and server-action conventions
globs: app/**/actions.ts, app/api/**/*.ts, server/**/*.ts
---
# API rules
- Validate inputs with existing Zod schemas in `lib/validators`.
- Return consistent error shapes used by the app (see `lib/errors.ts`).
- No raw SQL unless a file already uses it; prefer the ORM helpers in `lib/db`.
- Include a unit test beside or under `tests/` for new branches.
- Do not log PII; redact emails and tokens.
Template — UI-only rule file
---
description: UI generation and component edits
globs: components/**/*.tsx, app/**/page.tsx
---
# UI rules
- Mobile-first layout; respect existing spacing scale.
- Empty, loading, and error states required for list/detail screens.
- No glassmorphism, no three competing CTAs, no lorem in user-facing copy.
- Prefer composition over prop sprawl; extract only when reused twice.
Glob-scoped rules beat one giant essay. The agent gets sharp instructions when it touches the matching paths — which is closer to how seniors review PRs (“API changes need tests; UI changes need empty states”).
Cursor .cursorrules / project rules examples
Two more paste-ready cursor rules examples that work for common setups.
Example — bugfix mode (pin in chat or as a rule)
ROLE: Incident responder, not a rewriter.
SCOPE: Only files needed for [bug summary].
PROCESS: Reproduce from evidence → name root cause → minimal patch → prove with command or click path.
EVIDENCE REQUIRED: paste terminal/browser output in fenced blocks before editing.
REJECT: drive-by refactors, dependency adds, renaming for taste.
Example — feature slice mode
GOAL: Ship vertical slice for [feature] with screens [list] and fields [list].
CONSTRAINTS: Match stack in CLAUDE.md / project rules. No payments. No admin console.
ACCEPTANCE:
- Create → list → detail works for a logged-in user
- Unauthorized users cannot read/write the entity
- Unit tests for the happy path and one auth failure
DELIVERABLE: patch + commands + checklist. Stop when acceptance passes.
Pair these with the scaffold pack when you are generating a new slice, and with the debugging kit when the slice is red. System rules set the floor; task prompts set the ceiling for this hour.
Shared rules vs task prompts (do not confuse them)
People fail at system prompt templates for coding agents by stuffing the entire ticket into CLAUDE.md. Then the file rots, contradicts itself, and the agent gets noisy.
| Layer | Lives in | Changes when | Example |
|---|---|---|---|
| Standing law | CLAUDE.md / Cursor Rules | Stack or policy changes | No new deps; App Router only |
| Task brief | Chat / Composer / ticket | Every job | Fix login redirect loop with evidence |
| Review gate | PR template / human checklist | Rarely | Auth, migrations, billing need second eyes |
Crisp-E still owns the task brief. System files own the permanent constraints. Review owns the merge. If you blur those layers, you will either over-constrain daily work or under-constrain dangerous areas.
Maintenance checklist for living instruction files
- Quarterly prune. Delete rules the team ignores. Ignored rules train the agent that docs are optional.
- Update on stack bumps. New ORM? New auth vendor? Same-day edit to
CLAUDE.md. - Link, don’t duplicate. Point to
docs/api.mdinstead of pasting the whole API surface. - Measure pain. If the agent keeps inventing the same wrong pattern, add one hard ban — not five soft suggestions.
- Align humans. Onboarding should point new engineers at the same files the agents read.
This is vibe engineering energy: speed stays, guardrails get written down. Soft culture becomes hard text.
FAQ
Do I need both CLAUDE.md and Cursor Rules?
If your team uses both Claude Code and Cursor, keep a shared core (stack, bans, definition of done) and thin tool-specific wrappers. Duplicating 100% creates drift; sharing zero creates tool-tribal conventions.
How long should system prompts be?
Long enough to prevent repeated mistakes, short enough that a human will maintain them. If you need novels, split into linked docs and keep the agent file as an index plus hard laws.
Should system prompts include full Crisp-E every time?
No. Encode Crisp-E once as structure (context, role, constraints, output shape). Use full Crisp-E briefs in chat for each feature or incident.
What if the agent ignores the file?
Tighten: fewer adjectives, more commands and bans. Reference concrete paths. Require the definition-of-done block. And fix contradictions — agents love exploiting conflicting instructions.
Are these a substitute for code review?
No. System prompts reduce nonsense; humans still catch product risk. Use your review checklist, especially on auth, data, and billing.
Soft CTA: install one hard rule today
Pick one failure you saw this week — invented API, surprise dependency, auth scope miss — and write a single standing ban into CLAUDE.md or Cursor Rules. Paste the full template above if you are starting from zero. Then run one real task and insist on the definition-of-done block.
When the next diff arrives, review it like you mean it. When it breaks, rescue it with hard debugging prompts. When you scaffold the next slice, use the scaffold pack. Tool choice still matters (Claude Code vs Cursor), but instructions matter more: agents inherit your clarity — or your fog.
