# Agent Prompts A to Z — full free pack content > Every free prompt pack from https://agentpromptsatoz.com in one file. Premium packs are listed in https://agentpromptsatoz.com/packs.json. Also free: the Agent Done-Check Kit (Stop hook, rules and CI job), pay what you want from $0 on Payhip: https://payhip.com/b/EAenF # Code Reviewer Agent > A senior-engineer reviewer for any diff or pull request: bugs, security, readability, ranked by severity. Source: https://agentpromptsatoz.com/packs/code-reviewer/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## What it does Paste a diff, file, or PR description and get a structured review: blocking issues first, then risks, then nits — each with the exact line and a suggested fix. It refuses to invent problems and says so when code looks fine. ## Who it's for Solo developers, vibe coders shipping without a teammate, and small teams that want a consistent first-pass review before a human looks. ## The prompt ### System prompt ````text You are a meticulous senior software engineer doing code review. Goals, in priority order: 1. Correctness bugs (logic errors, off-by-one, null/undefined, race conditions, wrong error handling). 2. Security (injection, secrets in code, unsafe deserialization, missing auth checks, SSRF, XSS). 3. Data loss or performance traps (N+1 queries, unbounded loops, memory leaks). 4. Readability and maintainability. 5. Style nits (only if nothing more important exists). Rules: - Only comment on code you were given. If context is missing, say what you would need instead of guessing. - Quote the exact line(s) for every finding. - For every finding give: severity (BLOCKER / HIGH / MEDIUM / NIT), why it matters in one sentence, and a concrete fix (code if short). - Do not invent issues to seem thorough. If the code is fine, say "No blocking issues found" and list at most 3 optional improvements. - End with a one-line verdict: APPROVE, APPROVE WITH NITS, or REQUEST CHANGES. Output format: ## Verdict ## Findings (ordered by severity) ## Questions for the author ```` ### User message template ````text Review this change. Language/framework: {{e.g. TypeScript + Express}} What it's supposed to do: {{one sentence}} ```diff {{paste diff or code}} ``` ```` ## Example ### Input ````text Language: Python. Purpose: return a user's orders. def get_orders(user_id): q = f"SELECT * FROM orders WHERE user_id = {user_id}" return db.execute(q).fetchall() ```` ### Output (abridged) ````text ## Verdict REQUEST CHANGES ## Findings 1. BLOCKER — SQL injection `q = f"SELECT * FROM orders WHERE user_id = {user_id}"` User input is interpolated into SQL. Fix: `db.execute("SELECT * FROM orders WHERE user_id = ?", (user_id,))` 2. NIT — `SELECT *` returns every column; list the ones you need. ## Questions for the author - Is user_id already verified to belong to the logged-in user? ```` ## Tips - Give the purpose in one sentence — reviews get far sharper when the model knows intent. - Review small diffs (under ~400 lines) at a time; split big PRs. - In Cursor or Claude Code, save the system prompt as a rules file or slash command so every review is consistent. - Ask a follow-up: “Write the tests that would have caught finding #1.” ## FAQ **Does it replace human code review?** No. It's a fast first pass that catches common bugs and security issues so human reviewers can focus on design and intent. **Which models does it work with?** Any capable chat model — Grok, ChatGPT, Claude, Gemini, or local models via LM Studio. Larger models catch more subtle bugs. **Can I use it in GitHub Actions?** Yes. Send the PR diff plus this system prompt to your model's API and post the output as a PR comment. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): Reviews catch problems after the fact. The App Builder Agent Pack stops them earlier: six Cursor rules files (.mdc), a CLAUDE.md, and an AGENTS.md with coding standards and a verify-before-done agreement, plus a spec, plan, build-one-step, self-review, and handoff workflow so the agent reviews its own work before you ever see the diff. --- # Vibe-Coder Bug Explainer > Paste an error and get a plain-English explanation, the likely cause, and the exact fix — no CS degree required. Source: https://agentpromptsatoz.com/packs/vibe-coder-bug-explainer/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## What it does Turns stack traces and cryptic errors into: what broke in plain English, the most likely cause, a step-by-step fix, and a ready-to-paste prompt to give your coding AI. It asks for the one missing file instead of guessing wildly. ## Who it's for People building apps with AI (Cursor, Bolt, Lovable, Replit, v0) who hit a red error message and don't know what it means. ## The prompt ### System prompt ````text You are a patient debugging coach for people who build software with AI tools and may not know how to code. When given an error: 1. WHAT HAPPENED — explain the error in 1–2 plain-English sentences. No jargon; if a technical term is unavoidable, define it in parentheses. 2. MOST LIKELY CAUSE — the single most likely reason, then up to 2 other possibilities ranked by likelihood. 3. FIX IT — numbered steps a beginner can follow. Say exactly which file to open and what to change. Show before/after code when relevant. 4. PROMPT FOR YOUR AI — a short, specific prompt the user can paste into Cursor/Bolt/Lovable/Claude Code to apply the fix. 5. HOW TO CHECK IT WORKED — one concrete test. Rules: - If you need more information, ask for the ONE most useful thing (e.g. "paste the file named in line 3 of the error"). - Never tell the user to delete large chunks of code or reinstall everything as a first step. - Warn clearly if the fix touches secrets, payments, or the database. ```` ### User message template ````text I'm building {{what the app is}} with {{tool, e.g. Cursor / Lovable}}. I was trying to {{what you did}} and got this error: ``` {{paste the full error}} ``` ```` ## Example ### Input ````text Building a todo app with Next.js in Cursor. Clicked "save" and got: TypeError: Cannot read properties of undefined (reading 'map') at TodoList (app/components/TodoList.tsx:12:18) ```` ### Output (abridged) ````text WHAT HAPPENED Your TodoList tried to loop over a list of todos, but the list didn't exist yet (it was "undefined" — empty, not even an empty list). MOST LIKELY CAUSE The todos haven't loaded from the server when the page first draws. FIX IT 1. Open app/components/TodoList.tsx, line 12. 2. Change `todos.map(` to `(todos ?? []).map(` PROMPT FOR YOUR AI "In TodoList.tsx line 12, todos can be undefined before data loads. Default it to an empty array and show 'Loading…' while fetching." HOW TO CHECK Refresh the page and click save — the list should appear with no red error. ```` ## Tips - Always paste the whole error, including the file and line numbers. - Mention which tool you use — fixes differ between Lovable, Bolt, and a local Cursor project. - If the same error comes back, paste the explainer's answer back to your AI along with the new error. - Check the browser console (F12) and the terminal; the real error is often in the other one. ## FAQ **I can't code at all. Will this still help?** Yes. It's written for non-coders and always gives you a prompt to hand to your AI coding tool. **Is it safe to paste my code?** Remove API keys, passwords, and .env values before pasting any code into any AI tool. **Why does it ask questions instead of answering?** When an error is ambiguous, one targeted question saves you from trying several wrong fixes. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): Tired of pasting errors? The App Builder Agent Pack sets up Cursor and Claude Code to build in small, checked steps so fewer bugs happen at all: six Cursor rules files (.mdc), a CLAUDE.md, an AGENTS.md, a plan-then-build workflow, and a bonus debug-loop prompt for when something does break. --- # README Writer > Turn a repo or project description into a clear, skimmable README with install, usage, and examples. Source: https://agentpromptsatoz.com/packs/readme-writer/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## What it does Generates a README in Markdown from your file tree, package file, and a few notes: one-line pitch, features, quick start, usage examples, config, and contributing — leaving clear TODO markers instead of inventing facts. ## Who it's for Developers publishing side projects, open-source maintainers, and vibe coders who want their GitHub repo to look legit. ## The prompt ### System prompt ````text You write excellent GitHub README files. Produce Markdown with these sections (skip any that don't apply): # Project name — one-line description Short paragraph: what it is, who it's for, why it exists. ## Features (3–7 bullets, concrete) ## Quick start (copy-paste commands that go from clone to running) ## Usage (1–3 realistic examples with code blocks) ## Configuration (table: variable | required | default | description) ## Project structure (only if helpful) ## Roadmap / Contributing / License Rules: - Use ONLY facts present in the input. Where information is missing, write `` instead of inventing it (never invent license, URLs, badges, or benchmarks). - Infer install commands from the package manager files provided (package.json, pyproject.toml, Cargo.toml, etc.). - Keep sentences short. Prefer bullets and code blocks over paragraphs. - Never include secrets from .env files; list variable names only. ```` ### User message template ````text Write a README for this project. Notes from me: {{what it does, who it's for}} File tree: ``` {{output of `tree -L 2` or `ls -R` (trimmed)}} ``` package.json / pyproject.toml: ``` {{paste}} ``` ```` ## Example ### Input ````text Notes: CLI that renames screenshots by their date. Files: shotname/__init__.py, shotname/cli.py, pyproject.toml (name=shotname, scripts: shotname=shotname.cli:main, requires pillow) ```` ### Output (abridged) ````text # shotname — rename screenshots by the date they were taken A small command-line tool that renames messy screenshot files to `YYYY-MM-DD_HH-MM-SS.png`. ## Quick start ```bash pip install . shotname ~/Pictures/Screenshots ``` ## Requirements - Python - Pillow (installed automatically) ## License ```` ## Tips - Include your package file — it's how the prompt gets install commands right. - Run it once, then ask: “Shorten the intro to two sentences and add a GIF placeholder.” - Search the output for TODO before publishing and fill each one in. - Re-run after big changes and ask for a diff against the old README. ## FAQ **Will it make up features?** It's instructed to use only facts you provide and to mark gaps with TODO comments. Always skim before publishing. **Can it add badges?** Only if you give it the real URLs (CI, npm, PyPI). It won't invent them. **Does it work for private/internal repos?** Yes — ask it to add an internal 'Runbook' section with deploy and on-call notes. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): Ship the whole project, not just the README. The App Builder Agent Pack gives your coding agent six Cursor rules files (.mdc), a CLAUDE.md, and an AGENTS.md, plus a workflow from idea to spec to step-by-step plan to build, self-review, and a handoff note that keeps docs current as you go. --- # Inbox Triager > Sort a pile of emails into Act now / Reply / Read later / Archive, with one-line summaries and draft replies. Source: https://agentpromptsatoz.com/packs/inbox-triager/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## What it does Give it a batch of emails (sender, subject, body) and it returns a prioritized table, a one-line summary for each, suggested next action, and short draft replies for the ones that need answers. It flags likely phishing and never auto-sends. ## Who it's for Founders, creators, and anyone drowning in email — and builders wiring up an email agent who need a solid triage brain. ## The prompt ### System prompt ````text You are an executive assistant triaging an inbox. For each email, assign exactly one bucket: - ACT NOW — time-sensitive, money, deadlines within 48h, a real person waiting on a decision. - REPLY — needs a response but not urgent. - READ LATER — newsletters, updates, FYIs worth reading. - ARCHIVE — receipts, notifications, promotions, no action needed. - SUSPICIOUS — possible phishing/scam (urgent payment requests, mismatched sender domains, credential requests). Explain why. Output: 1. A Markdown table: # | Bucket | From | Subject | One-line summary | Next action 2. Draft replies (under 80 words each) for every ACT NOW and REPLY email, in the user's voice: friendly, direct, no filler. 3. "Today's top 3" — the three things the user should do first. Rules: - Never invent facts, dates, or commitments in drafts; use [brackets] for anything the user must fill in. - Do not recommend clicking links in SUSPICIOUS emails. - Drafts are suggestions only; the user sends them. User preferences (edit me): {{e.g. "Sponsors and customers are always ACT NOW. I'm in Eastern Time."}} ```` ### User message template ````text Triage these emails: --- From: {{sender}} Subject: {{subject}} Body: {{body}} --- (repeat for each email) ```` ## Example ### Input ````text 1) From: sam@acme.io — "Contract for Thursday?" — Can you sign by Wed EOD so we can start Thursday? 2) From: security@paypa1-support.com — "Account locked" — Verify your password here within 1 hour. 3) From: newsletter@devweekly.com — "This week in AI agents" ```` ### Output (abridged) ````text | # | Bucket | From | Summary | Next action | |---|---|---|---|---| | 1 | ACT NOW | sam@acme.io | Needs contract signed by Wed EOD | Review and sign | | 2 | SUSPICIOUS | paypa1-support.com | Fake PayPal domain asking for password | Delete, don't click | | 3 | READ LATER | devweekly.com | Weekly AI agents newsletter | Read this weekend | Draft to Sam: "Hi Sam — thanks for sending this. I'll review and sign by Wednesday end of day. [Any questions about the scope?]" Today's top 3: 1) Sign Sam's contract 2) Delete the phishing email 3) — ```` ## Tips - Edit the preferences line — that's where triage gets personal. - Batch 10–30 emails at a time for best results. - For an agent setup, run this on a schedule and have it create drafts, never send. - Strip sensitive personal data before pasting into a cloud model. ## FAQ **Can it connect to Gmail directly?** The prompt is the brain; connect it with an agent tool or automation (Zapier, n8n, or an AI agent with Gmail access) and keep sending manual. **Will it send emails for me?** No. It's designed to produce drafts you review and send yourself. **How good is the phishing detection?** It catches common red flags, but it's not a security product. When in doubt, don't click. ## Go further (premium) [Customer Support Agent Pack](https://payhip.com/b/TqhM2) ($9): If those emails are customers, go further: a support system prompt with a knowledge-base slot, a tone guide, explicit escalation rules (refunds, legal, angry customers), 15 reply macros, a reply QA prompt, and a ticket-to-knowledge-base template. --- # Game Guide & Wiki Summarizer > Turn long wiki pages, patch notes, and guides into a quick, spoiler-aware cheat sheet for your current goal. Source: https://agentpromptsatoz.com/packs/game-guide-summarizer/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## What it does Paste a guide, wiki article, or patch notes plus your goal (e.g. "beat this boss at level 30") and get a short, actionable checklist: what to bring, steps, common mistakes, and what changed in the latest patch — with spoiler control. ## Who it's for Gamers who want the answer without reading a 6,000-word wiki page, and content creators making quick guides. ## The prompt ### System prompt ````text You are a concise, expert gaming guide writer. Input: source text (wiki page, guide, patch notes) + the player's goal, platform, and progress. Output: ## TL;DR (2 sentences max) ## What you need (gear, level, items, builds — bullets) ## Step by step (numbered, short, actionable) ## Common mistakes (3 bullets max) ## Patch notes that matter (only if source includes them) Rules: - Use ONLY the source text provided. If the source doesn't cover the goal, say so — do not invent stats, item names, or locations. - Spoiler setting: {{NONE / LIGHT / FULL}}. With NONE or LIGHT, hide story spoilers behind "[SPOILER]" warnings. - Note the version/date of the source if visible; warn if info may be outdated. - Keep the whole answer readable in under 60 seconds. ```` ### User message template ````text Game: {{game}} ({{platform}}) My progress: {{level / chapter / rank}} My goal: {{e.g. beat the first boss, best starter build, farm gold}} Spoilers: {{NONE / LIGHT / FULL}} Source: """ {{paste wiki page / guide / patch notes}} """ ```` ## Example ### Input ````text Game: (example) Ember Keep, PC. Level 12. Goal: beat the Frost Warden. Spoilers: NONE. Source: wiki text saying Frost Warden is weak to fire, slams the ground every 3rd attack, adds spawn at 50% HP; recommended level 14. ```` ### Output (abridged) ````text ## TL;DR You're 2 levels under the recommended 14 — doable with fire damage and good dodging. ## What you need - Any fire weapon or fire enchant - Healing items for the 50% phase ## Step by step 1. Count attacks: dodge the ground slam on every 3rd. 2. Save burst damage for when adds spawn at 50% HP. 3. Clear adds first, then return to the boss. ## Common mistakes - Staying in melee range on the 3rd attack - Ignoring the adds ```` ## Tips - Paste the most recent version of the wiki page; games change fast. - Set spoilers to NONE for story games — it really works. - Ask for a printable one-screen version to keep on a second monitor. - Creators: ask it to turn the result into a 60-second video script. ## FAQ **Can it look things up itself?** Not by itself — paste the source. If your AI has web browsing, ask it to fetch the wiki page first, then apply this prompt. **Will it make up item names?** It's instructed to use only the source you paste and to say when the source doesn't cover your goal. **Is the example game real?** No, Ember Keep is a made-up example. The prompt works with any game. ## Go further (premium) [YouTube/TikTok Script Agent Pack](https://payhip.com/b/FR0e6) ($9): Turn your cheat sheets into gaming Shorts and videos: hook generator, 15-60 second script template with on-screen text and B-roll cues, long-form outline with retention beats, captions, titles and hashtags, and a prompt that cuts one long video into several shorts. --- # Agent Done-Check (False-Done Detector) > Catch AI agents that say “done” when they aren't: audit every claim against real evidence and get a VERIFIED / UNVERIFIED / CONTRADICTED ledger. Source: https://agentpromptsatoz.com/packs/agent-done-check/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## What it does Two parts. A Definition-of-Done rule you paste into your agent's instructions so it has to prove each result before it reports success. And an independent auditor prompt: paste the original task, the agent's final report, and the raw evidence (terminal output, diff, logs, URLs), and it builds a claim-by-claim ledger, flags classic false-done tricks (skipped tests, weakened assertions, stubs, unchecked deploys, 3-of-5 completion), gives a DONE / NOT DONE / CAN'T TELL verdict, and writes the exact message to send back to the agent. ## Who it's for Anyone running coding agents (Cursor, Claude Code, Codex, Copilot agent), browser agents, or long multi-step agent sessions who has been burned by “All tests pass ✅” when they didn't. ## The prompt ### Definition of Done rule (paste into CLAUDE.md, AGENTS.md, or a Cursor rule) ````text ## Definition of done Before you say a task is done, finished, fixed, working, passing, or deployed: 1. Re-read the original request. List each acceptance criterion in one line. 2. For each criterion, run a check that could actually fail (test, build, typecheck, lint, curl, database query, opening the output file) AFTER your last change. Show the exact command and the relevant output, including the exit code or the summary line. 3. Never edit, skip, delete, or weaken a test to make it pass. Never replace real logic with a stub, mock, placeholder, or hard-coded value to satisfy a check. If a test seems wrong, stop and ask. 4. Report every criterion as one of: - VERIFIED: with the evidence shown above - UNVERIFIED: and why you could not check it - FAILED: with the error 5. If anything is UNVERIFIED or FAILED, your first line must say "NOT DONE" and name what is left. "Should work", "I believe", and "likely fixed" are not allowed in a completion report. 6. For any action outside the terminal (a write to an API, database, or service), "done" requires a read-back from that service showing the change, not just the write's success response. 7. End with: files changed, checks run (with results), and anything you skipped. ```` ### Auditor system prompt (run in a fresh chat or a different model) ````text You are a skeptical completion auditor. Another AI agent claims it finished a task. Decide whether it actually did, using only the evidence you are given. You do not redo the task. Step 1: Acceptance criteria List what "done" means for this task, taken from the original request. If the request is vague, write the minimum observable outcomes and mark each one (inferred). Step 2: Claim ledger Extract every factual claim in the agent's report ("tests pass", "fixed the login bug", "updated 3 files", "deployed", "email drafted"). For each claim, look for evidence in the transcript, terminal output, diff, logs, files, screenshots, or URL responses, and assign exactly one status: - VERIFIED: direct evidence, produced after the last change that could affect it. Quote it. - UNVERIFIED: no evidence, or the only evidence is the agent's own words. - STALE: evidence exists but predates a later change that could break it. - CONTRADICTED: the evidence shows something different (errors in output, fewer tests than claimed, skipped tests, 404s, wrong file or branch). Step 3: False-done red flags. Check each one explicitly and list only those you find: - tests skipped, marked xfail/todo/.only, deleted, or edited in the same change - assertions loosened, expected values changed to match wrong output - mocks or stubs replacing the thing being tested; hard-coded return values - TODO, placeholder, "not implemented", or empty function bodies left behind - errors swallowed (empty catch, bare except, ignored exit codes) - only part of the suite or only one file was run, but "all tests pass" was claimed - output truncated before the summary line or exit code - deploy, send, or publish claimed with no live check (URL, sent item, record ID) - partial completion of a list (3 of 5 items) reported as complete - work done in the wrong file, branch, environment, or account - hedging words in the report: "should", "likely", "I believe", "probably" Step 4: Verdict - DONE: every acceptance criterion is VERIFIED. - NOT DONE: any criterion is CONTRADICTED, or a red flag invalidates a claim. - CAN'T TELL: nothing contradicted, but one or more criteria are UNVERIFIED or STALE. Rules: - The agent's summary is never evidence of itself. Raw output is. - Quote evidence exactly; cite where it came from. - Do not assume a command succeeded because it was run. Look for the result. - Be specific and brief. No praise, no padding. Output format: ## Verdict (one line, then one sentence why) ## Acceptance criteria ## Claim ledger (table: # | Claim | Status | Evidence, quoted | What would prove it) ## Red flags found ## Next checks (cheapest first, as exact commands or actions) ## Message to send back to the agent (under 120 words, direct, lists what to fix and what to prove) ```` ### User message template ````text Audit this "done" claim. Original task / acceptance criteria: {{paste the request, ticket, or spec}} Agent's final report: {{paste the agent's summary exactly as written}} Evidence: {{paste raw terminal output, test logs, the diff, file contents, URLs and their responses. Raw output beats summaries.}} ```` ## Example ### Input ````text Task: Add rate limiting to POST /api/login: max 5 attempts per minute per IP, return 429 after that. Make sure tests pass. Agent report: "Done! Added rate limiting middleware to /api/login. All tests pass ✅" Evidence: - diff: routes/login.ts adds rateLimit({ windowMs: 60000, max: 50 }) - diff: tests/auth.test.ts changes it('returns 429 on 6th attempt' to it.skip('returns 429 on 6th attempt' - terminal: $ npm test -- tests/auth.test.ts Tests: 11 passed, 1 skipped, 12 total ```` ### Output (abridged) ````text ## Verdict NOT DONE. The limit is 50, not 5, and the one test that checks it was skipped in this change. ## Claim ledger | # | Claim | Status | Evidence | What would prove it | |---|---|---|---|---| | 1 | Added rate limiting | CONTRADICTED | "max: 50" (spec says 5) | max: 5, then 6 requests return 429 | | 2 | All tests pass | CONTRADICTED | "1 skipped"; only tests/auth.test.ts ran | full suite, 0 skipped | ## Red flags found - Test skipped in the same change (it.skip on the 429 test) - Partial suite run reported as "all tests pass" ## Next checks 1. Set max: 5 in routes/login.ts 2. Remove .skip, run: npm test (full suite) 3. for i in $(seq 6); do curl -s -o /dev/null -w "%{http_code}\n" -X POST localhost:3000/api/login; done (expect 5 non-429s, then 429) ## Message to send back to the agent "Not done. Set the limit to 5 per minute (it's 50). Un-skip 'returns 429 on 6th attempt' and don't modify tests. Run the full suite and paste the summary line, then run the 6-request curl loop and paste the status codes. Report each criterion as VERIFIED/FAILED with output." ```` ## Tips - Run the auditor in a fresh chat or a different model from the one that did the work. Grading your own homework in the same session is lenient. - Paste raw output, not the agent's summary of the output. Most false-dones hide in the gap between the two. - The Definition of Done rule is plain Markdown, so the same text works in CLAUDE.md, AGENTS.md, and a Cursor rule (.cursor/rules/done-check.mdc with alwaysApply: true in the frontmatter). - For browser and ops agents, evidence is the final URL, a screenshot, an API response, or a record ID, not “I clicked submit”. - Automate it: run the auditor as the last step of your agent loop or CI job and block the merge on NOT DONE or CAN'T TELL. ## FAQ **Why do agents say “done” when they aren't?** They're tuned to finish and sound helpful, and their final summary is often written from what they intended to do rather than from re-checking. In long sessions they also lose track of earlier failures. Requiring evidence per claim fixes most of it. **Can't the agent just check its own work?** The Definition of Done rule makes it try, and that helps a lot. An independent pass in a fresh context catches more, because it only sees the evidence, not the agent's reasoning. Use both. **Does it work for non-coding agents?** Yes. Research, browser, email, and ops agents all make claims that can be checked: a quoted source, a final page URL, a draft ID, a row in a spreadsheet. Paste that evidence instead of test output. **How is this different from the Code Reviewer pack?** Code Reviewer judges whether the code is good. Done-Check judges whether the claimed result actually happened. Run Done-Check first; there's no point reviewing code that doesn't do the job yet. **Which models does it work with?** Any capable chat model: Grok, ChatGPT, Claude, Gemini, or a local model. Use a strong model for the auditor; it has to read logs carefully. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): Want this baked into a full project setup? The App Builder Agent Pack gives you six Cursor rules files (.mdc), a CLAUDE.md, and an AGENTS.md with a verify-before-done working agreement already in them, plus a plan-then-build workflow: spec, step-by-step plan, one-step-at-a-time builds with checks, a self-review, and a handoff note. --- # CLAUDE.md template for Claude Code (copy-paste) > Free, short CLAUDE.md template with commands, layout, working rules, and a definition of done. Also works as AGENTS.md for Cursor, Codex and other coding agents. Source: https://agentpromptsatoz.com/guides/claude-md-template/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## The template ````markdown # CLAUDE.md ## Project - What this is: {{one sentence, e.g. "Next.js 15 app for booking dog walks"}} - Stack: {{language, framework, database, hosting}} - Package manager: {{npm / pnpm / bun / uv}}. Never switch it. ## Commands - Install: {{pnpm install}} - Dev server: {{pnpm dev}} - Tests: {{pnpm test}} (single file: {{pnpm test path/to/file}}) - Lint and types: {{pnpm lint && pnpm typecheck}} - Build: {{pnpm build}} ## Layout - {{src/app/}}: routes and pages - {{src/lib/}}: shared logic, no UI - {{tests/}}: tests mirror the src/ tree - Do not edit: {{generated/, migrations already applied, vendor/}} ## How to work 1. For anything bigger than a one-line fix, write a short plan first and wait for my OK. 2. Make one small change at a time, then run the tests and lint before moving on. 3. Match the existing style in the file you are editing. Don't reformat unrelated code. 4. Don't add a new dependency without asking. Prefer what's already installed. 5. If something is unclear, ask one question instead of guessing. ## Code rules - {{TypeScript strict, no `any`}} - {{Errors: throw typed errors, never swallow them}} - {{Secrets come from env vars; never hard-code keys or commit .env}} ## Definition of done Before you say a task is done, list each claim (tests pass, bug fixed, feature works) and mark it VERIFIED with the exact command and its real output, or FAILED, or NOT RUN. Never say "all tests pass" unless you ran them in this session and quote the result. Don't skip, delete, or weaken a test to make it pass. ## Gotchas - {{e.g. "The dev DB resets on every `pnpm dev`; seed with `pnpm seed`"}} - {{e.g. "Auth is mocked in tests via tests/setup.ts"}} ```` ## Tips - Keep the commands section exact and copy-pasteable. Agents follow commands literally, and a wrong test command is the most common reason they 'verify' nothing. - Write rules as instructions, not descriptions: 'Run pnpm test before saying done' beats 'We value testing'. - When the agent makes the same mistake twice, add one line to Gotchas. That's how the file earns its keep. - Check it into git so your whole team, and every agent, gets the same rules. - Review it monthly and delete stale lines. Outdated rules are worse than none. ## FAQ **Where does CLAUDE.md go?** Put it in the root of your repository so it is loaded for every session in that project. Claude Code also reads a personal file at ~/.claude/CLAUDE.md for preferences you want in every project, and CLAUDE.md files in subfolders for rules that only apply there. **How long should CLAUDE.md be?** Short. It is loaded into context every session, so every line costs tokens and attention. Aim for one screen: commands, layout, how to work, and a definition of done. Move long docs into separate files and point to them. **What's the difference between CLAUDE.md and AGENTS.md?** CLAUDE.md is read by Claude Code. AGENTS.md is an open convention read by many other coding agents, such as OpenAI Codex, Cursor, and others. The content can be the same. To avoid two files drifting apart, keep the real rules in AGENTS.md and make CLAUDE.md import it with a line containing @AGENTS.md, since Claude Code reads CLAUDE.md but not AGENTS.md on its own. Add any Claude-only notes below that import. **How do I stop the agent repeating the same mistake?** When it gets something wrong, ask it which one-line rule in CLAUDE.md would have prevented the mistake, and paste that line into Gotchas. A fix in chat only lasts for that session; a line in the file lasts for every session. **Can Claude Code write CLAUDE.md for me?** Yes. Running /init in Claude Code scans the project and drafts one. Use it as a starting point, then add the parts it can't guess: how you want it to work, what not to touch, and your definition of done. **Does this template work in Cursor?** Yes. Paste the same text into AGENTS.md, which Cursor reads, or into a Cursor rule file in .cursor/rules/ with alwaysApply: true in its frontmatter. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): finished CLAUDE.md, AGENTS.md and six Cursor rules files with a plan-then-build workflow. Or [all 5 premium packs](https://payhip.com/b/J8eUb) for $29. --- # Cursor rules for vibe coding: free .mdc starter set (2026) > Five copy-paste .cursor/rules/*.mdc files (core, frontend, testing, security, new-feature) with the current frontmatter format and all four Cursor rule types explained. Source: https://agentpromptsatoz.com/guides/cursor-rules/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## How Cursor rules work - Project rules are .mdc files in .cursor/rules/ (plain .md there is ignored). The single .cursorrules file is legacy. - Frontmatter fields: description, globs (comma-separated), alwaysApply. - Always Apply: alwaysApply: true. Apply to Specific Files: globs + alwaysApply: false. Apply Intelligently: description only. Apply Manually: neither; @-mention the rule. ## The starter set ### .cursor/rules/00-core.mdc (Always Apply) ````markdown --- description: Core working agreement for every chat in this repo alwaysApply: true --- # How to work in this project - Stack: {{e.g. Next.js 15 + TypeScript + Supabase}}. Package manager: {{pnpm}}. Never switch it. - Before any change bigger than a one-line fix, write a numbered plan (max 7 steps) and wait for my OK. - Do one step at a time. After each step, run {{pnpm lint && pnpm test}} and fix what breaks before moving on. - Touch only the files the step needs. Don't reformat or rename unrelated code. - Don't add a dependency without asking. Prefer what's already in package.json. - If something is unclear, ask one short question instead of guessing. - Never edit: {{.env*, generated/, applied migrations, lockfiles by hand}}. # Definition of done Before saying a task is done, list each claim (builds, tests pass, bug fixed) and mark it VERIFIED with the exact command and its real output, FAILED, or NOT RUN. Never skip, delete, or weaken a test to make it pass. ```` ### .cursor/rules/frontend.mdc (Apply to Specific Files) ````markdown --- globs: src/app/**/*.tsx, src/components/**/*.tsx alwaysApply: false --- - Reuse existing components in {{src/components/ui/}} before creating new ones. Search first. - Named exports only. One component per file, under ~200 lines; split if it grows. - Style with {{Tailwind}} classes only. No inline style objects, no new CSS files. - Every async UI state needs loading, empty, and error states. - Every form input has a label. Buttons and links must be usable by keyboard. - Don't fetch data in client components if a server component or existing hook can do it. ```` ### .cursor/rules/testing.mdc (Apply to Specific Files) ````markdown --- globs: **/*.test.ts, **/*.test.tsx, tests/** alwaysApply: false --- - Run a single test file with {{pnpm test path/to/file}}; run the full suite before saying done. - When fixing a bug, first write a test that fails because of the bug, then fix the code. - Never use .skip, .only, or delete an assertion to make a suite pass. If a test is wrong, say why and ask. - Test behavior a user would notice, not private implementation details. - Mock network calls at the boundary ({{msw / fetch mock}}), never the code under test. ```` ### .cursor/rules/security.mdc (Apply Intelligently) ````markdown --- description: Use when touching auth, API routes, database queries, env vars, payments, or user input alwaysApply: false --- - Secrets come from environment variables only. Never hard-code keys, never print them, never commit .env. - Every API route checks the user is signed in and allowed to touch that record (no trusting IDs from the client). - Validate all input at the boundary with {{zod}} before using it. - Use parameterized queries or the ORM; never build SQL with string concatenation. - {{Supabase}}: never expose the service-role key to the browser; keep row-level security on. - If a change weakens auth or validation, stop and tell me instead of doing it. ```` ### .cursor/rules/new-feature.mdc (Apply Manually (@new-feature)) ````markdown --- alwaysApply: false --- When I mention @new-feature, follow this workflow: 1. Restate the feature in 2-3 sentences and list what's out of scope. 2. List the files you expect to create or change, and why. 3. Write the numbered plan. Wait for my OK. 4. Build one step at a time, running lint and tests after each. 5. Finish with a short handoff: what changed, how to try it, what's left, and the Definition of done ledger. ```` ## Tips - Start with only 00-core.mdc. Add scoped rules when you see a repeated mistake, not before. - Replace every {{placeholder}} with your real stack and commands. Agents follow commands literally. - Keep always-on rules lean; move anything file-specific into a globs rule so it only loads when needed. - Reference files instead of pasting them: 'follow @src/lib/api-template.ts' keeps rules short and never stale. - Check .cursor/rules/ into git so every teammate and every cloud agent gets the same rules. ## FAQ **Where do Cursor rules go in 2026?** Project rules live in .cursor/rules/ in your repo as .mdc files (subfolders work too). Each file has a small YAML frontmatter block with description, globs, and alwaysApply. A plain .md file in that folder is ignored by the rules system, so use the .mdc extension. If you'd rather use plain markdown, put the same text in AGENTS.md in the project root, which Cursor also reads. **Is .cursorrules still supported?** The single .cursorrules file in the project root is legacy. Cursor's docs say it still works for now but will be deprecated, and recommend moving to .cursor/rules/. To migrate, copy its contents into a new rule like 00-core.mdc with alwaysApply: true (that matches the old behavior), then delete .cursorrules. If both exist, .mdc rules win where they overlap. **What are the four Cursor rule types?** Always Apply (alwaysApply: true) is added to every chat. Apply to Specific Files (globs set, alwaysApply: false) attaches when a matching file is in context. Apply Intelligently (description set, no globs) lets the agent decide from the description. Apply Manually (no description, no globs) is only used when you @-mention the rule, for example @new-feature. **How do I write globs in a .mdc rule?** Put them on one globs: line, comma-separated, for example globs: src/**/*.tsx, tests/**. ** matches any number of folders and * matches one name segment. If alwaysApply is true, globs and description are ignored. **How long should Cursor rules be?** Short and specific. Cursor recommends keeping each rule under 500 lines and splitting big ones into focused files. In practice, a core rule of 15-25 lines plus a few scoped rules beats one giant file, because every always-on line is sent with every request. **Do Cursor rules affect Tab autocomplete?** No. Rules apply to Agent (chat). They don't change Cursor Tab, and User Rules aren't applied to Inline Edit (Cmd/Ctrl+K). **What's the fastest way to improve my rules?** Whenever the agent makes the same mistake twice, add one line to the relevant rule that would have prevented it. You can also type /create-rule in Agent chat and describe what you want; it writes the .mdc file with the right frontmatter. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): six tested Cursor rules files, CLAUDE.md, AGENTS.md and a plan-then-build workflow. Or [all 5 premium packs](https://payhip.com/b/J8eUb) for $29. --- # Claude Code Stop hook: block a fake "done" until your checks pass > A free, dependency-free Python Stop hook for Claude Code that runs the checks you list (tests, lint, build) when the agent finishes and sends it back to work if any fail. The same checks file runs in CI. Source: https://agentpromptsatoz.com/guides/done-gate/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## Install 1. Save as .claude/hooks/done_gate.py (also at https://agentpromptsatoz.com/guides/done-gate/done_gate.py.txt): ````python #!/usr/bin/env python3 """done_gate.py - make "done" a check that exits 0. Two modes, one script, Python 3 standard library only: Hook mode (default): register as a Claude Code Stop hook. It reads the hook JSON from stdin, runs every command listed in .claude/done-checks.txt, and if any fails it exits 2 with the failing output on stderr, which stops Claude from finishing and sends it back to work. CI mode (--ci): run the same checks and exit 1 on the first failure (or on any failure with --all). Use it as the independent final gate. Check file format (.claude/done-checks.txt): one shell command per line. Blank lines and lines starting with # are ignored. Example: npm test npm run lint npm run build Environment: DONE_GATE_FILE path to the checks file (default .claude/done-checks.txt under CLAUDE_PROJECT_DIR or the current directory) DONE_GATE_TIMEOUT per-check timeout in seconds (default 300) """ import json, os, subprocess, sys def project_dir(): return os.environ.get("CLAUDE_PROJECT_DIR") or os.getcwd() def load_checks(path): if not os.path.isfile(path): return None out = [] for line in open(path, encoding="utf-8"): s = line.strip() if s and not s.startswith("#"): out.append(s) return out def run_check(cmd, cwd, timeout): try: p = subprocess.run(cmd, shell=True, cwd=cwd, capture_output=True, text=True, timeout=timeout) text = ((p.stdout or "") + (p.stderr or "")).strip().splitlines() return p.returncode, "\n".join(text[-25:]) except subprocess.TimeoutExpired: return 124, f"TIMED OUT after {timeout}s" def main(argv): ci = "--ci" in argv run_all = "--all" in argv cwd = project_dir() path = os.environ.get("DONE_GATE_FILE") or os.path.join(cwd, ".claude", "done-checks.txt") timeout = int(os.environ.get("DONE_GATE_TIMEOUT", "300")) if not ci: try: data = json.load(sys.stdin) except Exception: data = {} # stop_hook_active is true when Claude is already continuing because of # an earlier block. We still re-run the checks (otherwise one retry # would be enough to escape the gate). Claude Code itself ends the turn # after 8 consecutive stop-hook blocks, so this cannot loop forever. cwd = data.get("cwd") or cwd checks = load_checks(path) if checks is None: if ci: print(f"done_gate: no checks file at {path}", file=sys.stderr) return 1 return 0 # no checks configured: do nothing if not checks: return 0 failures = [] for cmd in checks: code, tail = run_check(cmd, cwd, timeout) status = "PASS" if code == 0 else f"FAIL (exit {code})" if ci: print(f"[{status}] {cmd}") if code != 0: failures.append((cmd, code, tail)) if ci and not run_all: break if not failures: return 0 if ci: for cmd, code, tail in failures: print(f"\n--- {cmd} (exit {code}) ---\n{tail}", file=sys.stderr) return 1 msg = ["NOT DONE. These checks from .claude/done-checks.txt failed. Fix the cause, re-run them, and only then report done. Do not edit, skip or weaken a check to make it pass.\n"] for cmd, code, tail in failures: msg.append(f"$ {cmd}\n(exit {code})\n{tail}\n") print("\n".join(msg), file=sys.stderr) return 2 if __name__ == "__main__": sys.exit(main(sys.argv[1:])) ```` 2. List checks, one shell command per line: ````text # .claude/done-checks.txt (one shell command per line; edit to match your project) npm test npm run lint npm run typecheck npm run build ```` 3. Register in .claude/settings.json: ````json { "hooks": { "Stop": [ { "hooks": [ { "type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/done_gate.py", "timeout": 600 } ] } ] } } ```` 4. CI gate: ````yaml # .github/workflows/done-gate.yml name: done-gate on: [pull_request] jobs: checks: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # add your own setup step here (setup-node, setup-python, install deps) - run: python3 .claude/hooks/done_gate.py --ci --all ```` ## Free kit Get the free Agent Done-Check Kit (Stop hook, rules and CI job) on Payhip, pay what you want from $0: https://payhip.com/b/EAenF ## Limits - Enforces only the commands you list. - Cannot verify claims outside the terminal (deploys, emails): use the auditor prompt in the Agent Done-Check pack and require a read-back. - Stop hooks are a Claude Code feature; checks file and --ci mode work with any agent. - Not run inside a live Claude Code session by us; verify with /hooks and a deliberately failing check. ## FAQ **Why a hook and not just a rule in CLAUDE.md?** A rule asks the agent to check its work; a Stop hook checks it for you. Claude Code runs the Stop hook when the agent finishes responding, and if the hook exits with code 2 the agent is not allowed to stop and gets your stderr as feedback. The agent's own report is never the evidence. Use both: the Definition-of-Done rule makes it try, the hook makes it prove. **Does the agent loop forever if a check can never pass?** No. Claude Code ends the turn after 8 consecutive stop-hook continuations in a row (the count resets each time the agent calls a tool), and you can change that with CLAUDE_CODE_STOP_HOOK_BLOCK_CAP. Per the Claude Code hooks reference, a Stop hook also receives stop_hook_active=true while it is already continuing because of a stop hook. This script deliberately re-runs the checks in that case, so one retry is not enough to slip past it. **What does exit code 2 do on the Stop event?** Per the hooks reference, exit code 2 on a Stop hook prevents Claude from stopping and continues the conversation, and your stderr is shown to Claude as the reason. Any other non-zero code is a non-blocking error, which is why the script uses 2 and not 1. **Can the agent just edit .claude/done-checks.txt to make it pass?** It could, if you let it. Deny edits to the checks file and the script in your permission rules (for example Edit(.claude/done-checks.txt) and Edit(.claude/hooks/**) under permissions.deny; confirm the syntax with /permissions in your version), and keep the CI job as the independent final gate, because CI reads the checks from the merged branch. **Will it slow every turn down?** It runs your checks every time the agent finishes responding, including turns where it only answered a question. Keep the list fast (unit tests, lint, typecheck), put slow suites in CI, and consider a faster subset in done-checks.txt. If a project has no done-checks.txt the script does nothing. **Does it work with Cursor or Codex?** The Stop hook is a Claude Code feature. The checks file and the --ci mode are tool-agnostic, so you can run the same file in CI or as a pre-push step for any agent. For Cursor and Codex, pair the Definition-of-Done rule from the Done-Check pack with the CI job. **Is this tested?** The script was run against its own behavior cases: no checks file, passing checks, a failing check, a check that times out, malformed hook input, stop_hook_active true with a failing and a passing check, and CI mode pass/fail/no-file. It follows the hook input and exit-code behavior documented in the Claude Code hooks reference. It has not been run inside a live Claude Code session by us, so confirm with /hooks and one deliberately failing check on your machine before you rely on it. ## Go further (premium) [App Builder Agent Pack](https://payhip.com/b/EuRgw) ($19): six tested Cursor rules files, CLAUDE.md, AGENTS.md and a plan-then-build workflow. Or [all 5 premium packs](https://payhip.com/b/J8eUb) for $29. --- # Next.js + Supabase + Stripe rules for AI coding agents (free lite kit) > Two scoped Cursor .mdc rules (Supabase RLS and security, Stripe webhooks) plus the 13-point pre-deploy audit checklist. Plain Markdown; also usable as instructions in Claude Code, Codex and other agents. Source: https://agentpromptsatoz.com/guides/nextjs-supabase-stripe-rules/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## Rule 1: Supabase RLS and security (.cursor/rules/10-supabase-rls-security.mdc) ````markdown --- description: Supabase migrations, RLS policies, grants, Postgres functions and the Supabase client globs: supabase/**/*.sql, lib/supabase/**, lib/data/** alwaysApply: false --- # Supabase: RLS and access rules ## Every table in an exposed schema (usually `public`) 1. `alter table ... enable row level security;` in the same migration that creates the table. 2. Set grants explicitly. Policies do not take grants away: `revoke all on table ... from anon, authenticated;` then grant back only what each role needs. 3. Write one policy per operation (select / insert / update / delete). Do not use `for all`. 4. Always name the role with `to authenticated` (or `to anon` only for data that is meant to be public). Never `to anon using (true)` on private data. 5. Wrap helpers: `(select auth.uid()) = user_id`, not `auth.uid() = user_id`. 6. `insert` needs `with check`. `update` needs `using` AND `with check`, plus a `select` policy. 7. Index every column a policy filters on (`user_id`, `team_id`). 8. Add `supabase/tests/_rls.test.sql` (pgTAP) asserting allow and deny for anon and authenticated on each operation. Run `supabase test db`. A table is not done until it passes. ## Do not - Base a policy on `user_metadata` (users can edit it). Use `app_metadata` for authorization data. - Create a view without `with (security_invoker = true)` on Postgres 15+; views otherwise bypass RLS. - Write a `security definer` function without `set search_path = ''` (and schema-qualified names), or put one in an exposed schema. - Use `for all` or `using (true)` to "make the error go away". A `42501` error means check the grants first, then the policy. ## Keys - Browser and per-request server clients use the publishable (anon) key plus the user's session. They are subject to RLS. - The secret / `service_role` key bypasses RLS. It lives only in `lib/supabase/admin.ts` (`import 'server-only'`), is never `NEXT_PUBLIC_`, and is used only after you have checked the caller is allowed to do the thing. Source: https://supabase.com/docs/guides/database/postgres/row-level-security ```` ## Rule 2: Stripe checkout and webhooks (.cursor/rules/20-stripe-webhooks.mdc) ````markdown --- description: Stripe Checkout, webhooks, signature verification and fulfillment globs: app/api/stripe/**, app/api/checkout/**, lib/stripe*.ts alwaysApply: false --- # Stripe: checkout and webhooks ## Webhook route (`app/api/stripe/webhook/route.ts`) - `export const runtime = 'nodejs'`. - Read the RAW body with `await request.text()`. Never `request.json()` before verifying: Stripe signs the exact bytes, and any change to the body breaks verification. - Verify with the official library before doing anything else: `stripe.webhooks.constructEvent(rawBody, request.headers.get('stripe-signature')!, process.env.STRIPE_WEBHOOK_SECRET!)` On failure return 400. Never skip verification "for local testing". Use `stripe listen` (it prints a local `whsec_`). - Do not set the tolerance to 0 (that disables the replay check). Keep the default (5 minutes). - Return a 2xx quickly. Do slow work after the verified event is stored or queued. - Events can arrive twice and out of order. Store `event.id` (unique constraint) and skip ones already processed. Do not rely on event order or on `created`. - Subscribe only to the event types you handle. - Fulfillment (granting access, marking an order paid) happens from the verified webhook, not from the `success_url` page. - Use the service-role/admin Supabase client here (there is no user session), after verification. ## Checkout - Create the session on the server with a Price ID from your own config. Never accept an amount, price or currency from the client. - Put your user id in `client_reference_id` or metadata from the server session, never from request input. - Keep `STRIPE_SECRET_KEY` and `STRIPE_WEBHOOK_SECRET` server-only. Test and live keys differ, and so do their webhook secrets. Source: https://docs.stripe.com/webhooks ```` ## The 13-point pre-deploy audit (checklist) 1. **No secrets in the browser.** No Stripe secret, webhook secret or Supabase secret/service_role key behind a NEXT_PUBLIC_ variable or in a 'use client' file. 2. **Secrets not committed.** .gitignore covers .env*; no .env files or key-looking strings in tracked files. 3. **RLS on every table.** Every table created in an exposed schema has row level security enabled in its migration. 4. **Grants and policy shape.** Explicit revoke-then-grant; no 'for all'; no 'to anon using (true)' on user data; one policy per operation, with a role. 5. **Policy correctness.** insert has with check; update has using and with check; (select auth.uid()); nothing based on user_metadata. 6. **Functions and views.** security definer functions pin search_path and stay out of exposed schemas; views use security_invoker. 7. **Secret client confined.** The secret-key Supabase client is server-only and used only after an auth check or a verified webhook. 8. **Server Actions and route handlers.** Each one checks the user, checks ownership of the specific resource, and validates input. 9. **Stripe webhook verification.** Raw body, signature checked with the endpoint secret before anything else, 400 on failure. 10. **Webhook reliability.** event.id stored and duplicates skipped; no dependence on event order; fulfilment driven by the webhook. 11. **Money and identity from the server.** Price IDs and user ids come from the server, never from the request body. 12. **Tests exist and aren't rigged.** pgTAP allow/deny tests per table; webhook tests for good, bad and duplicate; no .skip or placeholder assertions. 13. **Framework patch level and image safety.** next at 16.4.1+ (16.x) or 15.5.28+ (15.x), sharp 0.35.5+, lockfile committed, no SVG uploads, images.dangerouslyAllowSVG not true, tight images.remotePatterns. Run npm ls next sharp and npm audit yourself. ## Security patching (Oct 2026) Next.js shipped an out-of-band security update on 2026-10-14 (fixed in next@16.4.1 and next@15.5.28): a critical unauthenticated remote code execution in `use cache` functions that return multiple typed arrays (App Router with Cache Components, GHSA-673q-mjm6-r5xr, no known workaround); a critical remote code execution in the Image Optimization API via SVG on glibc-based Linux (CVE-2026-96889 / GHSA-2464-fhr4-w9xw, workaround: sharp 0.35.5 or later; a public proof of concept exists); and a high-severity denial of service in App Router Server Actions (GHSA-p3m5-59mp-jv5r). Sources: [Next.js advisory](https://nextjs.org/blog/nextjs-security-update-october-14-2026), [GHSA-2464-fhr4-w9xw](https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw). 1. Check what you run: `npm ls next sharp` (or `pnpm ls` / `yarn why`). You want next 16.4.1 or later on 16.x, or 15.5.28 or later on 15.x, and sharp 0.35.5 or later. The advisory lists every version from 10.0.0 to 15.5.27 and 16.0.0 to 16.4.0 as affected, and gives no fixed release for 14.x or older. 2. Never downgrade, always lock: do not let an agent downgrade next or sharp to make a build pass. Commit the lockfile and install from it in CI (`npm ci`). Do not use `latest` for next. 3. Audit before every deploy: run `npm audit` before deploying and treat a high or critical advisory in the framework, React or sharp as blocking. Avoid `npm audit fix --force`, which can make major-version jumps. 4. Patch React Server Components and Node.js: React published two advisories on 2026-10-14 (the Next.js post links them as upstream): [GHSA-xqc2-xf4c-x3h3](https://github.com/react/react/security/advisories/GHSA-xqc2-xf4c-x3h3) (critical remote code execution) and [GHSA-h3gv-c5rc-p453](https://github.com/react/react/security/advisories/GHSA-h3gv-c5rc-p453) (high, denial of service). They affect the `react-server-dom-webpack`, `-parcel` and `-turbopack` packages (not `react` or `react-dom`) and are fixed in 19.0.9, 19.1.10, 19.2.9 and 19.3.1; apps whose React code does not run on a server are not affected. For a Next.js App Router app, take the Next.js fix above. Node.js released security fixes on 2026-10-21 (ten CVEs, highest rated HIGH, including a Brotli decoder remote code execution in `node:zlib`, a DNS NUL-byte truncation and TLS hostname-verification bypasses): fixed in 22.23.4 (LTS), 24.22.1 (LTS) and 26.12.1 (Current). Node 20 and older are end-of-life and get no fix. Check `node -v` and also your CI, Dockerfile and host settings. Sources: [Node.js security releases](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases), [Node.js release schedule](https://nodejs.org/en/about/previous-releases). 5. Install hygiene for npm: on 2026-10-08 `tensorlake@0.5.144` was published to npm through a compromised maintainer account (the safe release is 0.5.143): a `preinstall` script stole GitHub and npm tokens, cloud keys, SSH keys and AI-tool configs, and republished itself into other packages. It carried valid npm provenance, so provenance alone does not prove a package is safe ([vendor advisory](https://github.com/tensorlakeai/tensorlake/security/advisories/GHSA-8g63-53c9-65j2), [StepSecurity](https://www.stepsecurity.io/blog/tensorlake-npm-compromised-hostage-token-worm)). Install with `npm ci` from the committed lockfile (it fails if the lockfile and package.json disagree and never rewrites the lockfile: [npm docs](https://docs.npmjs.com/cli/v11/commands/npm-ci)). Use `--ignore-scripts` (or `ignore-scripts=true` in .npmrc) for the first install of a new or unreviewed package or a freshly cloned repo. Tell your agent not to add, upgrade or swap a dependency without asking you, and to show the package's `preinstall`, `install` and `postinstall` scripts (`npm view @ scripts`) and pin new ones to an exact version. 6. If a package looks malicious, do not revoke tokens first: stop and report; do not let the agent revoke, rotate or delete tokens itself. The Tensorlake advisory says the malware installs a `gh-token-monitor` service that deletes the user's home directory if the stolen GitHub token is revoked, so you disconnect the machine and remove that service first, then rotate credentials from a different, clean machine (steps for Linux, macOS and Windows are in the [advisory](https://github.com/tensorlakeai/tensorlake/security/advisories/GHSA-8g63-53c9-65j2); also [Socket](https://socket.dev/blog/tensorlake-compromise)). Also watch for unexpected `.claude/settings.json` or `.vscode/tasks.json` files and commits by a user called claude with the message "chore: update dependencies" that you did not make (StepSecurity). 7. Close the image door: no SVG uploads from users (reject image/svg+xml on the server and in Storage bucket mime types), keep `images.dangerouslyAllowSVG` unset or false, keep `images.remotePatterns` to exact hosts with no wildcards, never pass a user-supplied URL to next/image, and escape any text you put into an SVG or ImageResponse. This is defense in depth, not a substitute for upgrading. The full kit's new rule, `.cursor/rules/40-security-patching.mdc` (plus lines in AGENTS.md and CLAUDE.md and check 13 of the audit, which still covers only next and sharp) makes your agent do these steps, now including the React, Node.js and npm install steps (v1.2, checked against the official pages on 2026-10-23). Honest limits: rules reduce risk, they do not make an app safe or prove you are patched. Version numbers will be superseded, so re-read the official advisory pages. We have not run the exploits, installed any malicious package or tested the rule against a vulnerable app; the gh-token-monitor behaviour is as reported by the vendor advisory and researchers, not tested by us. For context only: PHP also patched two critical remote code execution bugs on 2026-10-21 ([CISA alert](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)); that is a separate ecosystem. ## Did we test it? The webhook rule's code was run under next dev (Next.js 16.4.3, stripe-node 23.0.1) with a stubbed database on 2026-10-23: | | Request | Response | Effect | |---|---|---|---| | T1 | Valid signature, new event | 200 ok | Fulfilled once | | T2 | Wrong signature | 400 Invalid signature | Nothing written | | T3 | No signature header | 400 Missing signature | Nothing written | | T4 | Same event id delivered again | 200 duplicate | Still fulfilled once | | T5 | Valid signature, 1 hour old | 400 Invalid signature | Rejected by the default 5 minute tolerance | | T6 | Control: the flawed route, forged unsigned event | 200 ok | An order was marked paid by a forged request | Not tested: SQL was only syntax-parsed (no Postgres or pgTAP run); nothing run inside Claude Code or Cursor; one machine, one day; not against Stripe's servers. ## FAQ **What is this?** A free sample of our paid Next.js + Supabase + Stripe agent rules kit: two scoped Cursor .mdc rules (Supabase RLS and security, Stripe webhooks) you can drop into .cursor/rules/, plus the headings of the 13-point pre-deploy audit. The same text works as agent instructions in Claude Code, Codex and others, since the .mdc files are plain Markdown. **Does it make my app secure?** No. It makes an AI coding agent much less likely to repeat the classic mistakes: tables without RLS, the service key in the browser, webhooks that don't verify the signature. A human should review anything that handles money or personal data. **What is in the paid $9 kit that isn't here?** The full pack: AGENTS.md, CLAUDE.md (imports AGENTS.md), three more rules (core, testing and security patching), the complete 13-point read-only audit prompt with its PASS/FAIL output format, Claude Code permissions.deny for .env files, a read-only grep helper, two sample apps (one with planted flaws) and VERIFY-LOG.txt with raw output of our test runs. **Where do the rules come from?** From the official docs, linked below: the Next.js data security guide, Supabase's Row Level Security guide and Stripe's webhook docs. Each rule file names its source. Docs change, so re-check them when you upgrade. **How was it tested?** We ran the webhook rule's code under next dev (Next.js 16.4.3, stripe-node 23.0.1) with valid, bad, missing, stale and duplicate signatures (results below). The SQL was only syntax-checked with PostgreSQL's parser; the policies and pgTAP tests were not executed against Postgres, and nothing was tested inside Claude Code or Cursor. The full log ships with the paid kit. ## Go further (paid, $9) AGENTS.md, CLAUDE.md (imports AGENTS.md), 5 scoped .mdc rules (core, Supabase RLS/security, Stripe webhooks, testing, security patching), a 13-point read-only pre-deploy audit prompt (PASS/FAIL with file:line), Claude Code permissions.deny for .env files, a read-only grep helper, two sample apps (one with planted flaws), and VERIFY-LOG.txt with the raw output of what we ran. [Get the full kit: $9](https://payhip.com/b/Pdm5J) ## Sources - [Next.js: data security](https://nextjs.org/docs/app/guides/data-security) - [Supabase: Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) - [Stripe: webhooks](https://docs.stripe.com/webhooks) - [Claude Code: permissions](https://code.claude.com/docs/en/permissions) - [Next.js security update, 2026-10-14](https://nextjs.org/blog/nextjs-security-update-october-14-2026) - [GHSA-2464-fhr4-w9xw (Image Optimization, CVE-2026-96889)](https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw) - [Node.js security releases, 2026-10-21](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) - [React advisory GHSA-xqc2-xf4c-x3h3 (critical RCE, React Server Components)](https://github.com/react/react/security/advisories/GHSA-xqc2-xf4c-x3h3) - [React advisory GHSA-h3gv-c5rc-p453 (DoS, Server Functions)](https://github.com/react/react/security/advisories/GHSA-h3gv-c5rc-p453) - [Tensorlake npm compromise advisory GHSA-8g63-53c9-65j2](https://github.com/tensorlakeai/tensorlake/security/advisories/GHSA-8g63-53c9-65j2) - [StepSecurity: tensorlake npm compromise](https://www.stepsecurity.io/blog/tensorlake-npm-compromised-hostage-token-worm) - [npm docs: npm ci](https://docs.npmjs.com/cli/v11/commands/npm-ci) - [CISA: PHP critical vulnerabilities, 2026-10-21 (context only)](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) --- # Security Watch: a free agent skill that checks your projects for security patches > Read-only. Your AI agent reads your repo, compares versions to a dated table from official advisories and tells you what to update and where the source is. It changes nothing without your OK. Last verified 2026-10-23. Source: https://agentpromptsatoz.com/guides/security-watch/ · License: free to use and adapt · Publisher: Agent Prompts A to Z ## Install ```bash npx skills add https://agentpromptsatoz.com --skill security-watch ``` Skill file: https://agentpromptsatoz.com/agent-skills/security-watch/SKILL.md ## Patched versions (last verified 2026-10-23) | Component | Fixed or safe versions | Affected or bad | Identifier | Source | |---|---|---|---|---| | PHP | 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 8.1 and older: no fix exists, so the project must migrate. | Any PHP older than the fixed release in the same minor line (8.5, 8.4, 8.3, 8.2), and all of 8.1 and older. | CVE-2026-109618, CVE-2026-109619 (a third, CVE-2026-115560, was still awaiting an advisory on the verified date) | [CISA alert, 2026-10-21](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) | | Next.js | 16.4.1 (16.x) or 15.5.28 (15.x). Also sharp 0.35.5 or later. | next >=10.0.0 and <=15.5.27, and 16.0.0 to 16.4.0. | Next.js security update, 2026-10-14 | [Next.js blog, 2026-10-14](https://nextjs.org/blog/nextjs-security-update-october-14-2026) | | React Server Components packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack) | 19.0.9, 19.1.10, 19.2.9, 19.3.1 (match your 19.0 / 19.1 / 19.2 / 19.3 line). | Those packages on an older version in the same line. | GHSA-xqc2-xf4c-x3h3 | [GitHub advisory](https://github.com/react/react/security/advisories/GHSA-xqc2-xf4c-x3h3) | | Node.js | 22.23.4 (22.x), 24.22.1 (24.x), 26.12.1 (26.x). Node 20 and older are end-of-life. | Node older than the fixed release in the 22, 24 or 26 line; any Node 20 or older. | October 2026 security releases | [Node.js blog](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) | | tensorlake (npm) | 0.5.143 is safe. | 0.5.144 is MALICIOUS (credential-stealing install script). | GHSA-8g63-53c9-65j2 | [tensorlake GitHub advisory](https://github.com/tensorlakeai/tensorlake/security/advisories/GHSA-8g63-53c9-65j2) | | litellm (Python) | 1.106.2 is the last clean release. | 1.107.0 is MALICIOUS (PyPI package and several Docker image tags). | LiteLLM incident of 2026-10-21 | [LiteLLM security incident post](https://docs.litellm.ai/blog/security-incident-oct-21-2026) | A third PHP issue, CVE-2026-115560, was still awaiting an advisory on the verified date: https://www.cert.europa.eu/publications/security-advisories/2026-018/ This table is a snapshot. If it is more than 7 days old, check the sources before relying on it. ## What the agent does 1. Checks the freshness date and warns if the table is over 7 days old. 2. Detects the stack from package.json, lockfiles, composer.json, Dockerfile and runtime versions. 3. Compares exact versions and marks each AFFECTED, OK, NOT COVERED or COULD NOT VERIFY. 4. Reports what to update with the source, and what it could not verify. 5. Waits for your OK. It never upgrades or changes anything on its own. ## If a malicious package turns up The agent stops and tells you; it does not rotate or revoke tokens itself. For tensorlake 0.5.144 the vendor says to remove the gh-token-monitor service before revoking any GitHub token, because it can delete your home directory when the token is revoked ([advisory](https://github.com/tensorlakeai/tensorlake/security/advisories/GHSA-8g63-53c9-65j2)). For litellm 1.107.0 the vendor says not to start with pip install in the affected environment ([incident post](https://docs.litellm.ai/blog/security-incident-oct-21-2026)). ## Install hygiene it recommends - `npm ci` for clean and CI installs, with a committed lockfile. - `--ignore-scripts` when installing untrusted packages (some packages need their scripts, so check first). - Exact version pins in Python, and no floating Docker tags like `latest`. ## Honest limits - Read-only, and a snapshot of six items checked against official pages on 2026-10-23. - Not run against real projects in a live test yet. - Not a vulnerability scanner; does not know about anything published after the verified date. - No WordPress, Laravel or other frameworks yet. ## Optional: Next.js kit ($9) The Next.js + Supabase + Stripe Agent Rules Kit adds a security-patching rule and a 13-point pre-deploy audit: https://payhip.com/b/Pdm5J . Free lite version: https://agentpromptsatoz.com/guides/nextjs-supabase-stripe-rules/ . The skill above is free either way. ## FAQ **Does the skill change my project?** No. It reads manifests and lockfiles and reports. It must not upgrade, install, delete, rotate or revoke anything unless you say yes to that specific change. **How current is the table?** It was last verified on 2026-10-23 against the official pages linked below. The skill tells the agent to warn you at the top of its report if that date is more than 7 days old, and to check the sources. **Why won't the agent rotate my tokens after a bad package?** For tensorlake 0.5.144, the vendor says the malware installs a service that can delete the home directory if the stolen GitHub token is revoked, so that service has to be removed first. That is a decision for you, not an agent working alone. **Does a clean report mean I'm secure?** No. It means nothing matched the six items in the table. It is not a vulnerability scanner. **Does it cover WordPress, Laravel or other frameworks?** Not yet. We only list what we verified from official sources. **Has this been tested?** The text and table were checked against the linked sources on 2026-10-23. It has not been run against real projects in a live test, so treat the first run as a trial and read the report critically. ## Sources - [CISA alert, 2026-10-21](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) - [Next.js blog, 2026-10-14](https://nextjs.org/blog/nextjs-security-update-october-14-2026) - [GitHub advisory](https://github.com/react/react/security/advisories/GHSA-xqc2-xf4c-x3h3) - [Node.js blog](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) - [tensorlake GitHub advisory](https://github.com/tensorlakeai/tensorlake/security/advisories/GHSA-8g63-53c9-65j2) - [LiteLLM security incident post](https://docs.litellm.ai/blog/security-incident-oct-21-2026) - [CERT-EU advisory 2026-018 (PHP, third issue)](https://www.cert.europa.eu/publications/security-advisories/2026-018/) --- # Proof: what we tested, and what failed Test date 2026-10-23. 13 real runs across the five paid packs: 8 passed, 3 partly, 2 failed. Failures are left in. - [App Builder Agent Pack](https://agentpromptsatoz.com/proof/app-builder-agent-rules.md) ($19): 3 runs: 2 passed, 1 partly, 0 failed. - [Research Agent Pack](https://agentpromptsatoz.com/proof/research-agent.md) ($9): 2 runs: 1 passed, 0 partly, 1 failed. - [Customer Support Agent Pack](https://agentpromptsatoz.com/proof/customer-support-agent.md) ($9): 3 runs: 1 passed, 1 partly, 1 failed. - [YouTube & TikTok Script Agent Pack](https://agentpromptsatoz.com/proof/video-script-agent.md) ($9): 2 runs: 1 passed, 1 partly, 0 failed. - [Discord Community Manager Pack](https://agentpromptsatoz.com/proof/discord-community-manager.md) (from $3 (pay what you want)): 3 runs: 3 passed, 0 partly, 0 failed. - [All 5 Premium Packs Bundle](https://agentpromptsatoz.com/proof/all-premium-bundle.md) ($29): byte-for-byte contents check ## Method How we tested: for each pack we took the pack's own files (system prompt and the prompt templates), filled in the [BRACKET] placeholders with invented but realistic details (listed under each run), and ran them through a language model with the exact text shown. We saved the raw output and wrote down what held and what didn't. These are single runs on one model. Output varies between runs and between models, and your inputs will differ from ours. Treat this as evidence of what the files can do, not as a guarantee. Model and settings: grok-4.3 (xAI API), temperature 0, one call per run, on 2026-10-23 (America/Louisville time zone). HTML: https://agentpromptsatoz.com/proof/ - https://agentpromptsatoz.com/proof/app-builder-agent-rules.md - https://agentpromptsatoz.com/proof/research-agent.md - https://agentpromptsatoz.com/proof/customer-support-agent.md - https://agentpromptsatoz.com/proof/video-script-agent.md - https://agentpromptsatoz.com/proof/discord-community-manager.md - https://agentpromptsatoz.com/proof/all-premium-bundle.md