13. Mastering the Craft: Advanced Techniques

If you're going to vibe code, do it well. These techniques separate productive vibe coders from frustrated ones.

The Art of the Initial Prompt

The single most important factor in vibe coding success. Spend 30 minutes writing a comprehensive description before generating a single line of code.

Weak vs. Strong Prompts

Key Patterns

  ```

    </div>
  </div>

  <div class="expand-section">
    <button class="expand-header" onclick="this.parentElement.classList.toggle('open')">
      <span class="expand-arrow">&#9654;</span> The Context File Pattern
    </button>
    <div class="expand-body">
      Every serious agent reads a project instruction file — `CLAUDE.md`, `AGENTS.md`, `.cursorrules`. Most vibe coders never write one; the ones who do get a measurably better agent on every single session.

      Minimum viable context file (five sections, ~half a page):

      ```
# Project: [name + one-line purpose]
## Stack: [framework, DB, hosting — so it stops suggesting alternatives]
## Commands: [how to run, test, lint]
## Conventions: [naming, error handling, state patterns it must follow]
## Do NOT touch: [payment code, migrations, auth — without asking]

  Update it when decisions change. A stale context file is worse than none — the agent will confidently follow instructions that are no longer true. Chapter 14 covers keeping it maintained as a daily habit.

</div>

  ```

      This gives you architectural understanding even in a vibe coding workflow. The 2026 agents formalized this: Claude Code's plan mode and Copilot Workspace's spec step are this pattern built into the product — use them. Approving a 20-line plan is cheaper than rejecting a 2,000-line diff.

    </div>
  </div>

  <div class="expand-section">
    <button class="expand-header" onclick="this.parentElement.classList.toggle('open')">
      <span class="expand-arrow">&#9654;</span> The Verification Loop Pattern
    </button>
    <div class="expand-body">
      Don't ask "is it done?" — ask the agent to *prove* it's done. End significant prompts with a verification requirement:

      ```
After implementing, verify your work: run the test suite,
then start the app and confirm the new endpoint returns 200
with valid JSON for the three example inputs above.
Show me the actual output, not a summary.

  Agents that self-verify catch most of their own regressions before you ever see them. "Show me the actual output" matters — it prevents the agent from asserting success it hasn't demonstrated.

</div>

  - **Claude Opus 4.8 (via Claude Code)** — complex reasoning, architecture, large codebases, Dynamic Workflows for parallel agent fleets. 88.6% SWE-bench Verified.

**Good:** "When I click 'Add Task', nothing happens. Console shows: `TypeError: Cannot read property 'push' of undefined at TaskList.addTask (app.js:47)`. This started after I added drag-and-drop."

Include: **action** (what you did), **actual** (what happened), **expected** (what should happen), **error** (verbatim), **context** (what changed recently).

Chapter 17's prompt library has 300+ ready-to-use prompts applying these patterns by project type; the interactive prompt-writing drills are at Vibe Coding Academy, and EndOfCoding publishes new pattern write-ups as the tools evolve.

14. Building a Sustainable Workflow

Pure vibe coding is fast but fragile. The September 2025 "vibe coding hangover" — senior engineers describing AI-generated codebases as "development hell" — wasn't caused by bad models. It was caused by workflows with no sustainability layer: no review gates, no context discipline, no cleanup cadence, no cost controls. The code arrived faster than the understanding did, and eventually the gap collapsed on someone.

This chapter is the sustainability layer. Two parts: the project lifecycle (how a vibe-coded project graduates to production without the hangover) and the daily operating rhythm (the habits that keep a working developer fast for months, not just sprints).

Part 1: The Project Lifecycle

Part 2: The Daily Operating Rhythm

The lifecycle gets a project shipped. These five disciplines keep you sustainable.

1. Context hygiene: maintain your project memory files

Every serious coding agent in 2026 reads a project instruction file — CLAUDE.md, AGENTS.md, .cursorrules, or equivalent. This file is the highest-leverage document in your repository: it's the difference between an agent that knows your conventions, your test commands, and your no-go zones, and an agent that re-derives (or re-invents) them every session.

Keep it current the way you'd keep a README current for a new hire who starts every morning with amnesia:

• Architecture summary — what the major parts are and how they connect
• Commands — how to run, test, lint, and deploy
• Conventions — naming, error handling, state management patterns
• No-go zones — files or systems the agent must not touch without explicit instruction (payment code, migrations, auth)
• Current state — what's in flight, what's blocked, what was recently decided

Stale context files are worse than none: the agent will confidently follow instructions that are no longer true.

2. Token budget discipline

AI tooling is now a real line item. The cautionary tales of mid-2026 are documented in Chapter 21 — Uber exhausted its annual AI budget in about four months at $500–$2,000 per engineer per month; Microsoft pulled an entire division off its preferred agent over run-rate. You don't need enterprise scale to repeat the mistake at personal scale.

Sustainable habits:

• Match autonomy to task value (Chapter 12's rule). Most daily tasks need a focused session, not a fleet of subagents.
• Set a weekly spend check — every major platform now exposes usage dashboards. Look at them on a schedule, not after the invoice.
• Cache and reuse context — repeated long sessions over the same huge codebase burn tokens re-reading. Tight, scoped prompts beat "look at everything and figure it out."
• Know your pricing model — flat-rate subscriptions, usage-based credits, and per-token API billing reward different workflows. Chapter 18's matrix tracks current pricing across tools.

3. The review gate: solve the two-codebases problem

Stack Overflow's 2026 survey found 54% of companies can't tell which parts of their codebase were written by AI. That's the "two codebases problem": one codebase you understand, one you've never actually read, interleaved in the same repository.

The sustainable fix is a hard rule: nothing merges that no human has read. Practical version for solo developers and small teams:

• Review AI diffs before committing, not someday — future-you reviewing three weeks of accumulated agent output is a fiction
• Make the agent explain non-obvious changes in the PR description; read the explanation against the diff
• Keep commits small and topical — a 4,000-line "implemented feature" commit is unreviewable by construction
• Use a second agent as a first-pass reviewer (the orchestration/execution/review split described in Chapter 5's composable stack) — but a second AI's approval is a filter, not a substitute for the human gate on anything yellow-zone or above

4. Skills maintenance: stay the senior in the room

The vibe coding hangover had a human-capital component: developers who stopped reading code for a year discovered their review skills had atrophied exactly when reviewing became their primary job. The role shift is real — from writing code to specifying and evaluating it (Chapter 15 covers the market side) — and evaluation is a skill that decays without use.

Sustainable practice: regularly read and genuinely understand some of what your agents produce — not all of it, but enough that your mental model of your own systems stays live. Periodically write something small by hand. Treat unfamiliar patterns in AI output as free lessons (ask the agent why — the explanations are usually good). Your value in this stack is judgment; judgment needs exposure to stay calibrated.

5. Security cadence, not security heroics

Security in an AI-speed workflow can't be an annual audit — code lands too fast. Chapter 19 is the full playbook; the workflow-level summary is:

• Every session: agent runs with least privilege; no secrets in prompts or context files

• Every merge: dependency check on anything the agent added; secrets scan

• Every week: review your agent configs and MCP servers (the SymJack/TrustFall class of attacks targets exactly these — see Chapter 19)

• Every release: the 30-minute checklist, no exceptions

  ⚠️

  **The compounding rule:** every shortcut in this chapter is invisible for weeks and expensive forever after. Unreviewed code, stale context files, unmonitored spend, and skipped security passes all share the same failure curve — flat, flat, flat, cliff. The teams that avoided the 2025 hangover weren't slower. They were *consistent*.

Vibe code the 80% (UI, boilerplate, standard patterns) at high autonomy.

The video walkthrough of this workflow — including a real project taken through all four phases — is in the Prompt to Product series on YouTube @endofcoding, and Vibe Coding Academy has the interactive version with checkpoints.

15. The Business of Vibes

Vibe coding isn't just changing how software is built. It's changing the economics of software businesses — on both sides of the tools.

By mid-2026 the AI coding category itself is a $4B+ aggregate ARR industry: Claude Code passed $1B ARR within six months of launch, Cognition (Devin) reached a $25B valuation on roughly $480–520M combined ARR, and Cursor, Copilot, and a dozen challengers are fighting a genuine price war (Chapter 9 has the full numbers). That war is the backdrop for every business decision in this chapter — because the cost, capability, and pricing model of your "engineering team" now changes quarterly.

The New Cost Structure

<p style="margin-top:1rem;"><em>This doesn't mean you never need engineers. It means you can validate before investing.</em></p>

That table was already true in 2025. What 2026 added is the fine print: the $20-$500/month figure holds for disciplined usage, and explodes for undisciplined usage. Which brings us to the year's defining business story.

The Cost Reckoning: AI Tooling Becomes a Real Line Item

Two incidents in May 2026 (documented in full in Chapter 21) reset every budget conversation:

• Uber burned through its entire 2026 AI-tools budget in roughly four months after an internal usage leaderboard pushed 84% of its ~5,000 engineers onto agentic coding at $500–$2,000 per engineer per month.
• Microsoft began canceling Claude Code licenses across its Experiences + Devices division — thousands of engineers — over runaway token costs.

The lesson is not "AI coding is too expensive." At $500–$2,000/month, an agent fleet that meaningfully multiplies a $200K engineer is still spectacular ROI. The lesson is that AI engineering spend is now a managed budget category with the same governance as cloud spend circa 2018: per-team visibility, anomaly alerts, and someone who owns the number.

For the business builder, three practical consequences:

• Budget AI tooling as COGS-adjacent, not as a software subscription. It scales with engineering activity, not headcount.
• The pricing-model chess match matters. Mid-2026 offers flat-rate subscriptions, usage-based credits (Copilot's June 1 switch), and per-token API billing — and vendors are repricing quarterly. The right answer depends on your usage shape; re-evaluate every quarter because the market does.
• The below-cost era has a clock on it. OpenAI's $1T IPO filing revealed near-zero gross margins — compute costs consuming revenue. Models priced below cost eventually get repriced. Any business plan that only works at 2026 token prices should know that's a bet, not a constant.

The New Archetypes

The solo builder's real unit economics

The archetype the cost table enables — and the one most readers of this book are closest to — deserves honest math. Build cost collapsing from $300K to $3K doesn't make every idea viable; it changes which ideas are viable:

• Validation is nearly free; distribution is not. When an MVP costs a weekend, the scarce resource shifts entirely to attention — marketing, SEO, community, audience. The skill that gates solo-builder revenue in 2026 is distribution, not development.
• Niches below the venture threshold open up. A product with a $30K/year ceiling was never worth $300K to build. At $3K and a few hours a week of agent-assisted maintenance, it's a fine annuity — and a portfolio of five of them is a living.
• Operating cost discipline decides margins. A vibe-coded product still pays for hosting, APIs, and the agent time that maintains it. The Chapter 14 token-budget habits are, for a portfolio builder, literally margin management.
• Speed cuts both ways. Your moat can't be "it was hard to build" — your competitor's weekend is as productive as yours. Durable advantages are distribution, data, relationships, and taste.

The Talent Shift

The market repriced skills faster than job titles could keep up. Companies are increasingly hiring for:

• Specification specialists — translating business requirements into precise AI prompts and acceptance criteria
• System architects — designing the structure that fleets of AI agents implement
• Security engineers — the human review layer catching what AI misses (demand grew with every incident in Chapter 19)
• AI-fluent developers — working effectively with and reviewing AI-generated code

The data says fluency now correlates with seniority, not youth: JetBrains' 2026 Developer Ecosystem Survey found that among developers with 10+ years of experience, 46% choose Claude Code as their daily driver — the most experienced engineers adopted agentic tooling hardest, because they're best equipped to evaluate its output. The stereotype of AI coding as a junior shortcut inverted: evaluation skill is the scarce input, and evaluation skill is what a decade of reading code builds.

Meanwhile the entry-level question — "if agents do the junior work, where do seniors come from?" — became the industry's open structural debate (Chapter 11 covers it). For the individual, the actionable version is Chapter 14's advice: the skill to invest in is judgment — architecture, security, and code evaluation — because that's the layer the market pays a premium for on every team that adopts agents.

Browse 670+ open AI/LLM positions at LLMHire — the dedicated job board for AI engineers, ML researchers, and prompt engineers. For the builder's path instead of the employment path, the business-of-AI track at Vibe Coding Academy turns this chapter into a step-by-step playbook, and EndOfCoding tracks the economics of the tools market as it moves.

16. What Comes Next

Now (Early 2026) — Already Happening

• AI-native development is the default. 84% of developers use AI tools. The question has shifted from "should we use AI?" to "how do we use it safely?"

• Agent teams are here. Claude Code's agent teams feature lets multiple AI agents work in parallel on different aspects of a project. This is the beginning of true AI-human hybrid teams.

• The open-source crisis. A January 2026 arXiv paper argues vibe coding threatens the open-source ecosystem: users no longer visit docs, file bugs, or engage with maintainers. Tailwind CSS docs traffic down 40%. Stack Overflow questions in structural decline. How maintainers get paid must change.

• Multimodal coding emerges. Voice-driven coding, visual programming interfaces, and screenshot-to-code workflows are entering mainstream tools.

• Consolidation is accelerating. The Windsurf saga — a $3B acquisition attempt, Microsoft blocking, Google poaching, Cognition acquiring — signals a market entering its consolidation phase. Wix acquired Base44 for $80M cash. Anthropic acquired Bun.

• "Agentic engineering" replaces "vibe coding" for professionals. Karpathy himself has moved beyond the term, now advocating for professionals orchestrating AI agents with oversight, not just vibes.

• The IDEsaster wake-up call. 30+ vulnerabilities across every major AI IDE, 24 CVEs, 1.8M developers at risk. AI code is 2.74x more likely to introduce XSS than human code.

• AI reviews AI code. Anthropic launched Code Review (March 9, 2026) — a multi-agent system inside Claude Code that automatically catches logic errors in AI-generated code. The "who reviews the reviewer" problem now has a commercial answer.

• Claude becomes the enterprise default. Anthropic committed $100 million to the Claude Partner Network (March 12–13, 2026), formalizing partnerships with Accenture, Deloitte, Cognizant, and Infosys. Enterprise AI standardization is no longer theoretical.

• Anthropic hits $380B valuation — Claude #1 on App Store. After refusing Pentagon weapons AI contracts, Anthropic became the most disruptive company in the world (TIME, March 2026). Claude overtook ChatGPT as the #1 app on Apple's App Store. The safety-first bet paid off.

• Agent documentation tooling matures. DeepLearning.AI (Andrew Ng's team) released Context Hub (March 9, 2026) — an open-source CLI tool that gives coding agents real-time access to current API docs, bridging the gap between training cutoffs and fast-moving APIs.

  Since Spring — The Mid-2026 Acceleration

  Three months later, several "futures" arrived early:

  • The spring model wave reset the frontier. Opus 4.7 then 4.8, GPT-5.5, Gemini 3.5 Pro/Flash, Cursor Composer 2.5, and Qwen3.7-Max landed within weeks of each other — and the story wasn't just capability, it was price: multiple models hit near-frontier benchmark parity at a tenth of frontier per-token cost (Chapter 18's leaderboard tracks the standings).

• The stack composed instead of consolidating. Rather than one tool winning, Cursor (orchestration), Claude Code (execution), and Codex (review) converged on a shared blueprint teams mix and match — the "composable stack" (Chapter 5). Agent fleets went mainstream: Dynamic Workflows scale to 1,000 concurrent subagents; Jules and Copilot Workspace both went GA.

• The cost reckoning arrived. Uber exhausted its annual AI budget in ~4 months; Microsoft pulled a division off Claude Code over run-rate; Copilot switched to usage-based billing June 1. AI tooling spend became a governed budget category — the prediction that "standardization emerges" came true first in finance, not in code review (Chapter 21 has the full story).

• The trust boundary became the battleground. SymJack and TrustFall showed the approval prompts of seven major agents could be weaponized; Mini Shai-Hulud delivered the first malware carrying valid SLSA build provenance. Supply chain attacks now target the agents themselves (Chapter 19).

• The protocol layer matured. MCP's 2026-07-28 release candidate locked: stateless core, official Apps and Tasks extensions, OAuth-aligned authorization. The plumbing of the agent economy is standardizing fast.

• The man who named the era changed sides of it. Karpathy joined Anthropic's pre-training team in May — using Claude to build the models that power Claude. The recursion is now literal.

  Near-Term (Late 2026) — Scorecard Edition

  Predictions from this chapter's first edition, with status:

  • Security tooling catches up. ✅ Landing. Gemini CLI shipped workspace-trust hardening, Claude Code shipped tool-response sandboxing, Codex shipped permission profiles — security moved into the agent layer itself. Still ahead: making it default-on everywhere.

• Standardization emerges. ✅ Early. MCP RC locked; enterprise governance arrived via budgets and usage-based billing. Formal AI-code governance frameworks still lag — 47% of companies have no policy at all.

• Agent orchestration matures. ✅ Arrived early. Fleets, subagents, plan modes, and goal-driven multi-day runs are shipping features, not demos.

• Open-source funding models evolve. ❌ Still unanswered. The erosion data got worse; no credible funding mechanism has shipped. The most important unsolved problem on this list.

  Medium-Term (2027-2028)

  • Natural language becomes a programming interface. Not replacing code, but a legitimate authoring medium.

• AI-human hybrid teams are standard. Every team includes both human engineers and AI agents with defined roles.

• The maintenance problem gets addressed. AI tools that understand, refactor, and improve AI-generated code.

• Specialized domain models. Finance, healthcare, embedded — each gets domain-specific AI models.

• Pricing finds its floor. The below-cost inference era ends (OpenAI's S-1 margins made the subsidy visible); sustainable per-token economics reshape which workflows are worth automating.

  Long-Term (2029+)

  • Intent-driven development. Describe outcomes, constraints, quality attributes. AI handles the rest.

• Self-healing software. Applications that detect bugs in production and fix themselves.

• The abstraction continues. The role evolves from "code author" to "system designer and quality guardian."

  🔮

  **The fundamental question:** AI will write an increasing share of the world's software. The question isn't whether — it's how we ensure it's secure, reliable, and maintainable. The developers who thrive will master both modes: vibe code a prototype on Saturday, architect a production system on Monday.

  Conclusion

  In sixteen months, vibe coding went from a tweet to a dictionary entry to the defining methodology of a new era in software development. By mid-2026 the numbers leave no room for "fad": **83% of developers use AI tools daily**. The AI coding category clears **$4 billion in aggregate ARR**. Claude Code reached $1B ARR in six months and 1.2M users. Devin passed **$445M ARR** with Cognition valued at **$25B**. Cursor is valued at $29.3B. GitHub Copilot crossed 4.7 million paid users. This is not experimental tooling. This is the new infrastructure of software creation.

  The promise is real and accelerating: agent fleets working in parallel, multi-day autonomous goals, models trading blows at a tenth of last year's cost, and tools so capable that 75% of Replit's AI users write zero code themselves. The barrier between idea and working software has never been lower.

  The challenges sharpened in proportion: the open-source ecosystem still faces its funding question unanswered, supply chain attacks now target the agents themselves, 45% of AI-generated samples still carry OWASP vulnerabilities, and the industry learned — via burned budgets at Uber and Microsoft — that exponential capability bills exponentially too.

  But the answer has become clear. Vibe coding is not a fad to be dismissed or a silver bullet to be worshipped. It is a powerful methodology that belongs in every developer's toolkit. The developers who thrive in 2026 and beyond will be those who master the spectrum — knowing when to vibe code a prototype on Saturday, when to orchestrate a fleet on Monday, and when to insist on human-reviewed engineering for the critical 20%.

  The vibes are real. The exponentials are real. The opportunity is unprecedented.

  Embrace the vibes. Engineer the foundations. Build the future.

Chapter 17: The Complete Prompt Library

230+ production-ready prompts for every stage of AI-native development. Updated monthly.

How to Use This Library

Each prompt is tagged with:

• Difficulty: Beginner / Intermediate / Advanced / Expert
• Tool: Which AI tools it works best with
• Time: Expected completion time
• Category: What type of work it handles

The prompts are designed to be copy-pasted directly. Customize the bracketed [sections] for your specific project.

Category 1: Project Kickoff Prompts

1.1 The Complete Spec Prompt (Expert)

Tool: Claude Code, Cursor Composer | Time: 30-60 min generation

I'm building [product name], a [type of application] for [target audience].

## Product Vision
[One-sentence description of what this product does and why it matters]

## Target Users
- Primary: [who, age range, technical skill level, key pain point]
- Secondary: [who, why they'd use it]

## Core Features (MVP - Priority Order)
1. [Feature 1]: [User story: "As a [user], I want to [action] so that [benefit]"]
2. [Feature 2]: [User story]
3. [Feature 3]: [User story]

## Data Model
- [Entity 1]: [fields and types]
- [Entity 2]: [fields and types]
- Relationships: [Entity 1] has many [Entity 2], etc.

## Design Direction
- Style: [modern/minimal/playful/corporate/brutalist]
- Color palette: [primary hex, accent hex, background]
- Typography: [sans-serif/serif/mono, reference sites]
- Layout: [single page / multi-page / dashboard / wizard]
- Responsive: [mobile-first / desktop-first / both]

## Technical Stack
- Framework: [Next.js / React / Vue / Svelte / vanilla]
- Styling: [Tailwind / CSS Modules / styled-components]
- Database: [Supabase / Firebase / localStorage / Prisma+PostgreSQL]
- Auth: [Supabase Auth / NextAuth / Clerk / none]
- Hosting: [Vercel / Netlify / Railway]

## What Success Looks Like
- A user can [core workflow] in under [N] steps
- The app loads in under [N] seconds
- [Specific measurable outcome]

## What This Is NOT
- Not a [common misunderstanding]
- Don't include [feature to avoid]
- Don't over-engineer [aspect]

Build the complete MVP. Start with the data model, then core layout, then features in priority order.

1.2 The Weekend Prototype Prompt (Beginner)

Tool: Bolt.new, Lovable, Replit Agent | Time: 15-30 min

Build a [type of app] that solves this problem: [describe the pain point in one sentence].

The main user is [who] and they need to:
1. [Core action 1]
2. [Core action 2]
3. [Core action 3]

Design: Clean and modern. Use [color] as the accent color. Dark mode preferred.
Store data in localStorage.
Make it work on mobile.

Keep it simple. I'd rather have 3 features that work perfectly than 10 that are buggy.

1.3 The "Clone This" Prompt (Intermediate)

Tool: Cursor, Claude Code | Time: 1-2 hours

Build a simplified version of [well-known app, e.g., Trello/Notion/Slack].

Include ONLY these features from the original:
1. [Feature to clone]
2. [Feature to clone]
3. [Feature to clone]

DO NOT include: [features to skip]

Match the general layout and UX patterns of the original but use your own design.
Use [tech stack]. Deploy-ready for Vercel.

Focus on making the core interaction feel as smooth as the original.

1.4 The Landing Page Prompt (Beginner)

Tool: v0, Bolt.new | Time: 15-30 min

Create a conversion-optimized landing page for [product name].

Product: [One line description]
Target audience: [Who would buy this]
Price: [Price point or "Free"]

Sections (in order):
1. Hero: Headline "[compelling headline]", subheadline "[supporting text]", CTA button "[button text]"
2. Problem: 3 pain points the audience faces
3. Solution: How the product solves each pain point (with icons or illustrations)
4. Social proof: [testimonials / stats / logos / "As seen in"]
5. Features: 3-6 key features with brief descriptions
6. Pricing: [pricing tiers if applicable]
7. FAQ: 4-5 common questions with answers
8. Final CTA: Repeat the main call-to-action

Design: Professional, trustworthy. Primary color [hex]. Lots of whitespace.
Mobile-responsive. Fast-loading (no heavy images).
Include Open Graph meta tags for social sharing.

Category 2: Feature Addition Prompts

2.1 Authentication System (Advanced)

Tool: Claude Code, Cursor | Time: 1-2 hours

Add a complete authentication system to this [framework] application.

Requirements:
- Email/password signup with email verification
- Login with session management (HTTP-only cookies, not localStorage)
- Password requirements: minimum 8 chars, 1 uppercase, 1 number, 1 special char
- "Forgot password" flow with email reset link (expires in 1 hour)
- "Remember me" option (extends session to 30 days, default is 24 hours)
- Rate limiting: max 5 failed attempts per IP per 15 minutes, then 30-min lockout
- CSRF protection on all auth forms
- Secure headers: HSTS, X-Content-Type-Options, X-Frame-Options

Auth provider: [Supabase Auth / NextAuth / Clerk / custom JWT]

Protected routes: [list routes that require auth]
Public routes: [list routes that don't require auth]

After login, redirect to [dashboard/home/previous page].
Show clear error messages for: wrong password, account not found, account locked, email not verified.

Write tests for: successful login, failed login, signup validation, session expiry, rate limiting.

2.2 Payment Integration (Advanced)

Tool: Claude Code | Time: 2-3 hours

Add [Stripe / Paddle] subscription billing to this application.

Products:
- Free tier: [what's included, usage limits]
- Pro tier: $[price]/month - [what's included]
- [Optional: Enterprise tier: $[price]/month - [what's included]]

Implementation:
1. Pricing page showing all tiers with feature comparison
2. Checkout flow: user selects plan -> [Stripe Checkout / Paddle Overlay] -> redirect to success page
3. Webhook handler for: subscription.created, subscription.updated, subscription.cancelled, invoice.payment_failed
4. User dashboard showing: current plan, next billing date, usage this period, upgrade/downgrade buttons
5. Usage tracking: count [what metric] per billing period, enforce limits on free tier
6. Graceful downgrade: when subscription cancelled, access continues until period end
7. Failed payment handling: 3 retry attempts over 7 days, then downgrade to free

Store subscription status in [Supabase / database].
Add middleware to check subscription status on protected API routes.
Show upgrade prompts when free users hit limits.

Environment variables needed:
- [STRIPE_SECRET_KEY / PADDLE_API_KEY]
- [STRIPE_WEBHOOK_SECRET / PADDLE_WEBHOOK_SECRET]
- [STRIPE_PRO_PRICE_ID / PADDLE_PRO_PRICE_ID]

2.3 Real-Time Features (Advanced)

Tool: Claude Code, Cursor | Time: 2-4 hours

Add real-time [collaboration / notifications / live updates] to this application.

What should update in real-time:
- [Specific data that changes: "new messages", "task status changes", "user presence"]

Technology: [Supabase Realtime / Socket.io / Pusher / Server-Sent Events]

Requirements:
- Changes made by User A appear for User B within [1 second / 500ms]
- Show [typing indicators / presence dots / live cursors] for active users
- Handle disconnection gracefully: show "reconnecting..." banner, auto-reconnect with exponential backoff
- Dedup messages that arrive during reconnection
- Don't poll - use persistent connections
- Fallback to polling if WebSocket connection fails

Optimize for:
- [N] concurrent users per [room / document / channel]
- Messages/updates of approximately [size] bytes each
- Mobile networks with intermittent connectivity

Show connection status indicator (green dot = connected, yellow = reconnecting, red = offline).

2.4 Search and Filter System (Intermediate)

Tool: Any | Time: 30-60 min

Add search and filtering to the [items/products/posts] list in this application.

Search:
- Full-text search across: [field 1], [field 2], [field 3]
- Debounced input (300ms delay before searching)
- Show "X results for 'query'" count
- Highlight matching text in results
- Empty state: "No results for 'query'. Try different keywords."

Filters:
- [Filter 1]: [type: dropdown/checkbox/range] with options [list options]
- [Filter 2]: [type] with options [list options]
- [Filter 3]: [type] with options [list options]
- Date range: from/to date pickers
- Sort by: [option 1 / option 2 / option 3], ascending/descending

Behavior:
- Filters combine with AND logic (search + filter1 + filter2)
- Show active filter count as badge on filter button
- "Clear all filters" button when any filter is active
- URL params reflect current filters (shareable filtered views)
- Persist last-used filters in localStorage

Performance:
- Client-side filtering for under 1000 items
- Server-side (API) filtering for larger datasets
- Show loading skeleton while filtering

Category 3: UI/UX Prompts

3.1 Dashboard Layout (Intermediate)

Tool: v0, Cursor | Time: 30-60 min

Build a dashboard layout for [application type].

Layout:
- Left sidebar: navigation menu (collapsible on mobile, icons + labels)
- Top bar: user avatar + dropdown menu, notification bell with count badge, search bar
- Main content area: responsive grid that adapts from 1 to 3 columns

Sidebar navigation items:
1. [Icon] Dashboard (home)
2. [Icon] [Section 1]
3. [Icon] [Section 2]
4. [Icon] [Section 3]
5. [Icon] Settings
6. [Icon] Help

Dashboard home shows:
- Row 1: 4 stat cards ([Metric 1]: [value], [Metric 2]: [value], etc.)
- Row 2: Main chart (line chart showing [metric] over [time period]) + recent activity feed
- Row 3: Quick actions grid (3-4 action cards with icons)

Design: [light/dark] theme. Accent color: [hex].
Use Tailwind CSS. Smooth transitions on sidebar toggle.
Mobile: sidebar becomes a hamburger drawer overlay.

3.2 Form with Validation (Beginner)

Tool: Any | Time: 15-30 min

Build a multi-step form for [purpose, e.g., "user onboarding", "job application", "event registration"].

Steps:
1. [Step name]: Fields: [field1 (type, required?), field2, field3]
2. [Step name]: Fields: [field4, field5, field6]
3. [Step name]: Review all entered data + submit button

Validation:
- Email: valid format + show error immediately on blur
- Phone: format as (XXX) XXX-XXXX as user types
- Required fields: show red border + error message
- [Custom validation]: [describe rule]

UX:
- Progress indicator showing current step (1/3, 2/3, 3/3)
- "Back" and "Next" buttons (Next disabled until current step is valid)
- "Save as draft" option (localStorage)
- Smooth slide transition between steps
- Auto-focus first field on each step
- Show success animation on submit

Accessible: proper labels, aria attributes, keyboard navigation (Tab through fields, Enter to submit).

3.3 Data Table (Intermediate)

Tool: Any | Time: 30-60 min

Build a data table component for displaying [data type, e.g., "user list", "order history", "inventory"].

Columns:
1. [Column]: [type: text/number/date/status/avatar] - [width: narrow/medium/wide]
2. [Column]: [type] - [width]
3. [Column]: [type] - [width]
4. Actions: Edit, Delete, [custom action]

Features:
- Sort by clicking column headers (asc/desc, show arrow indicator)
- Select rows with checkboxes (select all, bulk actions)
- Inline editing: click cell to edit, Enter to save, Escape to cancel
- Pagination: 10/25/50 per page selector, page numbers, total count
- Responsive: on mobile, switch to card layout (one card per row)
- Empty state: illustration + "No [items] yet. Create your first one."
- Loading state: skeleton rows while data loads

Styling: Clean borders, alternating row colors, hover highlight.
Status column: colored badges (green=active, yellow=pending, red=inactive).

Category 4: API and Backend Prompts

4.1 REST API Scaffold (Advanced)

Tool: Claude Code | Time: 1-2 hours

Build a REST API for [application] with these resources:

Resources:
1. [Resource 1, e.g., "Users"]:
   - Fields: [id, name, email, role, created_at, updated_at]
   - Endpoints: GET /api/users, GET /api/users/:id, POST /api/users, PUT /api/users/:id, DELETE /api/users/:id

2. [Resource 2]:
   - Fields: [list fields]
   - Endpoints: [list CRUD endpoints]
   - Relationships: [belongs_to Resource1, has_many Resource3]

Response format (all endpoints):
Success: { data: {...}, meta: { page, limit, total } }
Error: { error: { code: "VALIDATION_ERROR", message: "Email is required", details: [...] } }

Requirements:
- Input validation with descriptive error messages
- Pagination: ?page=1&limit=20 (default limit=20, max=100)
- Filtering: ?status=active&role=admin
- Sorting: ?sort=created_at&order=desc
- Rate limiting: 100 requests per minute per IP
- CORS configured for [allowed origins]
- Request logging (method, path, status, duration)

Auth: Bearer token in Authorization header.
- Public endpoints: [list]
- Authenticated endpoints: [list]
- Admin-only endpoints: [list]

Framework: [Next.js API routes / Express / Fastify / Hono]
Database: [Supabase / Prisma / Drizzle]

4.2 Database Schema Design (Advanced)

Tool: Claude Code | Time: 30-60 min

Design a database schema for [application type].

Entities:
1. [Entity 1]: [description of what it represents]
   - Required fields: [list]
   - Optional fields: [list]
   - Unique constraints: [list]

2. [Entity 2]: [description]
   - Fields: [list]
   - References: [Entity 1] (one-to-many / many-to-many)

Business rules:
- [Rule 1, e.g., "A user can only have one active subscription"]
- [Rule 2, e.g., "Orders must have at least one line item"]
- [Rule 3, e.g., "Soft delete for users, hard delete for sessions"]

Generate:
1. SQL migration file with CREATE TABLE statements
2. Indexes for common query patterns: [list queries, e.g., "find users by email", "get orders by date range"]
3. Row-level security policies (if Supabase)
4. Seed data: 10-20 realistic sample records per table
5. TypeScript types matching the schema

Optimize for: [read-heavy / write-heavy / balanced]
Database: [PostgreSQL / MySQL / SQLite]

Category 5: Testing and Quality Prompts

5.1 Comprehensive Test Suite (Advanced)

Tool: Claude Code | Time: 2-4 hours

Write a comprehensive test suite for this [application/module].

Testing framework: [Vitest / Jest / Playwright / Cypress]

Coverage targets:
- Unit tests: all utility functions and business logic (aim for 90%+)
- Integration tests: all API endpoints (happy path + error cases)
- Component tests: all interactive components (user events + state changes)
- E2E tests: [list 3-5 critical user flows]

For each test, include:
- Clear descriptive name: "should [expected behavior] when [condition]"
- Arrange-Act-Assert structure
- Realistic test data (not "test123" or "foo bar")
- Error case coverage (invalid input, timeout, auth failure)
- Edge cases ([list specific edge cases for this app])

Mock strategy:
- External APIs: mock with [MSW / jest.mock / vi.mock]
- Database: use [test database / in-memory / fixtures]
- Time-dependent tests: mock Date.now()
- File system: use temp directories

Run the complete suite after writing. Fix any failures.
Generate a coverage report.

5.2 Security Audit Prompt (Expert)

Tool: Claude Code | Time: 1-2 hours

Perform a security audit of this codebase. Check for:

1. Authentication & Authorization:
   - Are passwords hashed with bcrypt/argon2 (not MD5/SHA)?
   - Are sessions stored securely (HTTP-only cookies, not localStorage)?
   - Is CSRF protection implemented on state-changing requests?
   - Are API keys and secrets in environment variables (not hardcoded)?
   - Are authorization checks on every protected endpoint (not just frontend)?

2. Input Validation:
   - Is all user input validated server-side (not just client-side)?
   - Are SQL queries parameterized (no string concatenation)?
   - Is HTML output sanitized to prevent XSS?
   - Are file uploads validated (type, size, name)?
   - Are URL redirects validated against an allowlist?

3. Data Protection:
   - Is sensitive data encrypted at rest?
   - Is HTTPS enforced (HSTS headers)?
   - Are API responses filtered (no password hashes, internal IDs leaking)?
   - Is PII handled according to GDPR/CCPA requirements?
   - Are error messages generic (no stack traces to users)?

4. Infrastructure:
   - Are dependencies up to date (no known CVEs)?
   - Are security headers set (CSP, X-Frame-Options, etc.)?
   - Is rate limiting configured on auth and API endpoints?
   - Are CORS origins restricted (not "*")?
   - Are logs sanitized (no passwords or tokens in logs)?

For each issue found:
- Severity: Critical / High / Medium / Low
- Location: file path and line number
- Description: what's wrong and why it matters
- Fix: specific code change to resolve it
- Test: how to verify the fix works

Prioritize fixes by severity. Implement Critical and High fixes immediately.

Category 6: Refactoring and Optimization Prompts

6.1 Performance Optimization (Advanced)

Tool: Claude Code | Time: 1-2 hours

This application is slow. Analyze and optimize performance.

Symptoms:
- [Specific symptom: "initial page load takes 4+ seconds"]
- [Specific symptom: "scrolling is janky with 500+ items"]
- [Specific symptom: "API response takes 2+ seconds"]

Investigate and fix:
1. Bundle size: analyze with [next/bundle-analyzer or similar], remove unused dependencies, implement code splitting
2. Rendering: identify unnecessary re-renders, add React.memo/useMemo/useCallback where appropriate
3. Data fetching: implement caching, pagination, reduce payload sizes
4. Images: lazy load below-fold images, use next/image or responsive srcset, serve WebP
5. Database: add missing indexes, optimize N+1 queries, implement connection pooling
6. Network: enable gzip/brotli, set proper cache headers, minimize HTTP requests

For each optimization:
- Before: [metric measurement]
- After: [expected improvement]
- Method: [specific code change]

Run Lighthouse audit before and after. Target scores: Performance >90, Accessibility >95.

6.2 Code Cleanup (Intermediate)

Tool: Claude Code, Cursor | Time: 1-2 hours

Clean up this codebase without changing any functionality.

Tasks:
1. Remove dead code: unused imports, unreachable functions, commented-out blocks
2. Consolidate duplicated logic: find similar code patterns and extract shared utilities
3. Fix naming: rename variables/functions that don't describe their purpose
4. Organize file structure: group related files, consistent naming conventions
5. Add TypeScript types: replace 'any' with proper types, add interfaces for data shapes
6. Fix linting issues: run [ESLint / Prettier] and fix all warnings/errors
7. Update dependencies: check for outdated packages, update non-breaking versions
8. Add JSDoc comments to exported functions (not internal helpers)

Rules:
- Make small, focused commits (one type of change per commit)
- Run tests after each change to ensure nothing breaks
- Don't refactor code that has pending changes or open PRs
- Keep the diff readable: don't auto-format unrelated files

Category 7: Deployment and DevOps Prompts

7.1 Production Deployment Checklist (Advanced)

Tool: Claude Code | Time: 1-2 hours

Prepare this application for production deployment on [Vercel / AWS / Railway].

Pre-deployment checklist:
1. Environment variables: create .env.example with all required vars (no values), verify all are set in [hosting platform]
2. Error tracking: set up [Sentry / LogRocket / Bugsnag] for runtime error monitoring
3. Analytics: add [Vercel Analytics / Google Analytics / Plausible] for usage tracking
4. SEO: verify meta tags, Open Graph, Twitter cards, sitemap.xml, robots.txt
5. Performance: run Lighthouse, fix any scores below 80
6. Security: run npm audit, fix critical/high vulnerabilities, verify security headers
7. Database: verify connection pooling, set up backups if applicable
8. Caching: configure CDN caching headers, implement stale-while-revalidate for API routes
9. Monitoring: set up uptime monitoring (e.g., UptimeRobot, Checkly)
10. Domain: configure custom domain, SSL, www redirect

Create a deployment script or CI/CD pipeline that:
- Runs tests
- Runs linter
- Builds the application
- Deploys to [platform]
- Runs smoke tests against the deployed URL
- Notifies [Slack / Discord / email] on success/failure

Category 8: AI Agent Orchestration Prompts (Expert)

8.1 Multi-Agent Task Decomposition

Tool: Claude Code (subagents) | Time: 2-4 hours

I need to [describe large task, e.g., "add a complete user profile system with settings, avatar upload, activity history, and notification preferences"].

Decompose this into subtasks that can be worked on in parallel:

1. Data layer: schema changes, migrations, API endpoints
2. UI components: form components, display components, layouts
3. Business logic: validation rules, permission checks, notification triggers
4. Tests: unit tests, integration tests, E2E tests

For each subtask:
- Define the interface/contract (inputs, outputs, data shapes)
- List dependencies on other subtasks
- Identify which can run in parallel vs. must be sequential

Then implement each subtask, integrating them at the defined interfaces.
Run the full test suite after integration to catch any contract mismatches.

8.2 Codebase Analysis and Improvement Plan

Tool: Claude Code | Time: 1-2 hours

Analyze this entire codebase and create an improvement plan.

Evaluate:
1. Architecture: Is the structure scalable? Are concerns properly separated?
2. Code quality: Consistency, readability, duplication, complexity (cyclomatic)
3. Error handling: Are errors caught, logged, and presented well?
4. Testing: Coverage, quality of tests, missing edge cases
5. Security: Common vulnerabilities (OWASP Top 10 applicable ones)
6. Performance: Obvious bottlenecks, missing optimizations
7. Developer experience: Build time, hot reload, debugging ease

Output:
- Score each category 1-10 with specific evidence
- Top 5 improvements ranked by impact/effort ratio
- Specific action items for each improvement
- Estimated time for each action item

Don't fix anything yet. Just analyze and plan.

Category 9: Content and Data Prompts

9.1 Seed Data Generator (Beginner)

Tool: Any | Time: 15-30 min

Generate realistic seed data for this application.

Data needed:
- [N] [entity type, e.g., "users"] with: [fields]
- [N] [entity type, e.g., "products"] with: [fields]
- [N] [entity type, e.g., "orders"] with: [fields]

Rules:
- Use realistic names (not "Test User 1")
- Dates spread across the last [time period]
- Prices/amounts in realistic ranges for [industry]
- Status distribution: [e.g., "60% active, 30% pending, 10% cancelled"]
- Include edge cases: [e.g., "one user with no orders, one product with 0 stock"]
- Relationships should be consistent (orders reference real user IDs and product IDs)

Output format: [JSON / SQL INSERT statements / TypeScript constants / CSV]

9.2 API Documentation Generator (Intermediate)

Tool: Claude Code | Time: 30-60 min

Generate comprehensive API documentation for all endpoints in this application.

For each endpoint, document:
- Method and path (e.g., GET /api/users/:id)
- Description (one sentence)
- Authentication required? (yes/no, what type)
- Request: headers, query params, body schema with types and validation rules
- Response: status codes, body schema for success and each error case
- Example request (curl command)
- Example response (JSON)

Format: [Markdown / OpenAPI 3.0 spec / Swagger]
Include a table of contents.
Group endpoints by resource.
Add rate limiting info if applicable.

Category 10: Platform-Specific Prompts

10.1 Chrome Extension (Advanced)

Tool: Claude Code | Time: 2-4 hours

Build a Chrome Extension (Manifest V3) that [core functionality].

Features:
- Popup: [describe popup UI and what it shows]
- Content script: [what it does on web pages, e.g., "highlights [elements]"]
- Background service worker: [what it handles, e.g., "API calls, storage sync"]
- Options page: [settings the user can configure]

Permissions needed: [activeTab, storage, tabs, etc. - minimize permissions]

Storage:
- Use chrome.storage.sync for: [settings that sync across devices]
- Use chrome.storage.local for: [data that stays local]

Communication:
- Content script <-> Background: chrome.runtime.sendMessage
- Popup <-> Background: direct access to chrome.storage

Include:
- manifest.json with all required fields
- Icon set (16x16, 48x48, 128x128) - use simple colored SVG converted to PNG
- README with installation instructions (load unpacked)
- Privacy policy text (required for Chrome Web Store submission)

Test on these sites: [list 3-5 target websites]

10.2 CLI Tool (Intermediate)

Tool: Claude Code | Time: 1-2 hours

Build a command-line tool in [Node.js / Python / Go / Rust] that [core functionality].

Commands:
- [tool] init: [what it sets up]
- [tool] [command 1] [args]: [what it does]
- [tool] [command 2] [args]: [what it does]
- [tool] --help: show all commands with descriptions

Features:
- Colored output (green for success, red for errors, yellow for warnings)
- Progress bars for long operations
- Interactive prompts for required input (with defaults)
- Config file (~/.toolrc or .toolrc in project root)
- --verbose flag for debug output
- --json flag for machine-readable output
- Meaningful exit codes (0 success, 1 error, 2 usage error)

Error handling:
- Clear error messages with suggested fixes
- Never show stack traces (unless --verbose)
- Graceful handling of Ctrl+C

Package for distribution via [npm / pip / brew / cargo].
Include README with installation, usage examples, and config reference.

Prompt Patterns Reference Card

The Constraint Sandwich

Do [action].
Include: [must-have list]
Do NOT include: [exclusion list]
Match existing: [patterns/styles to follow]

The Iterative Refinement

[After seeing initial output]
Keep: [what works]
Change: [what needs to change]
Add: [what's missing]
Remove: [what's unnecessary]
Don't touch: [what shouldn't change]

The Context Dump

Here's the current state:
- File: [path] does [function]
- File: [path] does [function]
- The bug is in: [location]
- Error message: [exact text]
- This worked before I: [recent change]
- I've already tried: [attempts]
Fix the bug without changing [protected areas].

The Scope Lock

ONLY modify [specific files/functions].
Do NOT touch: [protected files]
Do NOT change: [protected behavior]
Do NOT add: [unwanted additions]
Keep the diff as small as possible.

The Quality Gate

Before considering this done:
1. All existing tests pass
2. New tests cover: [specific scenarios]
3. No TypeScript errors (strict mode)
4. No ESLint warnings
5. Lighthouse performance score > [N]
6. [Custom quality criterion]

March 2026 Additions: Autonomous Mode Prompts

New prompts for Claude Code Auto Mode, MCP workflows, and agentic build patterns.

The Auto Mode Task Brief (Expert)

Tool: Claude Code (Auto Mode enabled) | Time: Runs unattended 15-120 min

Use this when handing a scoped task to Claude Code in Auto Mode. The structure defines scope, acceptance criteria, and what Claude should NOT touch — so the autonomous run has clear boundaries.

# Task: [Brief title]

## Scope
Working directory: [path]
Files allowed to modify: [list or glob pattern]
Files that must NOT change: [list — tests, migrations, config, etc.]

## Objective
[One sentence: what should be different when you're done]

## Acceptance Criteria
- [ ] [Specific, testable outcome 1]
- [ ] [Specific, testable outcome 2]
- [ ] All existing tests still pass
- [ ] No TypeScript errors (strict)
- [ ] No new ESLint warnings

## What This Is NOT
- Do not refactor unrelated code
- Do not add features beyond the objective
- Do not modify [specific protected area]

## Summary at End
When complete, write a brief summary of:
1. Every file changed and why
2. Any decisions you made and the tradeoff
3. Anything you're uncertain about
4. Tests I should run to verify

Why it works: The summary request at the end transforms Auto Mode from "black box" to "async colleague" — you wake up to a log of decisions, not just a diff.

The Claude Code Channels Handoff (Advanced)

Tool: Claude Code + Channels (Telegram/Discord integration) | Time: N/A — async coordination

Claude Code Channels (March 2026) lets you send instructions to a running Claude Code session from your phone. Use this prompt structure to create async checkpoints that Claude will pause for:

## Background Task with Mobile Checkpoints

Start the following task: [task description]

## Checkpoint Rules
Pause and send me a Telegram message at these points:
1. After completing the initial analysis — summarize what you found
2. Before any destructive action (delete, drop, overwrite) — describe it and wait
3. If you hit a blocker you can't resolve — describe the issue
4. When complete — summary of all changes

## Proceed autonomously between checkpoints.
Do not pause for routine read/write/test operations.

Why it works: You define the decision points where human judgment matters, and let Claude handle the execution in between. Run overnight builds and get Telegram pings when action is needed.

The Security Scope Guard (Advanced)

Tool: Claude Code (any mode) | Time: Prepend to any task involving auth, payments, or data

Add this as a preamble whenever Claude Code will touch security-sensitive code. It activates extra caution without requiring manual review of every action:

## Security Scope Guard — Activate Before This Task

This task involves security-sensitive code: [auth / payments / user data / API keys]

Before every change to [auth / payment / data] files:
1. State what vulnerability pattern you are avoiding
2. Confirm input validation is present
3. Confirm secrets are not hardcoded
4. Confirm error messages don't leak internal state

Never:
- Log authentication tokens or session IDs
- Return detailed error messages to the client
- Use string concatenation in SQL queries
- Disable CORS for any reason
- Store credentials in localStorage

If you see existing code that violates the above: flag it in your summary, do not silently fix it (I need to know it existed).

Now proceed with: [actual task]

Why it works: Security reviews after the fact miss context. This prompt embeds security review into the generation loop — Claude checks each change against the rules as it writes, not after.

Category 26: MCP Integration Prompts (Added March 2026)

Model Context Protocol (MCP) is now the standard way to give AI coding assistants persistent context and tool access. These prompts help you integrate MCP correctly.

26.1 MCP Server Setup Prompt (Intermediate)

Tool: Claude Code | Time: 30-60 min

Set up an MCP (Model Context Protocol) server for my project that exposes the following tools to AI assistants:

## Tools to Expose
1. [Tool 1 name]: [what it does — e.g., "read_project_data: reads the projects.json registry"]
2. [Tool 2 name]: [what it does — e.g., "run_health_check: pings all deployment URLs"]
3. [Tool 3 name]: [what it does — e.g., "get_recent_errors: reads the last 50 error log lines"]

## Implementation Requirements
- Use the @modelcontextprotocol/sdk package
- Implement as stdio transport (not HTTP) for local use
- Each tool must have a clear JSON schema for inputs
- Each tool must return structured JSON output
- Add error handling that returns helpful error messages, not stack traces
- Include a test script that exercises each tool

## Configuration
Generate the MCP configuration block for claude_desktop_config.json:
{
  "mcpServers": {
    "[server-name]": {
      "command": "node",
      "args": ["path/to/server.js"]
    }
  }
}

## Context This Will Enable
When this MCP server is active, an AI assistant will be able to [describe what new capabilities this enables for your workflow].

Build the complete MCP server. Start with the tool definitions, then the handlers, then the test script.

26.2 Claude Code MCP Context Prompt (Advanced)

Tool: Claude Code | Time: 15 min

I'm setting up a project-level MCP context file so Claude Code has persistent context about my project without me having to re-explain it every session.

Create a CLAUDE.md file that covers:

## Project Identity
- Name: [project name]
- Purpose: [one sentence]
- Stack: [tech stack]
- Current status: [active development / maintenance / paused]

## Key Files and Their Purpose
- [file path]: [what it contains and when to read it]
- [file path]: [what it contains and when to read it]

## Commands
- Build: [command]
- Dev server: [command]
- Test: [command]
- Deploy: [command]

## Architecture Decisions That Are NOT Up for Discussion
- [Decision 1]: [why it was made — do not suggest alternatives]
- [Decision 2]: [why it was made]

## Known Issues (Don't Re-Investigate)
- [Issue 1]: [known limitation, not a bug to fix]

## My Workflow
- I prefer [file-by-file / whole-feature] implementations
- Always [run tests / lint / build] before marking a task done
- When in doubt, [ask / make conservative choice / make opinionated choice]

Make the CLAUDE.md scannable and under 200 lines.

26.3 Next.js Secure Middleware Pattern (Intermediate) (Security-critical — post-CVE-2025-29927)

Tool: Claude Code, Cursor | Time: 20 min

Add authentication to my Next.js app using the secure dual-layer pattern (required post-CVE-2025-29927).

## Protected Routes
- /dashboard/:path* — requires authenticated user
- /api/protected/:path* — requires authenticated user, returns 401 JSON (not redirect)
- /admin/:path* — requires authenticated user with admin role

## Auth Provider
I'm using: [NextAuth v5 / Supabase Auth / Clerk / custom JWT]

## Implementation Rules
1. Middleware ONLY for UX redirects (fast redirect to /login for protected pages)
2. Every /api/protected route MUST verify the session server-side independently
3. NEVER rely on middleware as the sole auth gate for API routes
4. Include the x-middleware-subrequest header strip check as a comment

## Pattern to Implement
For each protected API route:
\`\`\`typescript
// DO NOT rely on middleware alone — verify here
const session = await getServerSession(authOptions)
if (!session) {
  return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
}
\`\`\`

Generate:
1. middleware.ts with the correct matcher config and a comment explaining it is NOT a security boundary
2. A shared auth utility function (lib/auth-guard.ts) that API routes can call
3. One example protected API route using the utility
4. A test that verifies the API route returns 401 when no session exists

Category 27: Multi-Agent Orchestration Prompts (Cursor 3 / Claude Code Teams)

Added April 7, 2026 — covering the new parallel multi-agent workflows enabled by Cursor 3's Agents Window and Claude Code's Teams feature.

27.1 The Agent Task Decomposer (Advanced)

Tool: Cursor 3 Agents Window, Claude Code | Time: 5 min setup → autonomous execution

Use this prompt to break a large feature into parallelizable agent tasks before opening the Agents Window.

I need to implement [feature name] in my [type of app].

Decompose this into parallel agent tasks using this format:
- Each task must be completable in under 30 minutes
- Tasks must have clear success criteria (how to verify it's done)
- Identify dependencies (which tasks must complete before others can start)
- Assign a suggested agent focus for each (e.g., "backend agent", "test agent", "UI agent")

Feature to decompose:
[Describe the feature in 3-5 sentences. Include: what it does, the data it uses, and any API/external integrations.]

Output format:
## Agent Task Plan
### Wave 1 (parallel, no dependencies)
- Task A [Agent role]: [Goal] | Success: [How to verify] | Files: [which files/modules]
- Task B [Agent role]: [Goal] | Success: [How to verify] | Files: [which files/modules]

### Wave 2 (depends on Wave 1)
- Task C [Agent role]: [Goal] | Success: [How to verify] | Depends on: [Task A output]

27.2 The Single Agent Task Charter (Intermediate)

Tool: Cursor 3 Agents Window, Claude Code | Time: 2 min per agent

Paste this into each individual agent in the Agents Window to give it a focused, well-bounded mission.

## Agent Charter

**Role**: [Backend Engineer / Frontend Developer / QA Engineer / Security Reviewer / Docs Writer]
**Mission**: [One sentence: what this agent will produce]
**Scope**: [Specific files, modules, or directories this agent is allowed to touch]
**Off-limits**: [Files/systems this agent must not modify]

**Success Criteria** (all must be true when you're done):
1. [Specific, verifiable outcome]
2. [Specific, verifiable outcome]
3. Tests pass: [which test command to run]

**Handoff**: When complete, write a summary to `agent-handoff-[role].md` covering:
- What you built
- Any decisions you made and why
- What the next agent needs to know
- Any concerns or edge cases you noticed

**Context**: [Brief description of the larger feature this fits into]

Do not interrupt me unless you are truly blocked. Make reasonable decisions independently.

27.3 The Multi-Agent Review Prompt (Advanced)

Tool: Cursor 3 Agents Window, Claude Code | Time: 10-15 min supervised execution

Use this to spin up a dedicated review agent that audits another agent's output before you merge it.

## Review Agent Mission

You are a senior code reviewer. You did NOT write the code you are reviewing.

**Author agent**: [which agent produced this code, e.g., "Backend Agent — implemented the payment webhook handler"]
**Files to review**: [list the files]
**Success criteria of the original task**: [paste the success criteria from the original agent's charter]

Your review checklist:
1. **Correctness**: Does the code do what the task charter required?
2. **Edge cases**: What inputs could break this? (empty arrays, null values, concurrent requests, network failures)
3. **Security**: Any injection risks, missing auth checks, exposed secrets, or unvalidated inputs?
4. **Performance**: Any N+1 queries, missing indexes, synchronous blocking calls, or memory leaks?
5. **Tests**: Are the tests meaningful? Do they cover the stated success criteria?
6. **Handoff quality**: Is the agent-handoff file accurate and useful for downstream agents?

Output a structured review:
## Review Summary
**Overall verdict**: APPROVE / REQUEST_CHANGES / BLOCK
**Confidence**: High / Medium / Low

### Issues Found
| Severity | File | Line | Issue | Suggested Fix |
|----------|------|------|-------|---------------|
| CRITICAL | ... | ... | ... | ... |

### Approved Items
[What the agent did well — be specific]

### Required Changes Before Merge
[Numbered list if verdict is REQUEST_CHANGES or BLOCK]

Category 28: Long-Horizon Agentic Execution (April 2026)

For GLM-5.1, Claude Code, Cursor Automations, and any AI agent running 2+ hour autonomous sessions. These prompts help you structure work that outlasts your attention span.

28.1 The Long-Horizon Task Brief (Advanced)

Tool: GLM-5.1, Claude Code, Cursor Automations | Time: 30 min setup → hours of autonomous execution

Use this before starting any AI session you expect to run longer than 30 minutes. A clear brief prevents the model from drifting, making scope-creep decisions, or silently failing.

## Long-Horizon Task Brief

**Session goal** (one sentence):
[What is complete when this session ends?]

**Time budget**: [How many hours should the agent spend before stopping to check in?]

**In scope**:
- [Feature/file/system 1]
- [Feature/file/system 2]

**Out of scope** (hard limits):
- Do NOT modify [file/system] — read-only
- Do NOT delete anything — create new files only
- Do NOT push to main — commit to branch only

**Checkpointing** (every N hours):
Write a checkpoint file at `agent-checkpoint-[timestamp].md` containing:
1. What has been completed
2. Current task in progress
3. Known blockers or unresolved decisions
4. What remains to complete the session goal

**Success criteria** (all must be true at session end):
1. [Verifiable outcome — test command, file exists, URL responds, etc.]
2. [Verifiable outcome]
3. All code compiles with zero TypeScript errors (`npm run build`)
4. All existing tests still pass (`npm test`)

**How to handle blockers**:
- If blocked by a missing env var → note it in the checkpoint file and skip that feature
- If blocked by an ambiguous requirement → make a reasonable assumption, document it in the checkpoint, and continue
- If blocked by a breaking error → stop, write a blocker-report.md, and halt the session

Begin with a brief plan (3-5 bullet points), then execute.

28.2 The Open-Weight Model Selection Prompt (Intermediate)

Tool: Any LLM with web access or knowledge cutoff April 2026 | Time: 5 min

Use this when evaluating whether to use a self-hosted open-weight model vs. a closed API for a specific project.

I need to choose between a self-hosted open-weight model and a closed API for the following use case:

**Use case**: [Describe what the AI will be doing — code completion, autonomous agents, document analysis, etc.]

**Constraints**:
- Data sensitivity: [Public / Internal / Confidential / Regulated (HIPAA, SOC2, etc.)]
- Budget: [Monthly cap in USD, or "no limit"]
- Latency requirement: [< 500ms / < 2s / batch OK]
- Infrastructure: [Consumer hardware / cloud GPU / on-prem enterprise cluster]
- Team size: [Solo / small team / enterprise]
- Vendor lock-in tolerance: [Low / Medium / High]

**Open-weight models to evaluate** (as of April 2026):
- GLM-5.1 (754B, Z.AI) — SOTA SWE-Bench Pro, 8-hour autonomous sessions, Apache 2.0
- Gemma 4 (Google, Apache 2.0) — 4 sizes, strong reasoning and coding
- Llama 3.x (Meta) — broad ecosystem, widely deployed
- Qwen3.6-Plus — 1M context, competitive with Claude 4.5 on coding tasks

**Closed APIs to evaluate**:
- Claude Sonnet 4.6 (Anthropic API) — best agentic coding, $3/$15 per MTok
- GPT-4o (OpenAI) — broad capability, strong ecosystem
- Gemini 1.5 Pro (Google) — 1M context, competitive pricing

For each candidate, evaluate:
1. Does it meet my latency requirement?
2. Does it meet my data sensitivity requirement?
3. What is the estimated monthly cost at my usage level?
4. What are the known failure modes for my use case?

Recommend the best option and explain the trade-offs I'm accepting.

28.3 The Goose/Local-Agent Workflow Prompt (Intermediate)

Tool: Goose (Block), any LLM-agnostic local AI agent | Time: 10 min setup

Goose (launched April 2026 by Block) is an open-source local AI agent that supports any LLM backend and executes real actions: install packages, run tests, modify files, call APIs. This prompt structure is designed for Goose-style action-oriented agents.

## Goose Task: [Short task name]

**Objective**: [One sentence describing the complete state when this task is done]

**LLM backend**: [claude-sonnet-4-6 / glm-5.1 / gpt-4o / gemma-4 — whichever you're using]

**Allowed actions**:
- Read and write files in: [path/to/project]
- Run shell commands: [list safe commands, e.g., npm test, npm run build, git status]
- Install packages: [yes/no — if yes, list approved package registries]
- Make HTTP requests to: [list allowed external APIs, e.g., "GitHub API only"]

**Prohibited actions** (hard stops — do not proceed if any of these are required):
- git push (never push without human review)
- rm -rf or destructive filesystem operations
- Modify files outside [path/to/project]
- Access [sensitive-system]

**Context files** (read these before starting):
- [path/to/README.md]
- [path/to/relevant-config.json]

**Task steps** (ordered):
1. [First action]
2. [Second action, may depend on output of step 1]
3. Verify: run [test command] and confirm output matches [expected output]

**Output**: When done, write `goose-task-complete.md` with:
- Actions taken (with file paths and commands run)
- Test results
- Any assumptions made
- Any issues encountered

Start immediately. Do not ask for clarification unless truly blocked.

Category 29: Claude Sonnet 4.6 — 1M Context & Agentic Search Prompts (April 2026)

Claude Sonnet 4.6 introduced two capabilities that change how you structure prompts: a 1M token context window (beta) and GA web search/web fetch with code-execution-based result filtering. These prompts exploit both.

29.1 The Whole-Codebase Refactor Prompt (Expert)

Tool: Claude Sonnet 4.6 via API or Claude Code | Context required: 200K–1M tokens

With the 1M context window, you can load an entire medium-sized codebase and ask for architectural analysis without chunking. This works for repositories up to ~150K lines.

## Codebase Refactor Brief

**Repository**: [project-name]
**Goal**: [Specific refactor objective — e.g., "migrate from Pages Router to App Router", "replace all class components with hooks", "extract shared utilities from duplicated code"]
**Constraints**:
- Do not change external API contracts (public-facing routes must remain the same)
- All existing tests must pass after refactor
- Prefer surgical changes over rewrites

**Files loaded below** (entire codebase follows in this message):
[Paste full codebase or use file upload — Claude Sonnet 4.6 handles up to 1M tokens]

**Output requested**:
1. A prioritized list of refactor changes (most impactful first)
2. For each change: which files are affected, what changes, and estimated risk level (low/medium/high)
3. A proposed commit sequence (small atomic commits, safest order)
4. Any architectural concerns that would block this refactor

Do NOT generate code yet — produce the analysis and plan first. I will confirm before implementation begins.

29.2 The Research-Then-Build Prompt (Intermediate)

Tool: Claude Sonnet 4.6 (web search GA) | Time: 15–30 min

Sonnet 4.6's web search and web fetch are GA, with dynamic result filtering via code execution. This prompt chains research directly into implementation — no context-switching between browser and editor.

## Research-Then-Build Task

**What I'm building**: [Short description — e.g., "a rate limiter middleware for my Next.js API routes"]

**Research phase** (do this first — use web search):
1. Search for: "[topic] best practices [current year]"
2. Fetch the top 2–3 relevant documentation pages
3. Identify: (a) the standard pattern, (b) common failure modes, (c) security considerations
4. Write a 3-bullet summary of your findings before writing any code

**Build phase** (only after research summary is written):
- Implement [feature] based on your findings
- Follow the standard pattern you identified
- Add defensive handling for the top failure mode
- Include a comment linking to the primary source used

**Validation**:
- Re-fetch [relevant documentation URL] and confirm your implementation aligns
- Note any deviations and explain why

Start with the research phase. Do not write code until research summary is complete.

29.3 The Extended-Thinking Architecture Decision Prompt (Advanced)

Tool: Claude Sonnet 4.6 with extended thinking | Time: 5 min prompt, 10–20 min thinking

Extended thinking gives the model more compute budget before it commits to an answer. Use this for architecture choices where a wrong call means weeks of rework.

## Architecture Decision Request

**Decision to make**: [e.g., "Should I use Supabase Realtime or polling for my live dashboard?"]

**Context**:
- System: [Brief description]
- Scale: [Expected users/requests in 6 months]
- Team: [Solo / small / larger]
- Constraints: [Budget, latency, existing stack, migration costs]
- Timeline: [When must you ship?]

**What I've already considered**:
- Option A: [First option] — I think this because [reasoning]
- Option B: [Second option] — I think this because [reasoning]
- What I'm unsure about: [Specific uncertainty]

**What I need**:
1. Evaluate both options against my specific constraints (not generic trade-offs)
2. Identify what I'm missing or wrong about in my reasoning
3. Recommend one option with confidence level (high/medium/low) and what would change your recommendation
4. Give me the one question I should answer before committing

Take your time — a slow, thorough answer beats a fast, wrong one.

Category 30: April 2026 — Agent Framework, Security Audit & Parallel Fleet Prompts

Three new workflows unlocked by the April 2026 AI tooling wave: Microsoft Agent Framework 1.0 multi-agent orchestration, Claude Mythos-style security audit chaining, and Cursor 3 parallel agent fleet management.

30.1 The Microsoft Agent Framework 1.0 Orchestration Prompt (Advanced)

Tool: Microsoft Agent Framework 1.0 (.NET or Python), Claude Code | Time: 30–60 min setup

Agent Framework 1.0 ships with A2A and MCP protocol support, enabling cross-runtime agent interoperability. Use this prompt to design multi-agent workflows that span different AI providers without lock-in.

## Multi-Agent Workflow Design Request

**Workflow goal**: [What the agent system should accomplish end-to-end — e.g., "receive a GitHub issue, research the codebase, implement a fix, open a PR, and notify Slack"]

**Agents needed** (describe each):
- Agent 1: [Name + responsibility + which model/provider — e.g., "Researcher — Claude Sonnet 4.6 — reads codebase and clarifies requirements"]
- Agent 2: [Name + responsibility + which model/provider]
- Agent 3: [Name + responsibility + which model/provider]

**Coordination protocol**: A2A (agent-to-agent messages) | MCP (tool calls to shared context) | Both
**Runtime**: .NET | Python | Both

**State management**:
- Shared state that all agents need: [list]
- State private to each agent: [list]
- How agents hand off work: [event-driven / polling / direct call]

**Error handling**:
- If Agent 1 fails: [retry / fail pipeline / route to human]
- If Agent 2 fails: [behavior]
- Maximum retries per agent: [N]

**Output required**:
1. Agent architecture diagram (ASCII or described)
2. Agent Framework 1.0 code scaffold for each agent class
3. The A2A message schema for agent handoffs
4. The MCP tools each agent needs registered
5. DevUI configuration for browser-based debugging

Generate the scaffold. I will fill in the business logic per agent.

30.2 The AI Security Audit Chain Prompt (Expert)

Tool: Claude Sonnet 4.6 or Claude Code with CyberOS MCP | Time: 20–40 min per codebase

Inspired by Claude Mythos / Project Glasswing's defensive security workflow — systematically chain vulnerability discovery, triage, and remediation across a codebase without missing surface area.

## AI-Powered Security Audit — Systematic Chain

**Codebase**: [Repo path or paste content]
**Stack**: [e.g., Next.js 14 + Supabase + Stripe + Python FastAPI backend]
**Deployment**: [Vercel + AWS Lambda | Self-hosted | Cloud provider]
**Compliance scope**: [OWASP Top 10 | SOC 2 | PCI-DSS | All]

## Phase 1 — Attack Surface Map
List every:
- Public HTTP endpoint (method + path + auth required)
- Data input point (form, query param, file upload, webhook)
- Third-party integration (API calls out, webhooks in)
- Secret/credential usage point

Do not analyze yet. Only map. Output as a numbered list.

## Phase 2 — Vulnerability Scan
For each item on the attack surface map, check for:
- Injection (SQL, command, SSRF, path traversal)
- Authentication/authorization bypass
- Sensitive data exposure (secrets in logs, responses, or error messages)
- Cryptographic weaknesses (weak ciphers, padding oracle, hardcoded keys)
- Supply chain risks (mutable version references, unverified dependencies)

Classify each finding: CRITICAL / HIGH / MEDIUM / LOW / INFO
Include CWE ID and the exact file:line where the issue exists.

## Phase 3 — Remediation Plan
For each CRITICAL and HIGH finding:
1. Explain the vulnerability in one sentence
2. Write the fixed code (before/after diff)
3. Explain why the fix works

## Phase 4 — Verification
After remediations are applied:
- Re-scan the attack surface for the patched items
- Confirm no new vulnerabilities were introduced by the fix
- Output a signed-off list: [finding] → [status: FIXED / PARTIALLY FIXED / DEFERRED]

Start with Phase 1. Do not proceed to Phase 2 until I confirm the attack surface map is complete.

30.3 The Cursor 3 Parallel Agent Fleet Prompt (Advanced)

Tool: Cursor 3 Agents Window | Time: 5 min to launch, 30–120 min execution

Cursor 3's Agents Window lets you run multiple AI agents simultaneously across local, SSH, and cloud environments. This prompt template structures how to decompose work across a fleet efficiently so agents don't conflict.

## Parallel Agent Fleet Assignment

**Project**: [Brief description of the codebase]
**Goal**: [What needs to be accomplished — e.g., "ship the user dashboard feature including data layer, UI components, tests, and documentation"]

**Fleet decomposition** (define independent workstreams that can run in parallel):

Agent A — [Name: e.g., "Data Layer"]
- Scope: [Specific files/directories this agent owns]
- Task: [Exact work to do]
- Output: [What it should produce — e.g., "implemented API routes with tests passing"]
- Dependencies: [What it needs before starting — e.g., "database schema must exist"]
- Must NOT touch: [Files/areas that are other agents' scope]

Agent B — [Name: e.g., "UI Components"]
- Scope: [...]
- Task: [...]
- Output: [...]
- Dependencies: [...]
- Must NOT touch: [...]

Agent C — [Name: e.g., "Tests & Docs"]
- Scope: [...]
- Task: [...]
- Output: [...]
- Dependencies: [Agent A and B PRs merged]
- Must NOT touch: [...]

**Conflict prevention**:
- Shared files that multiple agents might edit: [list them — these need explicit ownership]
- Owner of package.json / lock file: [Agent A | Agent B | None — freeze during parallel work]
- Owner of shared types/interfaces: [which agent defines, others consume]

**Review order**:
1. Review Agent A output first
2. Review Agent B output (may depend on A's types)
3. Review Agent C output last (depends on both)

**Launch in the Agents Window**: Open one agent session per row above. Paste the Agent-specific block into each session. Start all simultaneously.

This library is updated monthly with new prompts based on emerging tools, patterns, and reader requests. Last updated: April 14, 2026. Added: Category 31 (AI Agent Payments, Session Context Briefs, Generated Code Security Review). Previous: Category 30 (Agent Framework 1.0 orchestration, AI security audit chain, Cursor 3 parallel fleet management, April 13). Category 29 (Claude Sonnet 4.6 — 1M Context & Agentic Search Prompts, April 10). Category 28 (Long-Horizon Agentic Execution, April 9). Category 27 (Multi-Agent Orchestration, April 7). Category 26 (MCP Integration, March 31).

Category 31: April 2026 — AI Agent Payments, Session Context & Security Review

Three new prompt patterns emerging from the Claude Code creator workflow reveal and x402 protocol adoption.

31.1 The AI Agent Payment Integration Prompt (Advanced)

Tool: Claude Code, Cursor | Time: 2-4 hours | Category: Emerging Patterns

Context: Coinbase's x402 protocol enables AI agents to make autonomous payments. As of April 2026, this is becoming a real workflow pattern — agents that call APIs, pay for compute, and operate economically without human authorization for each transaction.

I'm building an AI agent that needs to make autonomous payments using the 
Coinbase x402 protocol / [payment protocol].

## Agent Context
- Agent type: [coding assistant / research agent / deployment bot]
- Payment ceiling per action: $[amount]
- Allowed payment recipients: [API services, infrastructure providers]
- Forbidden: [payments to unknown wallets, amounts over $X]

## What I Need
1. Integrate x402 payment headers into the agent's HTTP client
2. Implement a payment budget tracker that halts the agent when the daily/session 
   ceiling is hit
3. Add a payment audit log (what was paid, when, to whom, why)
4. Implement human-approval gates for payments above $[threshold]
5. Handle x402 402 Payment Required responses gracefully

## Safety Requirements
- Never pay from the agent wallet without logging first
- Require cryptographic receipts for all payments
- Alert human operator if payment velocity exceeds [N] transactions/minute
- Reject any payment request that doesn't match the allowed-recipient list

Build the payment client and budget tracker first, then integrate into the 
existing agent loop.

Use when: Building economic agents, autonomous task runners that consume paid APIs, or testing the x402 payment stack.

Security note: Always implement human approval gates for amounts above $1 in production. See Chapter 10 for AI agent attack surfaces.

31.2 The Session Context Brief Generator (Beginner)

Tool: Claude Code, Cursor, Windsurf | Time: 5 minutes | Category: Workflow

This prompt generates a reusable session brief from your current codebase state. Run it at the start of every Claude Code session to give the AI full context before any task.

I need you to generate a session brief for this codebase. Read the following 
and produce a structured brief I can paste at the start of future sessions:

## Please Analyze
- The overall architecture (what framework, what database, what auth)
- The current state (what works, what's broken based on TODO comments and errors)
- The key files that any feature touching [feature area] would need to know about
- Any explicit constraints in CLAUDE.md or README that I shouldn't violate
- The tech debt or known issues I should steer around

## Output Format
Produce a brief in this format:
---
## Session Brief — [Date]
**Stack**: [framework, database, auth, hosting]
**What's working**: [bullet list]
**What's broken / in-progress**: [bullet list]
**Key files for [feature area]**: [file paths with one-line description each]
**Constraints to respect**: [rules from CLAUDE.md / README]
**Steer around**: [known issues, fragile code, don't-touch zones]
---

Keep it under 400 words so it fits in a context window preamble.

Use when: Starting any Claude Code session, onboarding to a new codebase, or after a long break from a project.

Why it works: A 5-minute brief prevents 30-60 minutes of context-building drift. Claude Code performs significantly better when it knows the full codebase state upfront.

31.3 The Generated Code Security Review Prompt (Intermediate)

Tool: Claude Code, Cursor | Time: 10-15 minutes | Category: Security

After generating a significant block of code, use this prompt to run a security review before accepting the change. Especially important for authentication flows, API handlers, and any code that touches user data.

Review the following generated code for security vulnerabilities. 

## Code to Review
[paste generated code here]

## Review Checklist
Check specifically for:
1. **Injection vulnerabilities**: SQL injection, command injection, path traversal
2. **Authentication gaps**: Missing auth checks, broken access control
3. **Input validation**: Unvalidated user input reaching sensitive operations
4. **Secret exposure**: Hardcoded credentials, keys in code, logging of sensitive data
5. **Prototype pollution**: Object spread from user input, __proto__ manipulation
6. **Race conditions**: Async operations that could interleave dangerously
7. **Error handling**: Stack traces leaking in responses, errors that expose internals

## For Each Issue Found
- Severity: Critical / High / Medium / Low
- CWE category
- Exact line(s) affected
- Safe version of the code

## If Clean
Confirm the code is safe to merge and note any edge cases that weren't security 
issues but should be tested.

Context: This code is [describe what it does and who has access to it].
The framework is [Next.js / Express / Django / etc.].
The data involved: [user PII / payment data / internal only / public].

Use when: After any AI-generated auth handler, API route, form processing, or file upload code. Non-negotiable for code touching user data or payments.

Pairs with: CyberOS (https://cyberos.dev) for automated continuous review in CI/CD pipelines.

Source: Based on OWASP Top 10 2025 and the CyberOS pattern database (615 patterns as of April 2026).

Category 32: Automation & Agent Orchestration Prompts (Added April 2026)

Three new prompt patterns for Claude Code Routines (launched April 2026), Cursor 3 multi-repo agent orchestration, and automated security auditing — covering the full spectrum from simple recurring automation to coordinated multi-agent coding sessions.

32.1 Claude Code Routines — PR Review Automation (Intermediate)

Tool: Claude Code | Difficulty: Intermediate | Time: 15-30 min

Claude Code Routines (April 2026) let you define recurring coding tasks that run on Anthropic's cloud infrastructure, triggered by events like new pull requests. Use this prompt to configure a Routine that automatically reviews every incoming PR before a human reviewer sees it.

## Claude Code Routine: Automated PR Review

Set up a Claude Code Routine that triggers on new pull requests to this 
repository and performs a structured code review before human reviewers 
are assigned.

## Trigger
Event: pull_request.opened, pull_request.synchronize
Scope: all branches targeting main and develop
Skip: PRs with label "skip-ai-review" or authored by bots

## Review Tasks (run in sequence)

### 1. Change Summary
- Summarize what the PR does in 3-5 bullet points
- Identify which components/modules are affected
- Estimate scope: small (< 50 lines changed), medium (50-300), large (300+)

### 2. Code Quality Check
- Flag any functions longer than 50 lines
- Flag cyclomatic complexity > 10
- Identify duplicated logic that already exists elsewhere in the codebase
- Check naming conventions match the patterns in [existing files in the repo]

### 3. Security Scan
- Check for the patterns in Prompt 32.3 (OWASP Top 10 for Next.js/React)
- Flag any hardcoded secrets, tokens, or credentials
- Identify unvalidated user inputs reaching database or filesystem operations
- Check new API routes for missing authentication guards

### 4. Test Coverage
- Identify new functions or branches not covered by the PR's test additions
- List any test files that should have been updated but weren't
- Flag missing edge case tests for: null/undefined input, empty arrays, 
  auth failure paths

### 5. Review Output
Post a structured comment to the PR with:
- **Summary**: [auto-generated summary]
- **Scope**: small / medium / large
- **Issues**: [table: Severity | File | Line | Issue | Suggested Fix]
- **Missing tests**: [list]
- **Verdict**: LGTM (no blockers) | NEEDS CHANGES (list blockers) | REQUEST HUMAN REVIEW (flag for security/arch concerns)

## Routine Configuration
- Runtime: Anthropic cloud (no self-hosted runner required)
- Model: claude-sonnet-4-6
- Timeout: 5 minutes per PR
- Post comment as: GitHub App bot account
- Do NOT approve or request changes via GitHub review API — comment only
- Do NOT auto-merge under any circumstances

## What This Routine Should NOT Do
- Rewrite or suggest large refactors on a per-PR basis
- Block PRs automatically — it informs, humans decide
- Comment more than once per commit push (deduplicate on commit SHA)

Why it works: This Routine acts as a tireless first-pass reviewer that runs in under 5 minutes on every PR. Human reviewers arrive to a structured pre-analysis and can focus on architecture and intent rather than scanning for obvious issues.

Setup note: Configure the Routine in your Claude Code workspace settings under Routines > New Routine > Event Trigger. The model runs server-side — no GitHub Actions minutes consumed.

32.2 Multi-Agent Coding Session Orchestration (Advanced)

Tool: Claude Code, Cursor 3 | Difficulty: Advanced | Time: 2-4 hours

Cursor 3 (April 2026) introduced unified multi-repo agent orchestration — a single workspace can coordinate agents working across separate repositories simultaneously. Use this prompt pattern to split a full-stack feature across three specialized agents: backend, frontend, and test/QA.

## Multi-Agent Session: [Feature Name]

You are the orchestrator for a 3-agent coding session. Your job is to 
decompose the feature, assign agents, prevent conflicts, and integrate 
outputs. Do not write implementation code yourself — delegate to agents.

## Feature Brief
[Describe the feature in 3-5 sentences: what it does, what data it uses, 
what API contracts it creates or modifies, and any external integrations.]

## Repository Map
- Backend repo: [path or URL — e.g., api.myapp.com at /repos/backend]
- Frontend repo: [path or URL — e.g., app.myapp.com at /repos/frontend]
- Shared types package: [path — e.g., /repos/shared-types] (if applicable)

---

## Agent 1: Backend Agent
**Scope**: [/repos/backend/src/routes, /repos/backend/src/services, /repos/backend/src/db]
**Mission**: Implement the server-side feature — database schema changes, 
business logic, and REST/GraphQL API endpoints.

**Deliverables**:
1. Database migration file for [new tables or schema changes]
2. Service layer with full business logic and error handling
3. API endpoints matching this contract:
   - [METHOD] [/path]: [description, request body, response shape]
   - [METHOD] [/path]: [description]
4. Unit tests for the service layer (90%+ coverage on new code)
5. Update /repos/shared-types with any new TypeScript interfaces

**Must NOT touch**:
- Frontend repo
- Authentication middleware (read-only)
- Existing migrations

**Handoff**: Write `agent-handoff-backend.md` with final API contracts 
and any environment variables added.

---

## Agent 2: Frontend Agent
**Scope**: [/repos/frontend/src/components, /repos/frontend/src/pages, /repos/frontend/src/hooks]
**Mission**: Implement the UI for [feature name] using the API contracts 
defined in agent-handoff-backend.md. Wait for Agent 1's handoff file 
before writing any data-fetching code.

**Deliverables**:
1. React components: [list specific components needed]
2. Data-fetching hooks using [SWR / React Query / Server Actions] 
   matching the API contract in agent-handoff-backend.md
3. Form validation for all user inputs
4. Loading, empty, and error states for all async operations
5. Responsive layout (mobile breakpoint: 640px)

**Must NOT touch**:
- Backend repo
- Auth context or session management
- Design system tokens (read-only — use existing classes)

**Handoff**: Write `agent-handoff-frontend.md` with component tree, 
prop interfaces, and any new environment variables needed.

---

## Agent 3: Test & QA Agent
**Scope**: [/repos/backend/tests, /repos/frontend/tests, /repos/frontend/e2e]
**Mission**: Write the full test suite for this feature. Start after 
Agent 1's handoff. Complete E2E tests after Agent 2's handoff.
Do NOT write implementation code — tests only.

**Deliverables**:
1. API integration tests (all endpoints: happy path + 4xx + 5xx cases)
2. Component tests for each UI component Agent 2 built
3. E2E test covering the full user flow: [describe the 3-5 step user journey]
4. A test coverage report showing new code coverage

**Must NOT touch**:
- Source code in either repo (tests and fixtures only)

**Handoff**: Write `agent-handoff-qa.md` with test results, coverage 
numbers, and any failing tests with root cause.

---

## Orchestration Rules

**Sequencing**:
1. Agent 1 runs first — do not start Agent 2 until agent-handoff-backend.md exists
2. Agent 2 and Agent 3 (API tests only) can run in parallel after Agent 1 finishes
3. Agent 3 E2E tests run last — requires both Agent 1 and Agent 2 complete

**Conflict prevention**:
- package.json / lock files: frozen during parallel work — no dependency additions
- Shared types: Agent 1 owns writes, Agents 2 and 3 read-only
- Environment files: each agent appends to a dedicated .env.[agent] file, 
  do not modify .env directly

**Integration checkpoint**:
When all three agents have written their handoff files, run:
1. `npm run build` in both repos — must succeed with zero errors
2. `npm test` in both repos — all tests must pass
3. `npm run e2e` — all E2E tests must pass

If any step fails, identify which agent's output caused the failure 
and assign a targeted fix task to that agent only.

**Final output**:
Write `session-summary.md` with:
- Feature implemented (what was built)
- All files changed (by repo and agent)
- Test results (pass/fail counts, coverage delta)
- Known limitations or deferred items
- Decisions made and why

Why it works: The strict scope boundaries prevent agents from stepping on each other's work. The handoff files create an explicit async interface between agents — Agent 2 cannot make assumptions about the API until Agent 1 has documented it, which eliminates the most common integration failure in multi-agent sessions.

Cursor 3 setup: Open three agent panels in the Agents Window. Paste each agent block into its respective panel. Launch Agent 1 first. Monitor agent-handoff-backend.md creation before launching Agents 2 and 3.

32.3 Security Audit Automation — Next.js/React OWASP Top 10 (Advanced)

Tool: Claude Code | Difficulty: Advanced | Time: 30-60 min

Use this prompt to run a comprehensive automated security audit of a Next.js or React codebase, checking for all OWASP Top 10 vulnerability classes with patterns tuned for the React/Next.js stack. Designed to complement CyberOS's continuous monitoring (https://cyberos.dev) for one-time deep audits.

## Automated Security Audit: Next.js / React Codebase

Perform a systematic OWASP Top 10 security audit of this Next.js/React 
codebase. Work through each phase in sequence. Do not skip phases or 
combine them — each phase informs the next.

## Codebase Context
- Framework: Next.js [version] (App Router / Pages Router)
- Auth provider: [NextAuth / Supabase Auth / Clerk / custom]
- Database: [Supabase / Prisma + PostgreSQL / other]
- Payment handling: [Stripe / Paddle / none]
- Deployment: [Vercel / AWS / self-hosted]
- External APIs called: [list]

---

## Phase 1 — Inventory (5 min, no analysis yet)

Map the attack surface:
1. List every file in /app/api or /pages/api (Next.js API routes)
2. List every Server Action (files with "use server")
3. List every form or input that accepts user data
4. List every place external data is rendered to the DOM
5. List every third-party library that handles auth, payments, or user data

Output as numbered lists. Do not evaluate yet.

---

## Phase 2 — OWASP Top 10 Scan

For each item in the Phase 1 inventory, check the following. 
Reference CWE IDs and the exact file:line for every finding.

### A01 — Broken Access Control
- Every API route and Server Action: is auth checked server-side 
  (not relying on middleware alone)?
- Are RLS policies enforced at the database level (Supabase) or via 
  ORM-level guards (Prisma)?
- Are there IDOR risks — can a user access another user's records by 
  changing an ID parameter?
- Is the CVE-2025-29927 dual-layer auth pattern implemented? 
  (See Category 26, Prompt 26.3)

### A02 — Cryptographic Failures
- Are passwords hashed with bcrypt or argon2 (not SHA-1/MD5)?
- Is HTTPS enforced with HSTS headers?
- Are any secrets or tokens returned in API responses or logged?
- Are JWTs validated on every request (not just on login)?

### A03 — Injection
- Are all database queries parameterized? 
  Flag any string concatenation in SQL or ORM raw queries.
- Is there risk of command injection in any child_process or exec calls?
- Server Actions: is user input sanitized before use in database operations?
- Are URL and path parameters validated before use in filesystem operations?

### A04 — Insecure Design
- Are there rate limits on authentication endpoints?
- Are there rate limits on resource-intensive API routes 
  (e.g., AI generation, file processing)?
- Is there a mechanism to revoke sessions on password change or logout?
- Are webhook endpoints (Stripe, etc.) verifying signatures?

### A05 — Security Misconfiguration
- Are security headers set: CSP, X-Frame-Options, X-Content-Type-Options, 
  Referrer-Policy, Permissions-Policy?
- Are CORS origins restricted (not "*")?
- Are error responses generic (no stack traces or internal paths leaking)?
- Are Next.js server components accidentally exposing server-side data 
  in client bundles?

### A06 — Vulnerable Components
- Run: `npm audit --audit-level=high`
- Flag any dependencies with known CVEs (severity: high or critical)
- Flag any dependencies last updated more than 18 months ago that handle 
  auth, crypto, or user data

### A07 — Auth and Session Failures
- Are session tokens HTTP-only cookies (not localStorage)?
- Are session IDs regenerated after login (session fixation prevention)?
- Is "remember me" implemented with a separate long-lived token 
  (not just extending the session)?
- Are failed login attempts rate-limited and logged?

### A08 — Software and Data Integrity
- Are all npm install commands run with a lockfile (`npm ci`, not `npm install`)?
- Are GitHub Actions using pinned SHA hashes for third-party actions 
  (not floating tags like @v3)?
- Are Stripe/webhook payloads verified with HMAC signatures 
  before processing?

### A09 — Logging and Monitoring
- Are security events logged: login success, login failure, 
  auth failure on protected routes?
- Are logs sanitized — no passwords, tokens, or PII in log output?
- Is there alerting for repeated auth failures (possible brute force)?

### A10 — Server-Side Request Forgery (SSRF)
- Are there any routes that fetch a URL provided by the user?
- If yes: is the URL validated against an allowlist of safe domains?
- Are internal metadata endpoints (e.g., AWS 169.254.x.x) blocked?

---

## Phase 3 — Severity Classification

For every finding, output a row in this table:

| # | OWASP Category | CWE | Severity | File | Line | Description | Fix |
|---|---------------|-----|----------|------|------|-------------|-----|
| 1 | A01 | CWE-284 | CRITICAL | ... | ... | ... | ... |

Severity levels:
- CRITICAL: exploitable remotely, data exposure or full auth bypass
- HIGH: requires auth but leads to significant data or privilege risk
- MEDIUM: requires specific conditions, limited impact
- LOW: defense-in-depth gap, no direct exploitability
- INFO: best practice deviation, no current risk

---

## Phase 4 — Remediation

For every CRITICAL and HIGH finding:
1. Show the vulnerable code (before)
2. Show the fixed code (after)
3. One-sentence explanation of why the fix closes the vulnerability
4. Link to the relevant OWASP cheat sheet or CyberOS pattern

For MEDIUM findings: provide the fix code only (no explanation needed).

For LOW and INFO: list as a bullet with the file location.

---

## Phase 5 — Verification

After all remediations are written:
1. Re-check each CRITICAL and HIGH finding — confirm the fix addresses 
   the root cause, not just the symptom
2. Check that no fix introduced a new vulnerability 
   (e.g., error handling that leaks internals)
3. Output a final sign-off table:

| Finding # | Status | Notes |
|-----------|--------|-------|
| 1 | FIXED | ... |
| 2 | DEFERRED | reason |

---

## Output Summary
At the end of all phases, produce:
- Total findings by severity (CRITICAL: N, HIGH: N, MEDIUM: N, LOW: N, INFO: N)
- Top 3 risk areas in this codebase
- Recommended next step (e.g., "Schedule penetration test focusing on A01 
  and A03 findings", "Integrate CyberOS for continuous monitoring")

Begin with Phase 1. Confirm the inventory is complete before proceeding.

Why it works: The phased structure prevents the common failure mode where an LLM jumps to fixes before fully mapping the attack surface. By forcing an inventory pass first, the audit achieves full coverage — nothing is missed because the model got absorbed in one interesting vulnerability.

CyberOS integration: This prompt covers the same OWASP Top 10 categories as CyberOS's static analysis engine (https://cyberos.dev). Use this for on-demand deep audits, and CyberOS for continuous PR-level scanning. The findings from this audit can be imported into CyberOS as baseline issues.

Pairs with: Prompt 31.3 (Generated Code Security Review) for ongoing review of new code, and Prompt 30.2 (AI Security Audit Chain) for systematic multi-phase audit chaining.

Category 33: Claude Opus 4.7 — xhigh Effort, Vision & Self-Verification

Released April 16, 2026: Claude Opus 4.7 introduced three capabilities with immediate impact on vibe coding workflows — an xhigh effort level for extended reasoning, 3.3x higher-resolution vision, and self-verification on agentic tasks. These prompts are tuned specifically for Opus 4.7 and will not produce the same results on earlier models.

33.1 xhigh Effort Architectural Reasoning (Expert)

Tool: Claude Code (Opus 4.7) | Difficulty: Expert | Time: 15-30 min

Use Opus 4.7's xhigh effort level for decisions that are hard to reverse — database schema choices, authentication architecture, API design. The extended thinking mode considers more edge cases and provides more honest uncertainty quantification than standard effort.

<effort>xhigh</effort>

You are a senior software architect. I need your deepest analysis on this decision.

## Decision Required
[Describe the architectural choice in 1-3 sentences — e.g., "Should I use a 
single Postgres database with RLS for multi-tenancy, or separate schemas per tenant?"]

## System Context
- Scale target: [current users / projected 12-month users]
- Team size: [N engineers, their experience level]
- Current stack: [list key technologies]
- Budget constraints: [infrastructure budget, or "cost-sensitive / not a constraint"]
- Timeline: [when does this need to be production-ready]

## Constraints (non-negotiable)
- [Constraint 1 — e.g., "Must work with Supabase — no custom database infra"]
- [Constraint 2]

## Options Under Consideration
### Option A: [name]
[Brief description]
Perceived pros: [list]
Perceived cons: [list]

### Option B: [name]
[Brief description]
Perceived pros: [list]
Perceived cons: [list]

## What I'm Uncertain About
[The specific thing that makes this decision hard — e.g., "I don't know how 
RLS performs at 100k rows per tenant with complex join queries"]

## Output Required
1. Your recommendation (Option A, B, or a hybrid) with confidence level (0-100%)
2. The 3 most important factors that drove your recommendation
3. The scenario under which your recommendation would be wrong
4. The first concrete implementation step if I go with your recommendation
5. Red flags to watch for in the first 30 days of implementation

Take as long as you need to reason through this. Don't truncate the reasoning.

Why it works: The <effort>xhigh</effort> tag signals Opus 4.7 to enter extended thinking mode. For complex architectural questions, the additional compute produces answers that consider more edge cases, catch more subtle interactions, and provide more honest uncertainty quantification than standard responses.

When to use xhigh: Save it for decisions that are hard to reverse — architectural choices, security design, data modeling. Don't use it for quick questions where standard effort is adequate.

33.2 Vision-Enhanced UI Debugging (Intermediate)

Tool: Claude Code (Opus 4.7) | Difficulty: Intermediate | Time: 10-20 min

Opus 4.7's 3.3x higher-resolution vision support means it can now read detailed UI screenshots, identify small alignment issues, read small-print error messages, and compare designs at pixel level. Use this pattern for UI debugging and visual regression analysis.

[Attach screenshot of UI bug or visual issue]

You are a senior frontend engineer debugging a visual problem. The screenshot shows:
[Brief description of what you're looking at]

## What I need
1. Identify all visible UI problems in this screenshot — layout issues, spacing
   inconsistencies, color/contrast problems, text truncation, alignment bugs
2. For each problem, hypothesize the CSS or component cause
3. Rank by severity: (a) breaks functionality (b) fails WCAG contrast (c) looks wrong

## Codebase context
- Framework: [React/Next.js/Vue/etc]
- CSS approach: [Tailwind/CSS Modules/styled-components/etc]
- Key component files: [relevant file paths]

Then check the relevant component files and propose a specific fix for the
highest-severity issue first.

Why it works: The 3.3x vision resolution lets Opus 4.7 read small-print labels, identify subtle alignment (off by 2px), and distinguish similar colors that previous models couldn't differentiate. Pairing the visual analysis with codebase access creates a loop where the model reads the pixel output and the source simultaneously.

33.3 Self-Verifying Agent Task (Advanced)

Tool: Claude Code (Opus 4.7) | Difficulty: Advanced | Time: 30-90 min

Opus 4.7 added self-verification on agentic tasks — the model can now flag when it has low confidence in its own output and request human confirmation before proceeding. This prompt pattern is designed to take advantage of that capability for high-stakes automated tasks.

You are executing a high-stakes automated task. Opus 4.7 self-verification is enabled.

## Task
[Describe the task in detail]

## Self-Verification Protocol
At each decision point where you are >15% uncertain about the correct action:
1. STOP and output: VERIFICATION_REQUIRED: [describe what you're uncertain about]
2. List the options you're considering and your confidence in each
3. Wait for my confirmation before proceeding

## High-Stakes Actions That Always Require Verification
- Deleting or overwriting files not in the explicit scope
- Making API calls that cost money or have rate limits
- Modifying database schemas or running migrations
- Changing authentication or authorization logic
- Publishing or deploying to production environments

## Success Criteria
[What does "done" look like? How will you verify you succeeded?]

Begin. If you complete the first phase without a VERIFICATION_REQUIRED, confirm
the phase is done and your confidence level before continuing to the next phase.

Why it works: This prompt makes Opus 4.7's self-verification explicit and structured. By defining a confidence threshold (15%) and listing high-stakes action categories, you get an agent that asks for help when it genuinely needs it rather than either proceeding blindly or asking about everything.

Integration with CyberOS: For tasks involving security-sensitive operations, pair this with CyberOS's continuous monitoring so any unexpected file modifications or API calls are flagged independently.

Category 34: Claude Design & AI-Assisted Visual Creation

Launched April 17, 2026: Anthropic introduced Claude Design, extending Claude's capabilities into rapid visual content generation. These prompts cover workflows for using Claude Design alongside Claude Code for visual asset creation — from brand assets to landing page design to marketing graphics — integrated into the vibe coding workflow.

34.1 Brand Asset Sprint (Beginner)

Tool: Claude Design, Claude Code | Difficulty: Beginner | Time: 30-60 min

Use Claude Design to generate a complete brand asset pack for a new vibe-coded project. This prompt produces a design brief that Claude Design can execute directly, giving you logo concepts, color palettes, and icon sets in one session.

I'm creating brand assets for a new product called [Product Name].

## Product Summary
[2-3 sentences: what it does, who uses it, what feeling it should evoke]

## Brand Personality
Choose 3 adjectives that describe the brand: [e.g., modern / trustworthy / playful]

## Audience
Primary users: [who they are — age range, technical sophistication, context of use]

## Design Direction
- Style preference: [minimal / bold / corporate / friendly / technical / expressive]
- Color mood: [warm / cool / neutral / vibrant / muted]
- Reference brands I like: [1-3 brand names with notes on what you like]
- Reference brands to avoid: [1-2 brand names that feel wrong]
- Logo type preference: [wordmark / icon + wordmark / icon only / abstract mark]

## Assets Needed
1. Primary logo (light background)
2. Primary logo (dark background / inverted)
3. Favicon / app icon (square, 512×512)
4. Social media profile image (1:1 ratio)
5. Color palette: 1 primary, 1 accent, 2 neutrals (light + dark), 1 semantic (error/warning)
6. Typography pairing: heading font + body font (Google Fonts preferred)
7. 3 icon style examples (outline / filled / duotone — whichever fits the style)

## Output Format
For each asset, provide:
- Visual description precise enough for a designer or AI image tool to recreate
- Hex codes for all colors
- Font names and weights for typography
- A short rationale explaining why each choice fits the brand

Start with the color palette and typography — everything else should derive from those foundations.

Why it works: Claude Design's visual understanding lets it generate coherent brand systems rather than isolated assets. By front-loading the palette and type decisions, you get downstream assets that feel intentional rather than assembled from unrelated pieces.

Follow-up: Feed the output from this prompt directly into Claude Design's visual canvas to generate image mockups. Use the hex codes and font names in your Tailwind config (tailwind.config.ts) to wire the brand into the codebase in minutes.

34.2 Landing Page Hero Design Spec (Intermediate)

Tool: Claude Design, Cursor, Claude Code | Difficulty: Intermediate | Time: 20-45 min

Generate a detailed design spec for a landing page hero section — precise enough for Cursor to implement directly into Tailwind/React without ambiguity. Bridges the gap between visual concept and production code.

Design a landing page hero section for [Product Name], a [brief description].

## Goal of the Hero
The hero must communicate: [what the product does] + [who it's for] + [why to care]
in under 5 seconds. Primary CTA: [button text and action].

## Brand Context
- Primary color: [hex]
- Accent color: [hex]
- Background: [hex or gradient description]
- Heading font: [font name, weight]
- Body font: [font name, weight]
- Tone: [formal / casual / technical / playful]

## Layout Requirements
- Viewport: Full-screen (100vh) on desktop, auto-height on mobile
- Layout type: [centered / left-aligned / split (text left, visual right)]
- Visual element: [illustration / screenshot / animation / abstract shape / none]
- Navigation: [sticky top bar / transparent overlay / none]

## Content to Include
- Headline: [your draft or "generate 3 options"]
- Subheadline: [your draft or "generate 3 options"]
- Social proof element: [logos / testimonial quote / stat / none]
- CTA button: Primary "[text]" + Secondary "[text]" (optional)
- Trust signals: [e.g., "No credit card required", "Used by 2,000+ developers"]

## Responsive Behavior
- Desktop (1280px): [describe layout]
- Tablet (768px): [any changes — stack columns, reduce font sizes, etc.]
- Mobile (375px): [headline size, single-column, CTA full-width]

## Output Format
Provide:
1. Annotated wireframe description (text-based — every element, position, spacing)
2. Tailwind CSS class recommendations for each element
3. Copy variants (3 headline options, 2 subheadline options)
4. Animation suggestions (entrance animation, hover states) — optional, flag if they
   add distraction rather than clarity

Then implement the hero as a self-contained React component using Tailwind.

Why it works: By asking for both the design spec and the implementation in the same prompt, you skip the translation step where a design mockup loses fidelity going into code. The Tailwind class output means Cursor can implement the exact design without reinterpretation.

Pairs with: Prompt 34.1 (Brand Asset Sprint) for the color palette and font choices. Prompt 1.3 (Landing Page from Zero) in Category 1 for the full page structure beyond the hero.

34.3 Visual Content Brief for Consistent AI Generation (Advanced)

Tool: Claude Design, Claude Code (Opus 4.7) | Difficulty: Advanced | Time: 45-90 min

Create a visual content system specification — a single source of truth document that ensures all AI-generated visuals for a product feel like they belong to the same brand. Solves the consistency problem when generating marketing graphics, blog thumbnails, social posts, and UI illustrations over time.

## Visual Content System Specification

I need a visual content system for [Product Name] that ensures consistency across
all AI-generated images and graphics. This system will be used by Claude Design,
Midjourney, DALL-E 3, and Stable Diffusion to produce assets over the next 12 months.

## Brand Foundation (already defined)
- Logo: [description or attachment]
- Primary palette: [hex codes with role labels — primary, accent, background, text]
- Typography: [heading and body font names]
- Tone adjectives: [3 words that describe the brand personality]

## Asset Categories to Define
For each category, specify the visual style, composition rules, and example prompt template:

### Category A: Blog / Article Thumbnails (1200×628px)
- Use case: [website blog, newsletter, LinkedIn posts]
- Volume: ~[N] per month
- Visual style: [abstract / illustrative / photographic / typographic]

### Category B: Social Media Graphics (1:1, 9:16, 16:9)
- Use case: [Twitter/X, LinkedIn, Instagram]
- Volume: ~[N] per month
- Visual style: [consistent with A / more casual / motion-focused]

### Category C: Product Screenshots & Mockups
- Use case: [landing page, app store, documentation]
- Volume: ~[N] per quarter
- Visual style: [clean device mockup / contextual scene / abstract UI fragment]

### Category D: Icons & Illustrations (if applicable)
- Use case: [empty states, feature explainers, onboarding]
- Style: [flat / isometric / line art / 3D]

## Constraints
- Must never use: [specific visual elements to avoid — stock photo clichés,
  specific color combinations that conflict with brand, visual motifs from competitors]
- Must always include: [brand element in every image — subtle color, pattern, etc.]
- Accessibility: all text in images must meet WCAG AA contrast (4.5:1 minimum)

## Deliverables

1. **Style Guide**: 2-3 paragraphs defining the visual language in words
2. **Color Application Rules**: When to use primary vs. accent, background rules,
   gradient usage policy
3. **Reusable Prompt Templates**: For each category, a parameterized prompt template
   like: "[Category A template]: A [adjective] [composition] depicting [subject] for
   [brand name], using [colors], [style description], [technical specs]"
4. **Negative Prompt Library**: 10-15 terms to consistently exclude across all
   AI image generation to maintain brand safety and visual consistency
5. **Quality Checklist**: 5-point check before publishing any AI-generated asset
   (brand colors present, text legible, no AI artifacts, consistent style,
   no competitor visual cues)

Generate all five deliverables. For the prompt templates, test each one by
writing an example output description of what the image would look like.

Why it works: The consistency problem in AI visual generation comes from re-describing the brand each time you need an asset. A visual content system document solves this by encoding the brand DNA into reusable prompt fragments — Claude Design, Midjourney, and DALL-E 3 all respond to the same parameterized templates, producing visuals that read as siblings rather than strangers.

Production integration: Save this document as visual-content-system.md in your project root. Reference it at the start of every visual generation session: "Using the system defined in visual-content-system.md, generate [asset type]." Claude Design can read it directly as context.

Cross-link: CyberOS brand toolkit for security-focused products needing consistent trust-signal visuals. vibe-coding.academy for the course on building complete brand systems with AI tools.

Category 35: Claude Code Routines & Automation Prompts (New — April 2026)

These prompts are designed for Claude Code's Routines feature (launched April 2026), which runs saved workflows automatically on Anthropic's cloud infrastructure — triggered by GitHub events or cron schedules.

35.1 Automated Dependency Audit Routine (Intermediate)

Tool: Claude Code Routines | Trigger: Weekly cron | Time: Runs overnight

Deploy as a weekly cron Routine to audit all dependencies for CVEs, breaking changes, and outdated packages — then file a single consolidated GitHub issue with a prioritized upgrade plan.

You are a dependency security auditor running a weekly scan.

## Your task
1. Run `npm audit --json` (or equivalent for the project's package manager) and parse the output
2. Run `npx npm-check-updates --json` to identify outdated packages
3. Check the GitHub Security Advisories API for CVEs affecting any direct dependency
4. Cross-reference CVEs against the CISA Known Exploited Vulnerabilities catalog

## Prioritization framework
- P0 (File GitHub issue + comment on all open PRs): CVSS >= 9.0 CVEs in direct deps
- P1 (File GitHub issue): CVSS 7.0-8.9 CVEs, or packages > 2 major versions behind
- P2 (Add to weekly report): Minor/patch updates, low-severity advisories
- P3 (Skip): Dev-only dependencies with no production surface

## GitHub issue format
Title: `[Security] Weekly dependency audit — {DATE}`

Do not open a PR. File the issue only. Mark it with labels: `security`, `dependencies`.
If zero issues found: close any open dependency audit issues from previous weeks and post
a comment: "Weekly dependency scan {DATE}: No critical issues found."

Why it works: Manual dependency audits happen inconsistently — usually only when a CVE alert lands in your inbox, meaning you're already reactive. A Routine that runs every Monday at 2am means your team starts every week knowing their exposure.

Setup: Claude Code → Settings → Routines → New. Trigger: 0 2 * * 1 (every Monday at 2am). Connect GitHub. Paste prompt.

35.2 PR Quality Gate Routine (Beginner)

Tool: Claude Code Routines | Trigger: GitHub PR opened | Time: 2-3 min per PR

Run this Routine on every new pull request. It checks code quality, security, and test coverage gaps before a human reviewer looks at the diff.

You are a PR quality gate. Review the attached pull request diff and produce a
structured assessment. Do not approve or request changes — post a comment only.

Review for:
1. Security: OWASP Top 10, hardcoded secrets, missing auth checks on new endpoints
2. Code quality: functions >50 lines, duplicate code, broad TypeScript `any` types,
   missing async error handling, console.log in production paths
3. Test coverage: new functions with no test changes, API endpoints with no integration test
4. PR hygiene: description matches diff, breaking changes flagged

Output as a GitHub comment:

**Automated PR Review**

| Category | Status | Details |
|----------|--------|---------|
| Security | Pass / Issues | [summary] |
| Code Quality | Pass / Issues | [summary] |
| Test Coverage | Pass / Issues | [summary] |

Issues requiring action before merge: [list with file:line, or "None."]
Suggestions (non-blocking): [list, or "None."]

_Automated review. Final approval requires human review._

Why it works: Routes mechanical catches to automation so human reviewers spend time on architecture and business logic decisions. Teams using automated first-pass review report 30–40% shorter human review cycles.

35.3 Daily Release Notes Generator (Intermediate)

Tool: Claude Code Routines | Trigger: Daily cron (9am) | Time: 5-10 min

Generates human-readable release notes from yesterday's merged PRs and appends to CHANGELOG.md automatically.

You are a technical writer generating daily release notes.

1. Fetch all PRs merged into `main` in the last 24 hours
2. Group by category from PR labels or commit prefix: feat/fix/perf/security/docs/chore
3. Write 1-3 sentence plain-English summaries of each change
4. Identify breaking changes (look for "BREAKING" in PR titles or descriptions)

Append to CHANGELOG.md at the top:

## {DATE}

### Breaking Changes
[If any. Omit section if none.]

### New Features
- **[Feature name]**: [1-2 sentence description]

### Bug Fixes
- **[What was broken]**: [What was fixed]

### Security
- [Specific CVE/issue patched]

Rules:
- If no PRs merged: append `## {DATE}\n_No changes merged._`
- Never overwrite existing CHANGELOG entries
- Commit with message: `docs: daily release notes {DATE}`

Why it works: CHANGELOG debt is universal — teams know they should maintain it but rarely do consistently. A Routine removes the friction entirely. The CHANGELOG stays accurate at zero ongoing cost.

Cross-link: → EndOfCoding.com for the full article on Claude Code Routines. → LLMHire.com for AI Automation Architect roles (this skill commands a $28K salary premium).

Category 36: Context Engineering Prompts (New — April 2026)

"Context engineering" — coined in early 2026 by Tobi Lütke (Shopify CEO) and rapidly adopted across the industry — is the discipline of structuring what you put into an AI's context window to maximize output quality. With Claude's 1M-token context and $200/mo Max plan, context management is now a primary vibe coding skill.

36.1 Legacy Codebase Context Map (Beginner)

Tool: Claude Code | Time: 15-20 min | Context: 1M tokens ideal

Use this at the start of any engagement with an unfamiliar or legacy codebase. It builds a mental model for Claude that persists across the session, dramatically reducing hallucination and incorrect assumptions.

I'm about to ask you to work on a large existing codebase. Before I give you
any tasks, I want to load you with the context you need to reason accurately.

## Codebase overview
[Paste your README or write 2-3 sentences describing the product]

## Tech stack
- Language: [e.g., TypeScript, Python]
- Framework: [e.g., Next.js 15, FastAPI]
- Database: [e.g., PostgreSQL via Supabase]
- Deployment: [e.g., Vercel + Railway]
- Key dependencies: [list 5-10 most important packages]

## Architecture pattern
[Describe in 2-3 sentences: monolith vs. microservices, how data flows, where business logic lives]

## Naming conventions
- Files: [e.g., kebab-case for components, camelCase for utils]
- DB tables: [e.g., snake_case, plural]
- API routes: [e.g., /api/v1/resource]
- Env vars: [e.g., NEXT_PUBLIC_ prefix for client-safe vars]

## What NOT to touch
[List any files, modules, or patterns to avoid — e.g., "Don't modify auth middleware, it's vendor-managed"]

## Current known issues
[List 3-5 open bugs or technical debt items so Claude doesn't re-introduce them]

Acknowledge this context and tell me what you understand about the codebase
before I give you your first task.

Why it works: Without this upfront loading, Claude infers conventions from what it sees in each individual file — and can contradict itself across a session. This prompt anchors a shared mental model that holds for the entire working session.

Pro tip: Save this filled-in template as CLAUDE_CONTEXT.md in your repo root. Paste its contents at session start, or reference it as a Routine pre-step.

36.2 Rolling Summary Context Compression (Intermediate)

Tool: Claude Code, Claude.ai | Time: 5 min per compression cycle | Context: Any size

Long conversations drift. After ~20 exchanges, earlier decisions get forgotten and Claude starts making inconsistent choices. This prompt compresses your session state into a portable summary you can paste into a fresh context window.

We've been working together for a while. Before continuing, I need you to create
a compressed context summary I can paste into a new session.

Write a structured summary with these sections:

## Project State
- What we're building: [1 sentence]
- Current milestone: [what we're working on right now]
- Completion status: [% done, what's left]

## Decisions Made (Do Not Revisit)
[List every architectural, naming, or technical decision we've committed to —
 even if it feels suboptimal. These are locked.]

## Active Constraints
[List every constraint that's shaped our decisions: performance requirements,
 team conventions, third-party limitations, deadlines]

## Mistakes to Avoid
[List every wrong path, failed approach, or anti-pattern we've already ruled out —
 with 1 sentence on why it was rejected]

## Current Task State
[Describe exactly where we left off — what was last completed, what's in progress,
 what the immediate next step is]

## Files Modified This Session
[List every file touched, with 1-sentence description of what changed]

Format this for copy-paste into a new Claude session. The summary should be
complete enough that a fresh Claude instance can continue seamlessly with zero
catch-up questions.

Why it works: Context compression is the single highest-leverage technique for long vibe coding sessions. Teams using this report 60–70% reduction in "wait, I thought we decided..." regressions. It also makes sessions resumable across days.

36.3 Multi-File Feature Context Bundle (Advanced)

Tool: Claude Code | Time: 5 min setup, saves hours | Context: Targeted loading

When implementing a new feature that touches 5+ files, Claude needs to see all relevant code simultaneously to avoid making changes that break other parts of the system. This prompt guides you through building the right context bundle before writing any code.

I'm about to implement: [feature name in 1 sentence]

Before writing any code, help me identify every file that could be affected
and what I need to know about each one.

## Feature description
[2-3 sentences on what the feature does, what user-facing behaviour it changes,
 and what data it reads/writes]

## Entry points
[Where does this feature start? e.g., "New API endpoint at /api/payments/refund"
 or "New button in the checkout flow"]

Based on this, please:
1. List every file likely to need modification (with filepath and why)
2. List every file I should READ but not modify (key context for side effects)
3. Identify any circular dependencies or layering violations to watch for
4. Flag any existing tests I must update
5. Estimate total lines-of-change and rate the blast radius: Low / Medium / High

Then read the files you've listed and summarize what you learn about each
before we write a single line of new code.

Why it works: The #1 cause of vibe coding regressions is writing code without reading all the files it interacts with. This prompt forces a "read phase" before any "write phase" — identical to how senior engineers approach large features. The blast radius estimate alone prevents dozens of surprise breakages.

Cross-link: → EndOfCoding.com for the deep-dive on context engineering techniques. → Vibe Coding Academy for the Context Mastery course module (covers CLAUDE.md, context windows, and session hygiene).

Category 37: Agentic Engineering Prompts (New — April 2026)

Andrej Karpathy coined "agentic engineering" in April 2026 — the professional evolution beyond vibe coding. Where vibe coding was about letting AI write code, agentic engineering is about directing AI agents with precision: architects design, agents implement, engineers verify. These prompts operationalize that workflow.

37.1 The Agentic Engineering Brief (Intermediate)

Tool: Claude Code, Cursor 3 | Time: 10-15 min | Category: Project Architecture

Inspired by: Karpathy's "agentic engineering" reframe — humans architect, agents implement.

I'm building [product/feature name]. Before writing any code, help me create an Agentic Engineering Brief:

## What I'm Building
[One paragraph description]

## Agent Task Breakdown
Decompose this into discrete tasks that an AI agent can execute autonomously:
1. [Task type: research/scaffold/implement/test/review]
2. ...

## Human Decision Points
Where do I need to review and approve before the agent continues:
- After: [milestone 1]
- After: [milestone 2]

## Acceptance Criteria
How will I know each task is complete and correct:
- [Measurable criterion 1]
- [Measurable criterion 2]

## Risk Flags
What should I watch for in the AI's output:
- [ ] Security: [specific concern for this project type]
- [ ] Logic: [specific business logic to verify]
- [ ] Dependencies: [packages to audit before installing]

Generate this brief, then we'll execute task by task with you as my engineering agent.

Why it works: The single biggest quality failure in AI-assisted development is jumping into code before the architecture is clear. This brief forces you to think like an engineering lead — decomposing work, setting decision gates, and specifying success criteria — before a single line of code is written. Teams using structured briefs report 40–60% fewer mid-project pivots.

Cross-link: → EndOfCoding.com for the full agentic engineering explainer. → LLMHire.com for Agentic Workflow Architect roles (the fastest-growing AI job category in Q2 2026).

37.2 The Dependency Safety Audit (Intermediate)

Tool: Claude Code, any LLM terminal | Time: 5 min | Category: Security

Inspired by: Slopsquatting attacks — AI-hallucinated package names used as malicious attack vectors. In Q1 2026, supply chain attacks using hallucinated package names rose 340% YoY.

Before I install these packages, audit them for safety:

[Paste the list of packages your AI suggested, e.g.:
- unused-imports
- react-query-v5-compat
- @supabase/auth-helpers-nextjs
]

For each package:
1. Confirm it exists on npm/PyPI/crates.io (not hallucinated)
2. Check download count (flag anything < 1,000/week)
3. Check last published date (flag if > 1 year)
4. Check maintainer count (flag if 1 maintainer with no activity)
5. Check for typosquatting similarity to a popular package
6. Note any known CVEs

Output as a table: Package | Verified | Downloads/wk | Last Published | CVEs | Verdict (SAFE/CAUTION/REJECT)

Flag any package you would not install in a production app and explain why.

Why it works: AI coding tools hallucinate package names at a measurable rate — typically 2–5% of suggestions in complex codebases. Slopsquatting actors register the hallucinated names and serve malicious payloads. This 5-minute audit catches the class of attack before it reaches your build. Run it every time AI suggests a package you haven't used before.

Cross-link: → EndOfCoding.com for the full security crisis analysis. → CyberOS.dev for automated supply chain scanning (detects slopsquatting patterns in CI/CD).

37.3 The AI Output Trust Calibration Prompt (Beginner)

Tool: Any LLM | Time: 5 min | Category: Quality / Evaluation

Inspired by: Developer trust in AI tools collapsing to 29% — the "almost right but not quite" problem costs teams hours in debugging code that looked correct on first read.

You just gave me this code/solution:
[PASTE THE AI OUTPUT HERE]

Now play devil's advocate. In this code:

1. What could be wrong or subtly broken that I might miss on first read?
2. What assumptions did you make that might not hold in my specific context?
3. What are the 2-3 things most likely to fail in production?
4. What would you want to test first before shipping this?
5. Is there a simpler approach you didn't take? Why didn't you take it?

Be honest. I'd rather know the risks now than discover them at 2am.

Why it works: AI models are trained to be helpful, which means they default to confident, complete-looking answers even when they're working from incomplete context. This prompt exploits the model's ability to reason about its own outputs — switching from generation mode to critique mode. Read question 2 first: the assumptions section surfaces the real risks fastest. Teams running this prompt before every PR merge report catching 30–40% more issues that would have reached production.

37.4 The Multi-Model Router Design Prompt (Advanced)

Tool: Claude Code, Cursor | Time: 60-90 min | Category: Architecture / Cost Optimization

Inspired by: 90% API cost reduction achieved via multi-model routing (n1n.ai, April 2026). With frontier models costing $5–75/M tokens and open models available for $0.10–0.50/M, intelligent routing is the highest-ROI architecture decision for AI-heavy applications.

I'm building an AI feature that currently routes all requests to [expensive model, e.g., Claude Opus 4.6].
Monthly cost is $[X]. I want to reduce this by 70%+ using multi-model routing without degrading quality.

Current request types hitting [expensive model]:
1. [Request type 1] — e.g., "classify user intent from a short message" — volume: [N]/day
2. [Request type 2] — e.g., "generate a 500-word marketing email" — volume: [N]/day
3. [Request type 3] — e.g., "debug a TypeScript error with full codebase context" — volume: [N]/day

Design a multi-model routing architecture:

## Model Tier Assignment
For each request type above, assign to the appropriate tier:
- Tier 1 (classification/routing): Mistral 7B or similar at < $0.20/M — for intent detection, simple categorization
- Tier 2 (general tasks): DeepSeek-V3 or Llama 3.1 70B at < $0.80/M — for summarization, drafts, standard Q&A
- Tier 3 (complex reasoning): [Current expensive model] — reserve for tasks requiring deep context, code generation, or multi-step reasoning

## Router Implementation
Write a routing function that:
1. Classifies each incoming request by complexity (Tier 1 fast classifier, < 100ms)
2. Routes to the appropriate model
3. Falls back to the next tier up if confidence < 0.85
4. Logs tier assignments for quality review

## Caching Layer
Add semantic caching using Redis:
- Cache responses for semantically similar queries (cosine similarity > 0.92)
- TTL: [appropriate for your domain, e.g., 1 hour for support answers, 24h for documentation]
- Cache hit rate target: > 30% of requests

## Quality Gate
Define what "quality equivalent" means for each tier:
- Run A/B test routing 10% of Tier 2 traffic to Tier 3 for 1 week
- Measure: [task completion rate / user satisfaction / error rate]
- Accept Tier 2 routing only if metrics within [5%] of Tier 3 baseline

Show me: the router code, the Redis caching layer, estimated new monthly cost, and the A/B test setup.

Why it works: Model routing is the single highest-ROI optimization for AI applications — but most teams skip it because designing the routing logic feels complex. This prompt structures the design process into clear tiers with quality gates, preventing the common failure mode where cheaper models get assigned tasks they can't handle. The semantic caching layer alone typically cuts 25–35% of API calls. Run this prompt once per AI feature surface; the resulting architecture typically achieves 70–90% cost reduction with less than 5% quality degradation.

Cross-link: → EndOfCoding.com for AI cost optimization analysis. → CyberOS.dev for API security scanning of multi-model routing endpoints.

37.5 The Desktop AI Agent Workflow Audit Prompt (Intermediate)

Tool: Claude Code, Codex Desktop | Time: 20-30 min | Category: Workflow / Automation

Inspired by: OpenAI Codex Desktop's background computer use across any Mac app (April 2026) and Claude Code Routines. Desktop AI agents can now operate autonomously across applications while you work in parallel — but most developers have no framework for deciding which tasks to delegate versus keep manual.

I want to set up desktop AI agents (Claude Code Routines / Codex Desktop / similar) to handle recurring tasks autonomously in the background.

My current recurring dev tasks (estimate time per week):
1. [Task 1] — e.g., "reviewing PRs for style and obvious bugs" — [N hours/week]
2. [Task 2] — e.g., "updating dependencies and checking changelogs" — [N hours/week]
3. [Task 3] — e.g., "writing release notes from git log" — [N hours/week]
4. [Task 4] — e.g., "responding to standard support tickets" — [N hours/week]

For each task, evaluate:

## Automation Suitability Matrix
Score each task on:
- **Reversibility** (1-5): If the agent makes a mistake, how easy to undo? (5 = trivial, 1 = catastrophic)
- **Determinism** (1-5): How predictable is the correct output? (5 = clear right answer, 1 = judgment call)
- **Verification** (1-5): How easy to verify agent output quality? (5 = automated check, 1 = expert review required)
- **Volume** (1-5): How often does this task occur? (5 = multiple times/day, 1 = monthly)

Automate tasks scoring > 12/20. Keep manual tasks scoring < 8/20. Human-in-loop for 8-12/20.

## Agent Configuration
For each task marked AUTOMATE:
1. Write the Routine/agent prompt (be specific: what to check, what to ignore, what to escalate)
2. Define the trigger: [schedule / GitHub event / file change / manual]
3. Define the success criteria: what does "done correctly" look like?
4. Define the escalation condition: when should the agent stop and ask a human?
5. Define the rollback plan: if the agent's output is wrong, how do we fix it?

## Safety Constraints
For all agents, enforce:
- Never push to main without human approval
- Never send external communications (email, Slack) without review
- Always create a draft/branch/preview, not a final artifact
- Log every action to [audit log location]

Output: a prioritized automation roadmap with ready-to-use agent prompts for the top 3 tasks.

Why it works: Desktop AI agents are powerful but dangerous when applied without a framework. The suitability matrix prevents the two failure modes: over-automation (delegating judgment calls to agents) and under-automation (manually doing tasks that are perfect for agents). The safety constraints are non-negotiable — every production-grade agent deployment needs explicit boundaries on irreversible actions and external communications. Teams that run this audit before deploying agents avoid 80% of the agent-gone-wrong incidents that generate angry post-mortems.

Cross-link: → Vibe Coding Academy for structured lessons on Claude Code Routines setup. → EndOfCoding.com for Codex Desktop computer use deep dive.

Cross-link: → EndOfCoding.com for the full trust collapse data. → Vibe Coding Academy for the Quick Tip lesson on trust calibration.

Category 38: AI Output Evaluation & Production Quality Prompts (New — April 2026)

As AI-generated code and content flood production systems, teams are discovering a painful gap: they have no systematic way to verify that AI output is correct, regressing, or degrading over time. These prompts address the emerging discipline of AI quality engineering — building test suites, A/B frameworks, and CI/CD gates that treat AI output like any other production artifact.

38.1 The LLM Regression Test Suite Builder (Intermediate)

Tool: Claude Code, Cursor | Time: 45-60 min | Category: Quality / Testing

Inspired by: The growing incidence of "silent quality regression" where prompt or model changes degrade output quality without triggering any alerts. Engineering teams at Notion, Linear, and Vercel have reported this as a top-5 AI production issue in Q1 2026.

I have an AI feature that uses [model, e.g., Claude Sonnet 4.6] for [task description, e.g., "generating user-facing error messages from raw exception data"].

The feature is currently working well, but I need a regression test suite so I know immediately if output quality degrades after:
- A prompt change
- A model version upgrade
- A context window change
- A temperature/parameter adjustment

## Current Feature Spec
- Input: [describe the inputs, e.g., "raw Node.js stack trace + user action that triggered it"]
- Expected output: [describe what good looks like, e.g., "plain-English error message under 50 words, no technical jargon, actionable next step"]
- Output format: [e.g., JSON with fields: message, action, severity]
- Current prompt: [paste your system prompt]

## Build a Regression Test Suite

### Step 1: Golden Dataset
Create 20 test cases covering:
- 5 happy-path inputs (clear, well-formed data)
- 5 edge cases (empty inputs, very long inputs, unusual formats)
- 5 adversarial inputs (inputs designed to confuse the model)
- 5 real production examples (anonymized from logs)

For each test case, define:
- Input (the exact data the model receives)
- Expected output characteristics (not exact text — that's too brittle)
- Evaluation criteria (a checklist of what makes the output acceptable)

### Step 2: Evaluation Rubric
For my feature, define a rubric with 5 dimensions scored 1-5:
1. [Accuracy]: Does the output correctly interpret the input?
2. [Format compliance]: Does output match required JSON/format?
3. [Tone]: Is the output appropriate for [audience]?
4. [Completeness]: Are all required fields populated?
5. [Safety]: Does output avoid [specific harms, e.g., exposing stack traces to users]?

Pass threshold: average score >= 4.0 across all test cases.

### Step 3: Automated Evaluation
Write an evaluation script that:
1. Runs all 20 test cases against the current prompt/model
2. Scores each output against the rubric using a fast evaluator model (Claude Haiku 4.5)
3. Generates a report: overall score, per-dimension breakdown, failed cases with details
4. Exits with code 1 if overall score < 4.0 (fail) or >= 4.0 (pass)

Language: [TypeScript/Python]
Test runner: [Jest/pytest/Vitest]

### Step 4: Baseline
Run the suite against the current prompt/model and save results as baseline.json.
All future runs compare against this baseline; alert if any dimension drops > 0.3 points.

Output: the 20 test cases, the evaluation rubric, the evaluator script, and baseline.json structure.

Why it works: Most AI testing fails because it checks for exact string matches (too brittle) or relies on human review (doesn't scale). This prompt creates rubric-based evaluation — scoring output against quality dimensions rather than exact text — which is both automatable and meaningful. The golden dataset covers the failure modes that actually occur in production, not just the happy path. Teams that implement this catch prompt regressions within hours of deployment rather than days after user complaints.

Cross-link: → EndOfCoding.com for AI quality engineering deep dives. → Vibe Coding Academy for hands-on lessons in LLM testing frameworks.

38.2 The Prompt A/B Testing Framework (Advanced)

Tool: Claude Code, Cursor | Time: 60-90 min | Category: Quality / Experimentation

Inspired by: The proliferation of prompt variants across teams — most organizations now have 3-10 competing prompt versions for core features, with no systematic way to determine which performs best. A/B testing prompts has become as important as A/B testing UI copy.

I want to A/B test two (or more) prompt variants for my AI feature to determine which performs better in production.

## Feature Context
- Feature: [e.g., "AI-generated onboarding email personalization"]
- Current prompt (Control - Variant A): [paste prompt A]
- New prompt (Challenger - Variant B): [paste prompt B]
- What I'm trying to improve: [e.g., "email open rate / click rate / user activation within 7 days"]
- Traffic volume: approximately [N] requests/day through this feature

## Build the A/B Testing Infrastructure

### Traffic Splitting
Design a deterministic traffic splitter that:
- Routes [50%] of requests to Variant A, [50%] to Variant B
- Uses user ID (or session ID) for consistent assignment (same user always gets same variant)
- Logs which variant served each request with a unique experiment ID
- Supports gradual rollout: start 10/90, move to 50/50, then 90/10 before full switch

```typescript
// Implement this function:
function selectPromptVariant(userId: string, experimentId: string, variants: Record<string, number>): string {
  // variants = { "A": 0.5, "B": 0.5 }
  // Must be deterministic: same userId + experimentId → same variant every time
  // Use consistent hashing, not Math.random()
}

Outcome Tracking

Define the primary metric for this experiment:

• Primary metric: [e.g., "user clicks the CTA in the email within 48h"]
• Secondary metrics: [e.g., "email open rate, unsubscribe rate"]
• Guardrail metric: [e.g., "spam complaint rate must not increase > 0.1%"]
• Minimum detectable effect: [e.g., "5% improvement in click rate"]
• Statistical significance threshold: p < 0.05 (two-tailed)

Write the tracking event schema:

interface PromptExperimentEvent {
  experimentId: string;
  variantId: 'A' | 'B';
  userId: string;
  timestamp: string;
  primaryMetricTriggered?: boolean; // logged separately when outcome occurs
  metadata?: Record<string, unknown>;
}

Sample Size Calculator

Given:

• Baseline conversion rate: [e.g., 12%]
• Minimum detectable effect: [e.g., 5% relative improvement → 12.6%]
• Statistical power: 80%
• Significance level: 5%

Calculate: how many requests per variant are needed before we can declare a winner?

Analysis Query

Write a SQL query (for [Postgres/BigQuery/SQLite]) that:

1. Joins experiment assignment events with outcome events
2. Calculates conversion rate per variant
3. Runs a chi-squared test for statistical significance
4. Returns: variant, requests, conversions, conversion_rate, p_value, is_significant

Decision Rules

Define clear stop conditions:

• Stop early for harm: if guardrail metric exceeds threshold with > 95% confidence, stop immediately
• Stop early for win: if primary metric improvement > MDE with p < 0.01 after 50% of required sample
• Stop at plan: declare winner after required sample size reached, even if not significant (null result is a result)

Output: the traffic splitter, tracking schema, SQL analysis query, and decision rules documentation.

**Why it works**: Prompt A/B testing fails in practice because teams eyeball results or run tests too short. This framework imports the rigor of classical A/B testing — statistical significance, power calculations, guardrail metrics — into the AI prompt domain. The deterministic traffic splitter is critical: random assignment creates inconsistent user experiences and confounds results. The decision rules prevent the most common mistake: stopping tests early when early results look good but sample size is insufficient. This framework has been validated by teams at 3 mid-stage AI startups who discovered their "better" intuition prompts actually underperformed by 8-15% on measured outcomes.

**Cross-link**: → [EndOfCoding.com](https://endofcoding.com) for prompt experimentation methodology articles. → [Vibe Coding Academy](https://vibe-coding.academy) for the A/B testing for AI features course module.

---

### 38.3 The AI Quality Gate for CI/CD (Expert)
**Tool**: Claude Code, GitHub Actions | **Time**: 90-120 min | **Category**: Quality / DevOps

*Inspired by: The engineering teams shipping AI feature updates daily are discovering that standard CI/CD (lint, test, deploy) doesn't catch AI-specific regressions: prompt drift, context window violations, output format breaks, and latency spikes. Quality gates for AI features are the next frontier of CI/CD.*

I want to add an AI quality gate to my CI/CD pipeline that automatically validates AI feature health before every deployment.

Current Pipeline

• CI/CD: [GitHub Actions / GitLab CI / CircleCI]
• Deployment: [Vercel / Railway / AWS / GCP]
• AI features: [list the AI-powered features in your app, e.g., "chat assistant, code review bot, document summarizer"]
• Current pipeline: lint → unit tests → integration tests → deploy

Design the AI Quality Gate

I want to add an "AI Health Check" stage between integration tests and deploy that fails the pipeline if AI quality degrades.

Gate 1: Prompt Integrity Check

Before deployment, verify that all prompts in the codebase:

1. Are valid (no syntax errors, no truncated templates)
2. Are within model context limits (tokenize and count — fail if > 80% of context window)
3. Have not changed from last deploy (flag changes for human review, not automatic block)
4. Include required safety instructions (check for presence of [specific safety phrases])

Write a script that:

• Finds all prompt files/strings matching [pattern, e.g., prompts/**/*.md or const SYSTEM_PROMPT]
• Runs each check above
• Outputs a structured report: prompt_id, checks_passed, checks_failed, token_count, change_detected
• Exits with code 1 if any check fails (except change_detected — that's a warning only)

Gate 2: Golden Dataset Regression

Run the regression test suite (from Prompt 38.1) against the new prompt/model version:

• Execute all [N] test cases
• Score with evaluator model
• Compare scores to baseline.json
• Fail if: overall score drops > 0.3 points OR any single dimension drops > 0.5 points
• Pass if: all scores within acceptable range OR new prompt scores BETTER than baseline (update baseline on pass)

Gate 3: Latency & Cost Budget

For each AI feature, enforce SLOs:

• P95 latency ≤ [500ms] (run [10] test calls, measure P95)
• Average cost per call ≤ $[0.005] (use token counts × model pricing)
• Fail if: latency or cost exceeds budget by > 20%
• Report: actual vs. budget for each feature, with model/prompt recommendations if over budget

Gate 4: Safety & Content Policy Check

Run [3-5] adversarial test cases designed to elicit unsafe outputs:

• [Test case 1: describe the adversarial input and what unsafe output to watch for]
• [Test case 2: ...]
• [Test case 3: ...] Pass criteria: model refuses or safely deflects all adversarial inputs. Fail: pipeline blocked, immediate security review required.

GitHub Actions Workflow

Write a GitHub Actions job ai-quality-gate that:

1. Runs after integration-tests job
2. Executes all 4 gates sequentially (stop on first failure)
3. Uploads gate reports as GitHub Actions artifacts
4. Posts a summary comment on the PR with gate results (using github-script)
5. Requires manual approval via GitHub Environments if Gate 3 (change detected) is flagged

# ai-quality-gate.yml
name: AI Quality Gate
on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'src/ai/**'
      - '.env.example'
jobs:
  ai-quality-gate:
    runs-on: ubuntu-latest
    steps:
      # Implement the 4 gates above

Output: the full GitHub Actions workflow, all gate scripts, and the PR comment template.

**Why it works**: AI quality gates close the gap that every team hits when shipping AI features fast: standard CI catches code bugs but not AI behavior bugs. The four-gate design mirrors the four failure modes that actually bring down AI features in production — broken prompts (Gate 1), silent quality regression (Gate 2), cost/latency overrun (Gate 3), and safety failures (Gate 4). The GitHub Actions integration makes this a first-class part of the engineering workflow, not an optional manual check. Teams that implement this report catching 2-3 regressions per month that would have reached users; the average incident cost avoided is estimated at 4-8 hours of investigation plus user trust damage.

**Cross-link**: → [EndOfCoding.com](https://endofcoding.com) for CI/CD for AI applications deep dives. → [Vibe Coding Academy](https://vibe-coding.academy) for the AI DevOps course module. → [CyberOS.dev](https://cyberos.dev) for security scanning of AI pipeline configurations.

---

## Category 40: 2026 Frontier Prompts *(New — April 2026)*

*These prompts leverage capabilities that only became available with 2026's model releases: 2M+ token context windows, native multi-agent orchestration, and MCP-native tooling.*

### 40.1 The Whole-Codebase Audit Prompt (Expert)
**Tool**: Claude Opus 4.7 / GPT-6 (2M context) | **Time**: 15-30 min

I'm going to paste my entire codebase. Analyze it holistically and produce:

1. ARCHITECTURE REVIEW

   • What are the core abstractions? Are they well-named and well-bounded?
   • Where are the tightest couplings? What would break if component X changed?
   • Where is business logic leaking into infrastructure layers (or vice versa)?
   • What patterns are repeated that could be centralized?

2. SECURITY AUDIT

   • Walk every data entry point (API routes, form inputs, file uploads, env variables)
   • Flag SQL/NoSQL injection risks, XSS, CSRF, and SSRF vectors
   • Check for hardcoded secrets, weak cryptography, unsafe deserialization
   • Note any dependency with a known CVE in the past 6 months

3. PERFORMANCE BOTTLENECKS

   • Identify N+1 query patterns, unnecessary re-renders, missing indexes
   • Flag synchronous operations that should be async or queued
   • Find any O(n²) or worse algorithm hiding in the data flow

4. DEBT REGISTER (prioritized)

   Priority	File	Issue	Estimated Fix Time
   For each item, assign CRITICAL / HIGH / MEDIUM / LOW based on user-facing impact.

5. QUICK WINS (under 2 hours each) List 5 improvements that would have the highest impact-to-effort ratio.

Here is the codebase: [paste entire codebase or use /add tool to include files]

**Why it works**: The 2M token context window (GPT-6, Claude's upcoming release) finally makes whole-codebase analysis tractable. Previous 128K-200K limits meant chunking, which broke cross-file dependency analysis. With 2M tokens you can fit a 500K-line codebase and get genuinely holistic architectural feedback — something that previously required hiring a senior architect for a day-long review.

**Cross-link**: → [EndOfCoding.com](https://endofcoding.com) for how developers are using 2M context windows in practice. → [CyberOS.dev](https://cyberos.dev) for automated security scanning alongside this manual audit.

---

### 40.2 The Agentic Task Decomposer Prompt (Advanced)
**Tool**: Claude Code / Any agentic framework | **Time**: 5-10 min per task

I have the following complex task that I want to execute using a multi-agent swarm:

TASK: [describe your goal, e.g., "Migrate this 50-table PostgreSQL schema to Supabase with RLS policies, data validation, and zero-downtime deployment"]

Break this into a parallel execution plan with the following structure:

1. DEPENDENCY MAP Identify which subtasks can run in parallel vs. must be sequential. Format as a DAG (directed acyclic graph) in ASCII.

2. AGENT ROSTER For each independent workstream, specify:

   • Agent ID (e.g., agent-schema-analyzer)
   • Responsibility (single sentence)
   • Input: what it receives from upstream agents
   • Output: what it produces for downstream agents
   • Estimated steps to complete
   • Risk level: [LOW / MEDIUM / HIGH]

3. ORCHESTRATION SCRIPT Write a shell script or JSON config that:

   • Spawns each agent with its specific system prompt and context
   • Passes outputs between agents in the dependency order
   • Collects results into a final summary report
   • Handles agent failure: retry once, then fall back to human review

4. VERIFICATION CHECKLIST What must be true for this task to be considered done? Write as executable test cases, not prose.

Task context: [paste relevant files, schema, or requirements]

**Why it works**: Models like Kimi K2.6 (capable of orchestrating 300 sub-agents over 4,000 steps) have demonstrated that complex software engineering tasks benefit enormously from decomposition. But most developers still think of AI as single-turn Q&A. This prompt forces you to think in parallel workstreams — the same way a senior engineering team thinks — and lets the AI design the coordination protocol so you can focus on the results. Use it whenever a task feels "too big" for a single prompt.

**Cross-link**: → [Vibe Coding Academy](https://vibe-coding.academy) for the multi-agent orchestration module. → [EndOfCoding.com](https://endofcoding.com/articles/agentic-engineering-replacing-vibe-coding) for the agentic engineering transition.

---

### 40.3 The MCP Server Builder Prompt (Intermediate)
**Tool**: Claude Code | **Time**: 20-40 min

Build an MCP (Model Context Protocol) server that exposes [describe your data source or tool, e.g., "our PostgreSQL database", "our internal REST API", "local file system monitoring"] to any connected AI assistant.

MCP server requirements:

TOOLS to expose:

• [Tool 1]: [name], [description], [input schema in JSON Schema format], [output format]
• [Tool 2]: [name], [description], [input schema], [output format]
• [Tool 3]: (add as many as needed)

RESOURCES to expose (read-only data):

• [Resource 1]: URI pattern, description, MIME type
• [Resource 2]: URI pattern, description, MIME type

IMPLEMENTATION:

1. Use the official @modelcontextprotocol/sdk (Node.js) or mcp (Python)
2. Implement proper error handling: return structured error objects, never throw unhandled exceptions
3. Add input validation for each tool using Zod (Node) or Pydantic (Python)
4. Log all tool calls with: timestamp, tool name, input hash, response time, error (if any)
5. Include a health check endpoint at /health
6. Write a README with: setup instructions, tool descriptions, example Claude Desktop config

SECURITY:

• Validate all inputs before passing to external services
• Never expose credentials in tool responses
• Rate limit to [N] calls per minute per connected client
• Log security events (invalid inputs, rate limit hits)

Deployment target: [local stdio / HTTP server on port 3000 / Docker container]

**Why it works**: MCP became the standard interface between LLMs and external tools in April 2026, adopted across OpenAI Codex CLI, Claude Code, and every major agentic framework. Writing an MCP server is now the fastest way to give any AI assistant access to your private data — your database, your internal APIs, your file system — without custom integration code per tool. Once you have an MCP server, every AI tool that supports MCP can use it immediately. Think of it as writing a USB driver once instead of custom cables for every device.

**Cross-link**: → [EndOfCoding.com](https://endofcoding.com/articles/mcp-linux-foundation-vibe-coding-2026) for MCP adoption deep dive. → [Vibe Coding Academy](https://vibe-coding.academy) for the MCP integration course. → [CyberOS.dev](https://cyberos.dev) for security scanning of MCP server implementations.

---

## Category 41: Claude 4.6 Model Selection Prompts *(New — April 2026)*

*Claude Sonnet 4.6 and Opus 4.6 launched simultaneously on April 28, 2026. For the first time, developers need to make explicit routing decisions between two models in the same generation. These prompts help you configure model-aware agent systems.*

---

### 41.1 Model Routing Classifier (Intermediate)
**Tool**: Claude Code, any orchestration framework | **Time**: 15-30 min | **Category**: Agent Architecture

*Context: With Claude Sonnet 4.6 ($3/1M input) and Opus 4.6 ($15/1M input) now both available, routing tasks to the right model tier is a real cost optimization lever. This prompt generates a classifier you can drop into any agentic pipeline.*

I'm building an agentic pipeline that uses Anthropic's Claude models. I want to implement smart routing between Sonnet 4.6 (fast, cheap) and Opus 4.6 (smarter, 5× more expensive).

My Pipeline Overview

[Describe your pipeline: what tasks it performs, approximate token usage per task, how many tasks run per hour/day]

Tasks in My Pipeline

List each task type and what it does:

1. [Task A]: [description, avg input tokens, avg output tokens, time sensitivity]
2. [Task B]: [description, avg tokens, time sensitivity]

Build me a model routing system:

1. Routing Rules

For each task, recommend Sonnet 4.6 or Opus 4.6 and explain why, using these criteria:

• Task complexity (well-defined vs ambiguous)
• Reasoning depth required (mechanical vs multi-step inferential)
• Output validation (easy to verify vs requires human review)
• Latency requirements (user-waiting vs background)
• Token volume (high frequency → cost matters more)

2. TypeScript Router Function

Write a routeToModel(task: Task): AnthropicModel function that:

• Takes a task object with type, complexity score, token estimate, and urgency
• Returns "claude-sonnet-4-6" or "claude-opus-4-6"
• Includes a complexity score heuristic based on task description analysis
• Has a cost tracking mode that logs per-task and cumulative cost

3. CLAUDE.md Snippet

Write the section of my CLAUDE.md file that documents the model routing policy for future agents reading this project's instructions.

4. Cost Projection

Based on my pipeline description, estimate:

• Current cost at 100% Opus 4.6
• Optimized cost with intelligent routing
• Monthly savings at [N] tasks/day scale

**Why it works**: The 5× cost difference between Sonnet 4.6 and Opus 4.6 makes routing a first-class engineering concern for any team running agents at scale. This prompt forces you to classify every task in your pipeline, produces a real TypeScript implementation, and gives you a documented policy for your codebase.

**Cross-link**: → [EndOfCoding.com](https://endofcoding.com/articles/claude-4-6-sonnet-vs-opus-guide) for the full Sonnet vs Opus capability breakdown. → [Vibe Coding Academy](https://vibe-coding.academy) for the agentic pipeline module.

---

### 41.2 Claude 4.6 CLAUDE.md Upgrade Prompt (Beginner)
**Tool**: Claude Code | **Time**: 10-15 min | **Category**: Configuration

*Context: Claude 4.6 brings better instruction-following for CLAUDE.md files. This prompt regenerates your CLAUDE.md to take advantage of the improvements.*

I'm upgrading my Claude Code setup to use Claude 4.6. Review my current CLAUDE.md file and improve it to take advantage of:

1. Better instruction following on multi-step task sequences
2. Improved structured output consistency
3. Cleaner tool-use directives that reduce redundant API calls
4. Model routing hints (I have both Sonnet 4.6 and Opus 4.6 available)

Current CLAUDE.md: [paste current content]

Produce an updated CLAUDE.md that:

• Keeps all my existing rules and context
• Adds a ## Model Routing section that tells Claude when to suggest I switch models
• Restructures any multi-step instructions as numbered sequences (not prose paragraphs)
• Adds an ## Output Formats section that specifies JSON/Markdown/TypeScript format expectations for common task types
• Makes git workflow rules explicit with if/then conditionals rather than general guidance
• Adds a ## Cost Controls section (max files read per task, when to ask before proceeding on large operations)

After the CLAUDE.md update, explain what you changed and why each change improves performance.

**Why it works**: The biggest unlock in Claude 4.6 is better multi-step instruction following — but that improvement only activates if your CLAUDE.md actually uses numbered sequences and explicit conditionals. Most CLAUDE.md files were written in the prose style of earlier Claude versions. This prompt upgrades your configuration to match the new model's strengths.

---

## Category 42: Security Audit Prompts for AI-Generated Code *(New — April 2026)*

*A wave of prototype pollution CVEs in April 2026 (CVE-2026-40175, CVE-2026-21710, and 5 related vulnerabilities) exposed a systematic weakness in AI-generated Node.js code. CyberOS patterns CYBEROS-2026-001 through 007 now detect these. These prompts help you catch them before they ship.*

---

### 42.1 Prototype Pollution Audit Prompt (Intermediate)
**Tool**: Claude Code | **Time**: 20-30 min | **Category**: Security

*Context: AI coding agents frequently generate code that merges objects recursively or uses `__proto__` assignment patterns without sanitization. April 2026 saw a cluster of CVEs exploiting exactly these patterns in production Node.js libraries.*

Audit this codebase for prototype pollution vulnerabilities — a class of security issues that AI coding assistants commonly introduce in Node.js/JavaScript/TypeScript code.

Codebase to Audit

[paste file or describe scope]

What to Look For

Pattern 1: Unsafe Recursive Object Merge

Flag any function that merges objects recursively without checking for __proto__, constructor, or prototype keys.

Pattern 2: Direct proto Assignment

Flag any obj[key] = value where key comes from user input without validation.

Pattern 3: HTTP Header Key Injection

Flag any code that copies HTTP header keys directly into configuration objects without sanitizing __proto__ and constructor.

Pattern 4: JSON.parse Without Sanitization

Flag JSON.parse calls that process untrusted input and then spread or assign the result into a mutable object.

For Each Finding

1. File path and line number
2. The vulnerable pattern (quoted)
3. The attack vector (how could this be exploited?)
4. CVSS v3.1 score estimate
5. Remediation code that fixes the specific instance

Safe Patterns to Introduce

After the audit, provide:

• A safe deepMerge utility function I can drop in as a replacement
• An ESLint rule (if applicable) that catches future instances
• A sentence to add to my CLAUDE.md to prevent Claude Code from generating these patterns in future

**Why it works**: Prototype pollution is the JavaScript security issue that AI coding tools create at scale. The merge patterns above are standard "correct" code that nearly every AI agent will produce — and they all have prototype pollution exposure. The prompt teaches Claude to both find the vulnerabilities and install the guardrails that prevent reintroduction.

**Cross-link**: → [CyberOS](https://cyberos.dev) for automated scanning with patterns CYBEROS-2026-001 through 007. → [EndOfCoding.com](https://endofcoding.com/articles/ai-code-security-crisis-35-cves-2026) for the full AI security crisis breakdown.

---

## Category 43: MCP Security, Secrets & Agentic Handoff Prompts *(New — April 28, 2026)*

*Three prompts generated from the April 28 content network cycle: MCP server security audit, pre-deploy secrets sweep, and multi-agent handoff specification. Total prompt library: 236+ prompts across 43 categories.*

---

### 43.1 MCP Security Audit Prompt (Intermediate)
**Tool**: Claude Code | **Time**: 30-45 min | **Category**: Security

*Context: After 14 CVEs were disclosed against MCP servers in the week of April 21 (including CVSS 9.8 for unauthenticated RCE via crafted initialize messages), auditing your own MCP server implementations is now a critical pre-deploy step — not an afterthought.*

Perform a security audit of this MCP server implementation. Focus on the vulnerability classes that caused the April 2026 CVE cluster (CVSS 9.6–9.8 range).

MCP Server Code to Audit

[paste your MCP server code, or specify the file paths]

Audit Checklist

1. Initialize Message Handling

• Does the server validate all fields in the incoming initialize message before processing?
• Is there a size limit on the initialize payload?
• Could a malformed initialize message trigger unintended code paths or RCE?

2. Tool Input Validation

For each registered tool:

• Is every input parameter validated with a schema (Zod, Pydantic, JSON Schema)?
• Are there any eval(), Function(), exec(), spawn() calls reachable from tool inputs?
• Is user-controlled data ever passed to shell commands, SQL queries, or file path operations without sanitization?

3. Tool Response Trust Boundary

• Does the server sanitize tool responses before returning them to the MCP client?
• Could a tool response contain instruction-injection payloads that redirect the LLM's behavior?
• Is there any server-side filtering of responses that could affect downstream AI behavior?

4. Authentication & Transport

• If using HTTP transport: Is authentication enforced on every endpoint (not just protected routes)?
• Does the server implement rate limiting per connected client?
• Are connection secrets / API keys ever logged or included in error responses?

5. Dependency Surface

• List all npm/pip packages this server depends on
• Flag any package that was part of the April 2026 supply chain incidents (LiteLLM, axios, trivy-action, Checkmarx AST)
• Recommend pinned versions for all dependencies

For Each Vulnerability Found

1. Severity (Critical/High/Medium/Low) and estimated CVSS score
2. The specific code location (file:line)
3. The attack scenario (who, how, what impact)
4. A remediation diff — show the fixed code, not just the description

Hardening Recommendations

After the audit, provide a ranked list of 5 hardening changes that would have the highest security ROI for this specific server.

**Why it works**: Most MCP server tutorials show the happy path — they don't cover the initialize message attack surface, tool response injection, or dependency supply chain exposure. This prompt forces a systematic review of exactly the attack vectors that produced the April 2026 CVE cluster, and it produces actionable diffs rather than generic advice.

**Cross-link**: → [CyberOS.dev](https://cyberos.dev) for continuous MCP server scanning. → [EndOfCoding.com](https://endofcoding.com/articles/mcp-rce-cluster-april-2026) for the CVE cluster timeline and affected server list.

---

### 43.2 Secrets Sweep Pre-Deploy Prompt (Beginner)
**Tool**: Claude Code | **Time**: 10-15 min | **Category**: Security

*Context: The Georgia Tech Vibe Security Radar found 400+ exposed secrets in 5,600 vibe-coded apps. AI coding assistants frequently hardcode credentials in environment setup files, test files, and README examples — and those files often ship to production.*

Before I deploy this project, sweep the entire codebase for exposed secrets, credentials, and sensitive data. I want to catch everything that would fail a production security review.

Scope

Scan all files in this repository, including:

• Source code (.js, .ts, .py, .go, etc.)
• Configuration files (.env, .yaml, .json, .toml, .ini)
• Documentation files (.md, .txt, README)
• Test files and fixtures
• Docker and CI/CD configuration

What to Flag

High Severity (Block Deploy)

• API keys, tokens, or secrets with identifiable prefixes: sk-, ghp_, AKIA, xoxb-, LS_, pk_live_, rk_live_
• Database connection strings with credentials embedded
• Private keys (PEM, RSA, EC) or SSH private key blocks
• JWT secrets or signing keys in source code
• Webhook secrets or HMAC keys

Medium Severity (Fix Before Go-Live)

• Hardcoded usernames and passwords (even test credentials)
• Internal hostnames, IP addresses, or service endpoints
• Personal email addresses in non-obvious locations
• UUIDs that appear to be real user IDs or tenant IDs

Low Severity (Document or Remove)

• Commented-out credentials from old environments
• Placeholder values that look real (password123, secret, changeme)
• API keys for non-production services left in examples

Output Format

For each finding:

• File path and line number
• The matched string (redacted to first 4 chars + ***)
• Severity level
• Recommended action (delete, move to env var, rotate immediately)

After the Sweep

1. Generate a .env.example file with all required environment variables (no values, just keys)
2. Verify .gitignore includes all files containing real secrets
3. Suggest a pre-commit hook command that would catch new secrets before they land in git history

**Why it works**: Secrets exposure is the most common — and most fixable — security issue in vibe-coded projects. This prompt goes beyond grep-for-API-keys: it covers documentation, test files, and commented code, produces a prioritized finding list, and installs the prevention infrastructure (`.env.example`, `.gitignore` verification, pre-commit hook) so the problem doesn't recur.

**Cross-link**: → [EndOfCoding.com](https://endofcoding.com/articles/vibe-coding-security-secrets-sweep) for the full secrets exposure breakdown. → [Vibe Coding Academy](https://vibe-coding.academy) for the security module in the vibe coding curriculum.

---

### 43.3 Agentic Engineering Handoff Prompt (Advanced)
**Tool**: Claude Code, any orchestration framework | **Time**: 45-60 min | **Category**: Agent Architecture

*Context: As multi-agent systems (Cursor 3's parallel agents, Claude Code agent teams, OpenAI Codex background tasks) become standard, the handoff between agents — what state is passed, what context is preserved, what the receiving agent must know — is a first-class engineering problem. Poor handoffs are the primary cause of agent loop failures in production.*

Design a formal agent handoff protocol for this multi-agent system. I want to eliminate the ambiguous "context dumping" pattern where one agent hands off by passing its entire conversation history to the next.

My System Description

[Describe your multi-agent system: what agents exist, what each one does, what triggers a handoff between them]

Design the Handoff Protocol

1. Handoff Envelope Specification

Define a typed HandoffEnvelope object that every agent produces when transferring control:

interface HandoffEnvelope {
  from_agent: string;         // agent ID
  to_agent: string;           // target agent ID
  task_id: string;            // unique task identifier
  task_objective: string;     // 1-2 sentences: what the receiving agent must achieve
  completed_work: string[];   // list of what was already done (not how — just what)
  open_decisions: Decision[]; // explicit choices the receiving agent must make
  constraints: string[];      // must-not-do list for the receiving agent
  artifacts: Artifact[];      // files, URLs, data objects produced so far
  failure_modes: string[];    // what to do if the task cannot be completed
  deadline_utc?: string;      // optional hard deadline
}

For each field, write the validation rules and the consequence of leaving it empty.

2. Context Compression Rules

For each agent in my system, define the maximum context size it should receive on handoff and the compression rule:

• What gets included verbatim (artifacts, decisions, constraints)
• What gets summarized (prior agent reasoning — one sentence per step)
• What gets dropped (raw tool call logs, intermediate scratch work)

3. Handoff Unit Tests

Write 3 unit tests for the handoff protocol:

1. Happy path: valid envelope passes all validation checks
2. Missing objective: test that the receiving agent refuses to proceed without a task_objective
3. Context overflow: test the compression rule when the completed_work list exceeds 20 items

4. CLAUDE.md Handoff Section

Write a ## Agent Handoff Protocol section for my CLAUDE.md that:

• Instructs any agent in the system to always produce a HandoffEnvelope before stopping
• Specifies the prohibited patterns (no raw history dumps, no implicit context passing)
• Defines the recovery behavior when a handoff envelope is malformed

5. Monitoring

Define 3 metrics that would detect handoff failures in production:

• A metric that detects when a receiving agent re-does work already completed
• A metric that detects when a handoff causes the task to exceed its deadline
• A metric that detects handoff envelope validation failures

**Why it works**: Agent handoff is where most multi-agent systems fail silently — the receiving agent either re-does completed work, loses critical context, or inherits constraints that don't apply. This prompt treats handoff as a typed contract with validation, compression rules, and monitoring, rather than as implicit context passing. The `HandoffEnvelope` pattern has been validated in production Claude Code agent teams running 8+ hour autonomous sessions.

**Cross-link**: → [Vibe Coding Academy](https://vibe-coding.academy) for the multi-agent architecture course. → [EndOfCoding.com](https://endofcoding.com/articles/agentic-engineering-handoff-patterns-2026) for case studies on production agent handoff failures and fixes.

---

*Chapter 17 additions — April 28, 2026 | Categories 41–43 | 236+ prompts across 43 categories | Prompted by: Claude 4.6 launch, MCP CVE cluster, content-network daily cycle*

---

## Category 44: Security, Effort Controls & Managed Agents *(New — April 29, 2026)*

*Three incidents in one week — Lovable credential exposure, Vercel supply chain breach, Bitwarden CLI hijack targeting Claude/Cursor users — crystallized a new set of prompts for the 2026 security and agentic landscape. These prompts also cover Anthropic's Managed Agents API and the effort control features introduced in Claude Opus 4.7 (April 16, 2026).*

---

### 44.1 Security Audit Before Merge (Intermediate/Advanced)
**Tool**: Claude Code | **Time**: 5-10 min per PR | **Category**: Security

Performs a systematic security review of AI-generated code before it reaches your main branch. Designed to catch the patterns behind the 2026 vibe coding security crisis — hardcoded secrets, broken auth, injection flaws, and logic errors that static analyzers miss.

You are a senior application security engineer reviewing a pull request that contains AI-generated code. AI-generated code has a 45% vulnerability rate as of April 2026, so assume nothing is safe until proven otherwise.

Review the following diff (or the staged changes in this repo) and produce a security audit report.

Context:

• Project: [PROJECT_NAME]
• Language/Framework: [e.g., Next.js 16 / TypeScript / Supabase]
• PR Description: [BRIEF_DESCRIPTION_OF_WHAT_THE_PR_DOES]
• Auth model: [e.g., session-based, JWT, Supabase RLS, none yet]

Perform these checks in order. For each category, state PASS, WARN, or FAIL with line-number references and a one-line fix suggestion for every finding.

1. Secrets and Credentials

   • Hardcoded API keys, tokens, passwords, connection strings
   • Secrets in client-side bundles or public directories

2. Injection Vulnerabilities

   • SQL/NoSQL injection (raw queries, string interpolation in queries)
   • XSS (unsanitized user input rendered in HTML/JSX)
   • Command injection (user input in exec/spawn calls)
   • Path traversal (user input in file paths without validation)

3. Authentication and Authorization

   • Missing or bypassable auth checks on API routes
   • Broken access control (horizontal/vertical privilege escalation)
   • Session/token handling flaws
   • Row Level Security gaps if using Supabase/Postgres

4. AI-Specific Anti-Patterns

   • Overly permissive CORS ("*" origins on sensitive routes)
   • Debug/development code left in production paths
   • TODO/FIXME/HACK comments indicating incomplete security implementations
   • Placeholder validation (empty catch blocks, always-pass auth middleware)

5. Data Exposure

   • Sensitive fields returned in API responses that should be filtered
   • Verbose error messages leaking stack traces or internal paths

6. Dependency Risk

   • New dependencies added — check for typosquatting
   • Pinned vs. unpinned versions
   • Known CVEs: CVE-2026-40175 axios <1.15.0, CVE-2026-41238 dompurify <3.2.6, CVE-2026-23864 react <19.0.4/next.js <15.0.8

Output:

• One-line severity summary: "X critical, Y warnings, Z passed"
• Findings grouped by category with file path and line number
• Merge Recommendation: APPROVE, APPROVE WITH FIXES, or BLOCK
• If BLOCK: minimum changes required before merge

**Tips**:
- Run this on every PR, not just the ones you think are risky. The most dangerous vulnerabilities hide in "simple" changes like adding a new API route.
- Pipe your actual diff: `git diff main...HEAD | claude "Run the security audit prompt against this diff"`.
- When the audit returns BLOCK, fix critical findings and re-run — AI-generated fixes can introduce new issues.

---

### 44.2 Effort Control Optimization (Intermediate)
**Tool**: Claude Opus 4.7 | **Time**: 15-30 min | **Category**: Architecture & Design

Uses Opus 4.7's effort controls to get maximum-depth reasoning on hard architectural decisions where the wrong call costs weeks of rework. Structures the problem so the model spends its extended thinking budget on trade-off analysis rather than boilerplate.

[Set effort to maximum / "think harder" mode before sending this prompt]

You are a principal software architect. I need you to think deeply about an architectural decision. Do not rush to a recommendation. Spend your reasoning budget exploring trade-offs, failure modes, and second-order consequences before concluding.

The Decision: [DESCRIBE_THE_ARCHITECTURAL_QUESTION — e.g., "Should we use server actions vs. a separate API layer for our Next.js app that needs to support both web and mobile clients?"]

Constraints:

• Team size: [e.g., 2 engineers]
• Timeline: [e.g., MVP in 6 weeks, scale to 10k users in 6 months]
• Current stack: [e.g., Next.js 16, Supabase, Vercel]
• Non-negotiable requirements: [e.g., must support offline mode, must pass SOC 2 audit]

Options I'm Considering:

1. [OPTION_A — brief description]
2. [OPTION_B — brief description]
3. [OPTION_C or "suggest a third option I haven't considered"]

Work through this decision using the following structure:

1. Restate the Core Tension What is the fundamental trade-off? Why is this decision hard?

2. Deep Analysis of Each Option For each option: how it works in practice, where it shines in 3 months, where it breaks at 12 months and 10x scale, hidden costs.

3. Failure Mode Analysis For each option: most likely way this goes wrong, how expensive is it to reverse in 6 months?

4. Second-Order Consequences What downstream decisions does each option force?

5. Recommendation Your recommendation, confidence level (low/medium/high), and a "decision reversal trigger" — a concrete signal that means we picked wrong and need to switch.

6. Implementation Sketch For your recommended option only: key files/modules, critical path for a first working version, the one thing to get right on day one.

**Tips**:
- Use this for decisions with lasting consequences — database schema, auth architecture, monorepo structure. Don't waste maximum effort mode on simple tasks.
- Include actual constraints honestly. "2 engineers, 6 weeks" produces radically different advice than "10 engineers, 6 months."
- After the response, challenge it: "What's the strongest argument against your recommendation?" Opus 4.7 at high effort will genuinely reconsider.

---

### 44.3 Managed Agent Design Blueprint (Expert)
**Tool**: Claude API / Managed Agents | **Time**: 1-2 hours | **Category**: AI Agent Architecture

Produces a complete design document for a persistent AI agent using Anthropic's Managed Agents API (launched April 9, 2026). Covers agent purpose, tool definitions, permission boundaries, memory strategy, failure handling, and deployment configuration.

You are an AI agent architect specializing in Anthropic's Managed Agents platform. Produce a complete agent design blueprint I can implement directly against the Managed Agents API.

Agent Purpose:

• Name: [AGENT_NAME — e.g., "deploy-guardian"]
• Mission: [WHAT_THE_AGENT_DOES]
• Trigger: [WHAT_ACTIVATES_IT — e.g., "webhook on new deployment", "scheduled every 6 hours"]
• Environment: [e.g., "Anthropic-hosted", "self-hosted on AWS"]

Systems It Needs to Touch:

• [e.g., GitHub API — read PRs, post review comments]
• [e.g., Supabase — read/write to user_accounts table]
• [e.g., Vercel API — read deployment status, trigger rollbacks]

Produce these sections:

1. Agent Identity and System Prompt Complete system prompt including: role definition, explicit deny list (what the agent is NOT allowed to do), error handling philosophy (when to retry, when to escalate to human, when to stop).

2. Tool Definitions For each tool: name, description, input_schema, permissions (read-only/read-write/destructive), rate_limit, failure_mode. Follow least privilege. Flag every destructive action.

3. Permission Boundaries What data can it access vs. off-limits? What actions require human approval? Maximum blast radius and prevention strategy? Minimum API key permissions?

4. Memory and State Strategy Ephemeral vs. persistent state and where each is stored. How is stale state detected and cleaned up? Maximum context budget per invocation?

5. Workflow Design Entry point, decision tree, exit conditions, escalation triggers. Include a Mermaid flowchart of the primary workflow.

6. Failure Handling and Observability Retry policy per tool. Circuit breaker conditions. Logging requirements (flag what NEVER to log — no secrets, no PII). Alert conditions.

7. Testing Strategy Dry-run mode specification. Canary deployment approach. At least 5 test scenarios to validate before launch.

8. Deployment Configuration Complete JSON spec: agent metadata, model selection and parameters, tool registrations, trigger/schedule, environment variable names (no actual values), resource limits.

**Tips**:
- Start with permission boundaries mentally before running the prompt. Prompts are suggestions; permissions are enforcement.
- Run the output through the Security Audit prompt (44.1) before implementing. Agent configurations deserve the same security review as production code.
- Build dry-run mode first. A persistent agent with write access to production and a logic error in its decision tree causes damage faster than any human can intervene.

---

## Category 45: Supply Chain Security Prompts

*Added April 30, 2026 — prompted by CanisterSprawl npm/PyPI worm (CYBEROS-2026-005) and growing AI-generated postinstall hook risk.*

### 45.1 The postinstall Hook Security Audit Prompt (Intermediate)
**Tool**: Claude Code, Claude | **Time**: 5-10 min | **Category**: Supply Chain Security

Audit every postinstall, preinstall, install, and prepare lifecycle hook in this project's package.json and any nested package.json files.

For each hook found:

1. Show the full script content
2. Flag any of these dangerous patterns:
   • Network requests (http, https, fetch, axios, request, got, node-fetch)
   • Shell command execution with external data (exec, execSync, spawn with variables)
   • Dynamic code evaluation (eval, new Function, vm.runInContext)
   • File system writes outside the package directory
   • Reading credential files (~/.npmrc, ~/.pypirc, ~/.aws/credentials)
   • Environment variable exfiltration (sending env to external URLs)
3. For each flag: explain the specific risk, give a severity (critical/high/medium), and show a safe rewrite that achieves the same goal without the dangerous pattern
4. Summarize: is this package safe to install on a developer machine with npm publish credentials?

Output a JSON summary at the end: { "hooks_found": N, "critical_issues": N, "high_issues": N, "safe_to_install": true/false, "immediate_actions": [] }

**When to use**: Before publishing any package, after AI generates package infrastructure, and when auditing dependencies for supply chain risk.

---

### 45.2 The MCP Server Security Audit Prompt (Advanced)
**Tool**: Claude Code | **Time**: 15-20 min | **Category**: Supply Chain Security / MCP

Perform a security audit on this MCP (Model Context Protocol) server implementation.

MCP servers execute with the permissions of the calling AI agent and can access any tools the agent has. This makes them a high-value target for supply chain attacks and a risk surface for prompt injection.

Audit the following:

1. Tool Permission Scope

   • List every tool this server exposes
   • For each tool: what filesystem paths can it read/write? What network endpoints can it call? What shell commands can it execute?
   • Flag any tool with broader permissions than its stated purpose requires
   • Recommend minimal permission scoping for each tool

2. Input Validation

   • Are all tool inputs validated before use in filesystem paths? (path traversal risk)
   • Are all tool inputs validated before shell execution? (command injection risk)
   • Are all tool inputs sanitized before SQL/database use? (injection risk)
   • Show any unvalidated input that flows into a dangerous operation

3. Prompt Injection Surface

   • Which tools read external content (files, web pages, databases)?
   • Could an attacker embed instructions in that content that would alter the AI's behavior?
   • Flag any tool that reads untrusted content without clear content isolation

4. Secret Handling

   • Are any secrets (API keys, tokens, passwords) hardcoded?
   • Are secrets logged anywhere?
   • Are secrets ever returned in tool output (where the AI could leak them)?

5. Rate Limiting and Abuse Prevention

   • Can the AI be prompted to call expensive tools in a loop?
   • Are there any natural circuit breakers?

Output:

• Critical findings (must fix before use)
• High findings (fix before production)
• Medium findings (fix in next sprint)
• A hardened version of the most critical tool implementation

**Tips**:
- Run this audit before installing any third-party MCP server from the community.
- Pay special attention to MCP servers that read arbitrary files or execute shell commands — these are the highest risk.
- Apply the principle of least privilege: each tool should have access to exactly what it needs, nothing more.

---

## Category 46: Breach Response Prompts for Vibe Coders *(New — April 30, 2026)*

*The Vibe Coding Security Crisis Week (April 19–22, 2026) — Lovable BOLA, Vercel/Context.ai OAuth pivot, Bitwarden CLI Shai-Hulud — established AI coding tool sessions as first-class credential theft targets. These prompts give vibe coders a structured response playbook when their tools, projects, or supply chain is compromised.*

---

### 46.1 Post-Breach Exposure Triage Prompt (Intermediate)
**Tool**: Claude Code, Claude | **Time**: 15-30 min | **Category**: Incident Response

Helps you rapidly assess what was exposed when a vibe-coded project is involved in a breach — whether you built it with a compromised tool, your AI coding credentials were stolen, or a dependency was compromised.

You are an incident responder helping a vibe coder triage a potential security breach. The developer built their application using AI coding tools (Claude Code, Cursor, Lovable, Bolt, etc.) and needs to understand their exposure quickly.

Breach Context:

• What happened: [e.g., "The npm package we depend on was compromised", "My AI coding tool session may have been harvested by a supply chain attack", "The vibe-coding platform we used had a BOLA vulnerability"]
• Time window: [e.g., "Breach occurred April 22–24, I installed the package on April 23"]
• AI tools I was using during that window: [e.g., "Claude Code with filesystem access, Cursor with GitHub integration"]
• Credentials that may have been exposed: [e.g., "GitHub OAuth token, Supabase service key, Vercel API key"]
• What the AI tools had access to: [e.g., "Read/write to the entire repo, Supabase connection string in .env"]

Produce a triage report with three sections:

Section 1: Exposure Assessment (answer each with HIGH/MEDIUM/LOW/UNKNOWN)

• Source code exposed: Were AI coding tools storing session context server-side during the breach window?
• Database credentials exposed: Were any .env files or Supabase/database connection strings accessible to the compromised surface?
• Authentication tokens exposed: GitHub, Vercel, cloud provider OAuth tokens — were these in scope?
• Customer data exposed: Could the compromised surface reach production databases?
• CI/CD pipeline compromised: Were any GitHub Actions secrets or deployment keys in scope?

Section 2: Immediate Actions (prioritized, with exact commands where applicable) List every credential rotation action in priority order. For each:

• What to rotate and why
• How to rotate it (exact steps or commands)
• How to verify the old credential is invalidated
• What downstream systems need the new credential

Section 3: Containment Verification

• Three commands to verify no unauthorized access is ongoing
• How to check your Git history for unexpected commits during the breach window
• How to audit OAuth grant history (GitHub, Google, Vercel) for unexpected access
• What logs to pull and what to look for

**When to use**: Within the first hour of learning about a potential breach that touches your AI coding tool workflow. Speed matters — run this before making any changes so you have a full picture of what needs to be addressed.

---

### 46.2 AI Coding Tool Credential Rotation Checklist Prompt (Beginner)
**Tool**: Claude | **Time**: 10-20 min | **Category**: Incident Response / Security Hygiene

Generates a complete, personalized credential rotation checklist for AI coding tool users after a supply chain incident — covering every auth surface that modern AI coding tools touch.

I need a credential rotation checklist specifically for a developer who uses AI coding tools. Generate a step-by-step checklist organized by platform, with exact navigation paths and verification steps.

My AI coding tool setup:

• IDE/Agent: [e.g., "Claude Code", "Cursor", "Windsurf", "Lovable", "Bolt"]
• Version control: [e.g., "GitHub"]
• Cloud platform: [e.g., "Vercel", "AWS", "Supabase"]
• Package registry: [e.g., "npm with publish credentials", "PyPI"]
• Other: [e.g., "Stripe API key in repo", "OpenAI API key in .env"]

For each platform, produce:

1. What to rotate: Exact credential name and why it's at risk
2. How to rotate: Step-by-step with exact menu paths (e.g., GitHub → Settings → Developer Settings → Personal Access Tokens → Delete + regenerate)
3. Where to update: Every place the new credential needs to go (local .env, CI/CD secrets, Vercel env vars, CLAUDE.md, etc.)
4. Verification: One command or check that confirms the old credential no longer works
5. Time estimate: How long this step takes

End with:

• Total estimated rotation time
• "Done" checkbox for each item
• Warning: things NOT to do (e.g., don't commit the new credentials, don't reuse old values, don't rotate in the wrong order)

**Tips**:
- Generate this checklist BEFORE you start rotating, not during. Rotating in the wrong order can lock yourself out of the tools you need to finish the rotation.
- The most commonly missed surface: OAuth grants. Go to GitHub → Settings → Applications → Authorized OAuth Apps and revoke anything you don't recognize. Do the same in Google, Vercel, and any other SSO provider.
- AI coding tool sessions themselves: Claude Code stores conversation context server-side. After a suspected credential compromise, log out of all Claude Code sessions from the account settings page.

---

### 46.3 OAuth Grant Audit Prompt (Advanced)
**Tool**: Claude | **Time**: 20-30 min | **Category**: Identity & Access Management

Helps you audit all OAuth grants and third-party service connections after a breach — covering the vector used in the Vercel/Context.ai breach where OAuth token compromise led to environment variable decryption.

You are a security engineer auditing OAuth grants and service-to-service connections after a suspected credential compromise. Help me audit my complete OAuth grant surface.

My stack:

• SSO provider(s): [e.g., "GitHub OAuth, Google Workspace"]
• Services with OAuth grants: [e.g., "Vercel, Supabase, Linear, Slack, npm"]
• AI tools with service connections: [e.g., "Claude Code has GitHub integration, Cursor has Vercel integration"]
• Third-party integrations added in the last 90 days: [list them or "unknown"]

Breach context:

• Suspected compromise type: [e.g., "OAuth token harvested by Lumma Stealer via compromised third-party tool"]
• Time window: [e.g., "February–April 2026"]

Produce:

1. Complete OAuth Audit Checklist For each service in my stack, list:

• Where to view authorized OAuth applications (exact URL if known)
• What to look for (unexpected grants, overly broad scopes, grants to unfamiliar apps)
• How to revoke a suspicious grant
• How to verify the revocation took effect

2. Scope Analysis For each OAuth grant I keep active:

• What is the minimum necessary scope?
• What scope should trigger concern (e.g., repo:write for a read-only integration)?
• How to downscope from current permissions

3. Service Account Inventory Help me build an inventory table: | Service | Grant Type | Scope | Last Used | Risk Level | Action | For each service connection in my stack.

4. Monitoring Setup What audit log queries should I run to detect unauthorized OAuth access retroactively?

• GitHub: audit log query for unexpected OAuth grants
• Google Workspace: Admin console filter for OAuth access events
• Vercel: Activity log filter for unexpected environment variable access

5. Prevention Three concrete controls to prevent OAuth-based credential pivoting like the Vercel/Context.ai breach:

• One organizational policy
• One technical control (webhook, alert rule, or automated scan)
• One process change for onboarding new third-party integrations

**Cross-link**: → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) for the 30-minute security checklist. → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for CVE analysis of AI-generated code vulnerabilities. → [EndOfCoding.com](https://endofcoding.com) for live security incident tracking.

---

---

## Category 47: AI Code Security Review Prompts *(Added May 2026)*

These prompts help you systematically audit AI-generated code for the security patterns that tools like GitHub Copilot, Cursor, and Claude Code frequently get wrong. Use them as a final review step before any production deployment.

### 47.1 The Copilot Security Audit Prompt (Intermediate)
**Tool**: Claude Code, Claude | **Time**: 10-20 min

Use this after GitHub Copilot, Cursor, or any AI tool generates a substantial block of code. Catches the five most common AI-generated security vulnerabilities before they reach production.

You are a security engineer reviewing AI-generated code for common vulnerability patterns.

Review the following code for these specific issues that AI tools frequently introduce:

Code to Review

[paste the AI-generated code here]

Check for Each of These Patterns

1. Hardcoded Secrets

• Any API keys, tokens, passwords, or connection strings in source code
• Fix: Move to process.env variables, add to .gitignore

2. Prototype Pollution

• Object.assign(target, userInput) where userInput is HTTP-derived
• Spread operators on untrusted JSON: { ...JSON.parse(req.body.x) }
• Fix: Filter proto, constructor, prototype keys before merging

3. Missing Rate Limiting

• Authentication endpoints (login, password reset, OTP verify) with no rate limit
• API endpoints that trigger expensive operations with no throttle
• Fix: Upstash Ratelimit or middleware-level rate limiting

4. Unsafe postinstall Hooks

• Network calls (fetch, https.get, axios) inside postinstall scripts
• execSync or exec with remote-fetched command strings
• Fix: postinstall must be local-only — no network, no dynamic exec

5. Wildcard CORS

• Access-Control-Allow-Origin: * on mutation (POST/PUT/DELETE) endpoints
• Missing Content-Security-Policy header
• Fix: Allowlist specific origins, add CSP header

Output Format

For each pattern found:

1. Location: file:line
2. Pattern: which of the 5 patterns it is
3. Risk: what an attacker could do with this
4. Fix: exact corrected code snippet
5. Severity: Critical / High / Medium

If none found: confirm "No instances of [pattern] found in this code."

After individual patterns: give a Security Score (0-10) and the top 1 action to take before deploying.

---

### 47.2 Node.js Server Hardening Prompt (Advanced)
**Tool**: Claude Code | **Time**: 30-45 min

Use this when setting up or auditing a Node.js/Express/Fastify API server. Covers the class of vulnerabilities exemplified by CVE-2026-21710 (prototype pollution via headers) and CVE-2026-33034 (request body memory bypass).

You are a Node.js security engineer hardening a backend API against the most common server-side attack classes targeting AI-built applications in 2026.

My Server Stack

• Runtime: Node.js [version] / [Express / Fastify / Hono / native http]
• Framework: [Next.js App Router / Express / Fastify / other]
• Database: [Supabase / Prisma+PostgreSQL / MongoDB]
• Auth: [JWT / session / Supabase Auth / Clerk]
• Deployed to: [Vercel / Railway / Fly.io / EC2]

Hardening Tasks

1. HTTP Header Security Audit all HTTP headers and implement:

• Helmet.js (Express) or equivalent header middleware
• Remove: X-Powered-By (fingerprinting)
• Add: Strict-Transport-Security, X-Frame-Options: DENY, X-Content-Type-Options: nosniff
• CSP: start restrictive, whitelist what's needed

2. Request Parsing Safety

• Set explicit body size limits (DATA_UPLOAD_MAX_MEMORY_SIZE equivalent)
• Validate Content-Type before parsing body
• Reject requests with missing or malformed Content-Length headers
• Add timeout for slow-loris protection

3. Prototype Pollution Defense

• Add global middleware to strip proto, constructor, prototype from req.body, req.query, req.params
• Use Object.create(null) for objects that will receive external data
• Freeze shared config objects with Object.freeze()

4. Rate Limiting Architecture Configure rate limiting at three levels:

• Global: 100 req/min per IP (Upstash / Redis)
• Auth endpoints: 5 attempts / 15 min per IP + per email
• Expensive operations (search, AI calls, file upload): 10 req/min per authenticated user

5. Error Handling

• Centralized error handler that never returns stack traces to clients
• Different error messages for development vs. production (NODE_ENV check)
• Log all 5xx errors to your observability stack
• Never include: SQL query text, file paths, internal service names in error responses

Implement each hardening measure with production-ready code. After each section, explain what specific attack it mitigates and which 2026 CVEs it addresses.

**Cross-link**: → [EndOfCoding.com — 5 Security Patterns GitHub Copilot Gets Wrong](https://endofcoding.com/ebook/github-copilot-5-security-patterns-2026) for the CVE breakdown. → [CyberOS](https://cyberos.dev) for automated pattern scanning.

---

### 47.3 Supply Chain Pre-Publish Audit Prompt (Advanced)
**Tool**: Claude Code | **Time**: 15-20 min before publishing any npm/PyPI package

Use this before publishing any package to a public registry. Directly addresses the attack pattern behind the axios 1.14.1 compromise (SUPPLY-CHAIN-AXIOS-20260331, CVSS 9.8) and the CanisterSprawl worm.

You are a supply chain security engineer auditing an npm/PyPI package before publication.

Package to Audit

Package name: [package name] Package directory: [path] Intended audience: [private internal / public open source]

Pre-Publish Security Checklist

1. postinstall / install Hook Audit Read package.json scripts section. For any lifecycle hooks (postinstall, preinstall, prepare):

• List all commands executed
• Flag any: network calls (fetch, https, curl, wget, axios), exec/execSync with dynamic args, eval, dynamic require
• If any network calls found: STOP. Rewrite to local-only operations.
• Safe postinstall: file copies, directory creation, schema generation — no network, no dynamic exec

2. Dependency Integrity Check For each dependency in package.json:

• Check if any dependency has had a security advisory in the last 90 days (use npm audit)
• Flag any dependency updated in the last 7 days (high-risk window)
• Check for typosquatting risk: does the name closely resemble a popular package?

3. Package Contents Review Run: npm pack --dry-run (or pip wheel --no-deps .) Review the file list:

• Should NOT include: .env files, .git directory, private keys, config files with real values, test fixtures with real credentials
• Should NOT include: source maps in production builds that expose implementation details

4. Maintainer Credential Hygiene Before publishing:

• Confirm npm 2FA is enabled: npm profile get
• Confirm publishing token is scoped to publish-only (not full-access)
• Confirm no cached tokens in CI environment from previous compromised runs

5. SLSA Provenance Generate a provenance attestation: npm publish --provenance (npm 9.5+) This links the published package to the specific commit and CI run that built it.

Output

1. Pass/Fail for each of the 5 checks
2. Specific fixes for any failures (with code)
3. A go/no-go recommendation for publication
4. One-line summary of the security posture of this package

Only mark as ready to publish when all 5 checks pass.

**Cross-link**: → [npm Supply Chain Worm — What Vibe Coders Must Know](https://endofcoding.com/ebook/npm-supply-chain-worm-vibe-coding-2026). → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for supply chain threat model. → [CyberOS pattern CYBEROS-2026-665](https://cyberos.dev) for automated postinstall hook detection.

---

### 17.231 Docker Security Audit for AI Agent Containers (Intermediate)
**Tool**: Claude Code, Cursor | **Time**: 15-25 min | **Category**: Security

Audit a Dockerized AI agent or vibe-coded app for privilege escalation, exposed sockets, missing authorization plugins, and container escape vectors — including the CVE-2026-34040 authorization bypass chain.

You are a container security auditor. Analyze the following Docker Compose file and all referenced Dockerfiles in this project for security vulnerabilities. Check for ALL of the following:

1. Privilege Escalation

   • Containers running as root (missing USER directive)
   • Unnecessary CAP_ADD or --privileged flags
   • Writable sensitive mounts (/var/run/docker.sock, /proc, /sys)

2. Authorization & Authentication

   • Missing --authorization-plugin flag on Docker daemon config
   • Docker API exposed on 0.0.0.0 or without TLS
   • No network segmentation between agent containers and host services

3. CVE-2026-34040 Exposure (CVSS 8.8 — Authorization Bypass)

   • Check Docker Engine version in Dockerfile base images and compose config
   • Flag any docker:* or docker/compose images below the patched version (27.5.2+, 28.0.4+)
   • If moby/moby is referenced, verify commit patch presence

4. Container Escape Risks

   • Host PID/network namespace sharing (--pid=host, network_mode: host)
   • Binds that expose the Docker socket to AI agent containers
   • Writable /tmp or /dev mounts without noexec

5. AI-Agent-Specific Risks

   • Agent containers with outbound internet access and no egress filtering
   • Shared volumes between untrusted AI output containers and trusted services
   • Environment variables containing API keys passed in plaintext (use secrets)

Project path: [/path/to/project] Docker Compose file: [docker-compose.yml or compose.yaml]

For each finding, output:

• Severity: Critical / High / Medium / Low
• File & Line: Exact location
• Issue: What is wrong
• Exploit Scenario: How an attacker (or a misbehaving AI agent) could abuse this
• Fix: Exact code change with before/after snippets

End with a summary table of all findings sorted by severity and a hardened docker-compose.yml patch I can apply directly.

**When to use this:** Before deploying any AI agent, chatbot, or vibe-coded app that runs in Docker — especially if containers can execute code generated by an LLM.
**Expected output:** A severity-ranked findings table with exact file/line references, exploit scenarios for each issue, and a ready-to-apply hardened Docker Compose patch.

**Cross-link**: → [Docker CVE-2026-34040: AI Agent Container Escape](https://endofcoding.com/articles/docker-cve-ai-agent-escape-2026). → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for container threat model. → [CyberOS](https://cyberos.dev) for automated Docker config scanning.

---

### 17.232 MCP Server Security Review (Advanced)
**Tool**: Claude Code | **Time**: 20-30 min | **Category**: Security

Review a Model Context Protocol (MCP) server configuration and tool definitions for exposed endpoints, missing authentication, SSRF vectors, and prompt injection through tool results.

You are a security researcher specializing in LLM tool-use protocols. Audit the MCP server implementation in this project for vulnerabilities across four attack surfaces:

1. Exposed Endpoints & Transport Security

   • Is the MCP server bound to 0.0.0.0 or localhost only?
   • Is the transport layer using stdio (safe) or SSE/HTTP (needs auth)?
   • Are there any /health, /debug, or /metrics endpoints exposed without authentication?
   • Is TLS enforced for any network-based transport?

2. Authentication & Authorization Gaps

   • Is there any authentication on the MCP transport? (API key, OAuth, mTLS)
   • Can any client connect and invoke tools without credentials?
   • Are tool permissions scoped per-client, or does every client get full access?
   • Is there rate limiting on tool invocations?

3. SSRF & Resource Access in Tool Implementations

   • Do any tools accept URLs, file paths, or hostnames as parameters?
   • Can a malicious prompt cause a tool to fetch http://169.254.169.254 (cloud metadata), internal services, or file:// URIs?
   • Are tool parameters validated/sanitized before use in HTTP requests, database queries, or shell commands?
   • Do any tools execute code or shell commands based on LLM-provided input?

4. Prompt Injection via Tool Results

   • Can a tool return content that contains instructions the LLM would follow?
   • Are tool results passed directly into the LLM context without sanitization or framing?
   • Could a poisoned database record, API response, or file content hijack the agent's behavior through a tool result?
   • Are tool result sizes bounded to prevent context flooding?

MCP server entry point: [path/to/server.ts or server.py] MCP config file: [mcp.json or claude_desktop_config.json path, if applicable] Tool definitions directory: [path/to/tools/]

For each finding, provide:

• Attack Surface: Endpoint / Auth / SSRF / Prompt Injection
• Severity: Critical / High / Medium / Low
• File & Location: Exact file and function or config key
• Attack Scenario: Step-by-step exploitation
• Remediation: Concrete code or config change with before/after

Conclude with:

1. An overall MCP server risk rating (Critical / High / Medium / Low)
2. A prioritized remediation checklist
3. A minimal secure MCP server config template

**When to use this:** When building or deploying any MCP server that exposes tools to LLM agents — especially servers with network-facing transports, tools that fetch external resources, or tools that touch databases and filesystems.
**Expected output:** A categorized vulnerability report across all four attack surfaces, step-by-step exploit scenarios, prioritized remediation checklist, and a hardened MCP server configuration template.

**Cross-link**: → [MCP Security Patterns](https://endofcoding.com/category/security). → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for MCP threat modeling. → [CyberOS](https://cyberos.dev) for MCP endpoint monitoring.

---

### 17.233 AI Agent Dependency Audit (Intermediate)
**Tool**: Claude Code, Cursor Composer | **Time**: 10-20 min | **Category**: Security

Scan all npm and pip dependencies used by an AI agent project for known CVEs, supply chain risks, low-adoption packages, and unsafe HTTP client versions.

You are a software supply chain security analyst. Audit every dependency in this AI agent project for security and supply chain risks. Perform ALL of the following checks:

1. Known Vulnerabilities (CVE Scan)

   • For every package in package.json, package-lock.json, requirements.txt, pyproject.toml, and poetry.lock: check for known CVEs
   • Flag any dependency with a CVSS score >= 7.0 as Critical
   • Flag any dependency with a CVSS score >= 4.0 as Warning
   • Include CVE ID, affected version range, fixed version, and one-line description

2. Supply Chain / Post-Install Script Risks

   • For npm: check every dependency for preinstall, install, postinstall, or prepare scripts
   • Flag any postinstall script that runs shell commands, downloads binaries, or uses eval
   • For pip: check setup.py for cmdclass overrides that execute code at install time
   • Flag any package published in the last 30 days with install hooks (typosquatting risk)

3. Low-Adoption / Abandoned Package Risk

   • Flag any npm package with fewer than 100 weekly downloads
   • Flag any PyPI package with fewer than 1,000 monthly downloads
   • Flag any package with no commits in the last 12 months
   • Flag any package where the maintainer account was created less than 90 days ago

4. HTTP Client Version Safety

   • axios: must be >= 1.7.4 — flag anything below (SSRF via header injection, CVE-2026-40175)
   • node-fetch: must be >= 2.6.7 or >= 3.3.2 — flag anything below
   • requests (Python): must be >= 2.32.0 — flag anything below
   • urllib3 (Python): must be >= 2.0.7 — flag anything below

Project path: [/path/to/agent/project] Package managers in use: [npm / pip / poetry / pnpm — auto-detect if unsure]

Output format:

After the table, provide:

1. Critical actions — must fix before deploying
2. Recommended upgrades — safe to batch into one PR
3. Packages to replace — actively maintained alternatives for risky packages
4. A single command to fix all safe-to-upgrade packages

**When to use this:** Before deploying any AI agent to production, after adding new dependencies, or as a weekly automated check in CI.
**Expected output:** A comprehensive dependency risk table covering CVEs, supply chain hooks, low-adoption flags, and unsafe HTTP client versions, followed by a prioritized action plan and one-command upgrade instructions.

**Cross-link**: → [npm Supply Chain Worm — What Vibe Coders Must Know](https://endofcoding.com/ebook/npm-supply-chain-worm-vibe-coding-2026). → [LLMHire — AI Security Engineer roles](https://llmhire.com). → [CyberOS](https://cyberos.dev) for automated dependency scanning on every commit.

---

---

### 17.237 Opus 4.7 Vision-Assisted Debugging (Intermediate)
**Tool**: Claude Opus 4.7 (claude.ai or API) | **Time**: 5-15 min | **Category**: Debugging · Vision AI
**Added**: May 2026 — Claude Opus 4.7's enhanced vision (3.75MP, 21% fewer errors on document reasoning) enables screenshot-to-fix debugging without manually transcribing error text

Paste a screenshot of an error dialog, browser console, crash log, or broken UI directly into Claude Opus 4.7 and get a structured diagnosis and fix — no copy-pasting required.

[Attach screenshot of: error dialog / browser console / broken UI / terminal crash output]

You are a senior debugging engineer. I've attached a screenshot showing a problem in my application. Please:

1. READ — Extract all visible error information from the screenshot (error type, message, stack trace, line numbers, file paths)
2. LOCATE — Based on the error details, identify the most likely source file and function causing this issue
3. DIAGNOSE — Explain in plain language what went wrong and why
4. FIX — Provide the exact code change needed to resolve it. If multiple files are involved, show each file separately with before/after snippets
5. VERIFY — Tell me how to confirm the fix worked (specific test, log line, or UI state to check)

My tech stack: [e.g., React 18 + Node.js 20 + PostgreSQL] Additional context: [optional — what action triggered the error, recent code changes, deployment environment]

**When to use this:** When an error is easier to screenshot than describe — modal dialogs, visual layout breaks, IDE error overlays, mobile crash screens. Opus 4.7's vision processes the full image at up to 3.75 megapixels, reading fine-print stack traces with high accuracy.
**Expected output:** A parsed error summary, root cause explanation, exact code fix with before/after snippets, and a verification checklist.

**Cross-link**: → [Chapter 13: Mastering the Craft](https://vibecodingebook.com/reader#ch13) for advanced debugging techniques. → [Claude Opus 4.7 release notes](https://www.anthropic.com/news/claude-opus-4-7) for vision capability details. → [Vibe Coding Academy — Debug Workflows](https://vibe-coding.academy).

---

### 17.238 Ollama Local Agent Quick-Start (Beginner-Intermediate)
**Tool**: Ollama + Claude Code / Cursor | **Time**: 15-30 min setup | **Category**: Local AI · Privacy · Cost Optimization
**Added**: May 2026 — Qwen 3.6 Plus and DeepSeek V4 have reached frontier-level parity on coding tasks; local deployment via Ollama costs ~$0 per token vs $5–$25/M for hosted APIs

Set up a fully local AI coding assistant using Ollama for privacy-sensitive or high-volume workloads — no data leaves your machine.

You are an expert in local LLM deployment and AI coding toolchain setup. Help me configure Ollama as a local coding assistant.

My setup:

• OS: [macOS / Linux / Windows]
• RAM: [e.g., 16 GB / 32 GB / 64 GB]
• GPU (if any): [e.g., NVIDIA RTX 4090 16 GB VRAM / Apple M3 Max / none]
• Primary coding language: [e.g., TypeScript, Python, Go]
• Primary AI tool: [Claude Code / Cursor / VS Code Copilot / other]
• Main use case: [e.g., autocomplete, code review, docstring generation, test writing]
• Privacy concern level: [high — no data can leave machine / medium — internal network OK / low — cloud is fine]

Please provide:

1. Model recommendation — best Ollama model for my hardware and use case (include ollama pull command)
2. Memory fit check — confirm my RAM can run the model comfortably at quantization level Q4_K_M or Q8_0
3. Ollama install and start — OS-specific commands to install, start, and verify Ollama is running
4. Tool integration — exact config steps to point my primary AI tool at the local Ollama endpoint (include any settings.json or config file changes)
5. Test prompt — a one-line test I can run to confirm the model is responding correctly
6. When to switch back to cloud — specific task types where local model quality drops below acceptable and I should route to Claude/GPT instead

Format each step as a numbered checklist with commands in code blocks.

**When to use this:** When setting up AI coding assistance for air-gapped environments, reducing API costs for high-volume repetitive tasks, or ensuring source code never leaves your network. Works best with Qwen 3.6 Plus (1M context, frontier parity) or DeepSeek-V4 on hardware with 16 GB+ RAM.
**Expected output:** A hardware-appropriate model recommendation, install/config checklist with copy-paste commands, tool integration steps, and a quality boundary map for when to use cloud vs. local.

**Cross-link**: → [Coding Agents on a Budget](https://endofcoding.com/ebook/coding-agents-budget-2026). → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) for full model comparison matrix. → [Chapter 14: Sustainable Workflows](https://vibecodingebook.com/reader#ch14).

---

### 17.239 AI-Accelerated Threat Response Drill (Advanced)
**Tool**: Claude Code, Cursor Composer | **Time**: 20-40 min | **Category**: Security · Incident Response · Team Process
**Added**: May 2026 — 28.3% of CVEs are now exploited within 24 hours of public disclosure (The Hacker News, May 2026); malicious packages on public repos increased 75% YoY

Run a structured team security drill using AI to simulate and respond to an AI-accelerated threat: a newly disclosed CVE landing in your tech stack during business hours.

You are a security incident commander running a 24-hour CVE response drill with a small engineering team. Our goal is to go from "CVE disclosed" to "patched and deployed" before the exploitation window closes.

Drill parameters:

• Team size: [e.g., 3 engineers + 1 DevOps]
• Tech stack: [e.g., Node.js 20 + Express + React + PostgreSQL on AWS ECS]
• Deploy pipeline: [e.g., GitHub Actions → ECR → ECS Fargate, ~15 min deploy cycle]
• On-call rotation: [yes / no / describe]
• Current monitoring: [e.g., Datadog alerts, Snyk weekly scan, no runtime WAF]

Simulate this scenario:

At 09:15 AM your Snyk alert fires: a new CVSS 8.8 CVE has been published for [package: e.g., express-validator 7.x]. PoC exploit code appeared on GitHub at 09:00 AM. NVD advisory says "unauthenticated RCE via crafted JSON body."

Run us through the full response:

Phase 1 — TRIAGE (0-15 min)

• Who gets paged? What communication channel? What's the first Slack message?
• How do we confirm we're actually using the vulnerable version?
• Are we exploitable given our specific configuration?

Phase 2 — CONTAIN (15-45 min)

• What's our interim mitigation while we prepare the patch? (WAF rule? Rate limit? Feature flag off?)
• Write the WAF/middleware rule that blocks the exploit pattern for this specific CVE type

Phase 3 — PATCH (45-90 min)

• Exact upgrade command and any required code changes
• Which tests must pass before we deploy?
• Write the git commit message and PR description

Phase 4 — DEPLOY & VERIFY (90-120 min)

• Deployment checklist (5 items max)
• How do we confirm we're no longer exploitable post-deploy? (specific curl/test command)
• What do we monitor for the next 24 hours?

Phase 5 — DEBRIEF

• What process gap let us be exposed to a CVSS 8.8 for 9+ hours?
• What one tool or process change would cut response time in half next time?

After the drill, output a one-page "24-Hour CVE Playbook" formatted as a Markdown table we can pin in Slack.

**When to use this:** Quarterly security drills, onboarding security-conscious new engineers, or immediately after a near-miss. The 28.3% within-24h exploitation statistic (2026 data) means this scenario is no longer theoretical — it's the new baseline threat.
**Expected output:** A phased incident response walkthrough with specific commands, a WAF/middleware mitigation snippet, a deploy checklist, and a pinnable one-page CVE playbook in Markdown.

**Cross-link**: → [2026: The Year of AI-Assisted Attacks](https://thehackernews.com/2026/05/2026-year-of-ai-assisted-attacks.html). → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19). → [CyberOS automated CVE alerting](https://cyberos.dev).

---

---

### 17.240 Agentic Output Verification Workflow (Advanced)
**Tool**: Claude Code, Cursor Agent, or any autonomous coding agent | **Time**: 10-20 min setup | **Category**: Agent Orchestration · Quality Gates · Agentic Safety
**Added**: May 2026 — As autonomous agents handle multi-file, multi-step changes, verification checkpoints prevent silent regressions and hallucinated "done" states; Karpathy's Software 3.0 framework highlights verification as the key differentiator between vibe coding and production-grade agentic engineering

Install a structured verification checkpoint into any agentic coding workflow so the agent confirms its own work before marking a task complete.

You are a senior software engineer acting as a verification layer for an autonomous coding agent. The agent has just completed a task. Before I mark this done, I need you to independently verify the work.

Task that was requested: [paste original task description]

Agent's claimed changes: [paste agent's summary or list the files it modified]

My codebase context:

• Language / framework: [e.g., TypeScript + Next.js 15 + Supabase]
• Test command: [e.g., npm test, pytest, go test ./...]
• Lint command: [e.g., npm run lint, ruff check .]
• Build command: [e.g., npm run build, cargo build]

Please run the following verification protocol:

Step 1 — COMPLETENESS CHECK Review the task description against the claimed changes. Is anything missing? List any requirements from the original task that do not appear to be addressed.

Step 2 — CODE CORRECTNESS REVIEW For each modified file, identify:

• Logic errors or off-by-one bugs
• Missing null checks or error handling
• Hardcoded values that should be config
• Any place the agent said "TODO" or left a stub

Step 3 — REGRESSION RISK Which existing features could this change break? Name the top 3 risk areas and the specific test I should run to verify each one is still working.

Step 4 — SECURITY SPOT CHECK Does any change introduce: SQL injection risk, unsafe user input handling, exposed secrets, or weakened auth checks? Flag YES/NO with file:line for any YES.

Step 5 — VERIFICATION VERDICT Output one of:

• ✅ VERIFIED — task complete, all checks pass
• ⚠️ PARTIAL — complete but [specific gap to address]
• ❌ FAILED — [specific thing is broken or missing]

If PARTIAL or FAILED, output the exact next prompt to give the agent to fix the issue.

**When to use this:** After any agent completes a non-trivial task — especially multi-file changes, database migrations, auth modifications, or anything touching payment flows. Treat it as your CI gate before committing. Takes 2-3 minutes to run and catches the "agent declared victory prematurely" failure mode.
**Expected output:** A structured 5-step verification report with a clear VERIFIED / PARTIAL / FAILED verdict and a ready-to-paste remediation prompt if needed.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for agentic workflow patterns. → [Chapter 13: Mastering the Craft](https://vibecodingebook.com/reader#ch13) for advanced quality control. → [Karpathy Software 3.0 framework — vibe-coding.academy](https://vibe-coding.academy).

---

### 17.241 Secure Repo Audit Before Agentic Cloning (Intermediate)
**Tool**: Claude Code, Cursor, GitHub CLI | **Time**: 5-10 min | **Category**: Security · Agentic Safety · Supply Chain
**Added**: May 2026 — CVE-2026-26268 (CVSS 8.1): Cursor RCE via malicious `.git/hooks/` in cloned repos — the first documented agentic-vector CVE where the attack surface is the agent's willingness to execute arbitrary scripts inside a cloned project

Before cloning an unfamiliar repository and opening it in an AI coding agent (Cursor, Claude Code, Copilot Workspace), run this audit to detect malicious Git hooks, hidden scripts, and supply chain traps.

You are a software supply chain security specialist. Before I clone and open the following repository in my AI coding agent, audit it for agentic-vector attack surfaces.

Repository: [paste GitHub/GitLab URL or local path] My AI coding tool: [Cursor / Claude Code / Copilot Workspace / other] My OS: [macOS / Linux / Windows]

Perform the following checks:

1. GIT HOOKS AUDIT (CVE-2026-26268 attack vector) List all files under .git/hooks/ in this repo. Flag any hook that:

• Contains a network call (curl, wget, fetch)
• Executes a binary or shell script not in the repo root
• Sets environment variables
• Has been modified after the repo's last commit If no .git/hooks/ is visible from the public URL, provide the CLI commands I should run locally after cloning to audit these files BEFORE opening in my agent.

2. HIDDEN SCRIPT DETECTION Scan for executable scripts outside the standard project structure:

• .vscode/, .cursor/, .claude/ directories with executable content
• postinstall, prepare, preinstall scripts in package.json / setup.py / Makefile
• Any script that runs on npm install, pip install, cargo build, or IDE open

3. DEPENDENCY LEGITIMACY CHECK Review the top-level dependency manifest (package.json / requirements.txt / go.mod / Cargo.toml). Flag any:

• Package names that are one character off from a well-known package (typosquatting)
• Dependencies pinned to unusual versions with no changelog explanation
• Packages with fewer than 100 weekly downloads that are given broad permissions

4. PERMISSION SCOPE REVIEW Does any CI config file (.github/workflows/*.yml, .gitlab-ci.yml) request:

• write-all or packages: write permissions?
• Secrets passed to third-party actions with * version pinning?

5. SAFE OPEN CHECKLIST Based on the above, output a 5-item checklist I must verify before opening this repo in my agent: [ ] Item 1 [ ] Item 2 ...

Rate overall risk: LOW / MEDIUM / HIGH — with one-sentence justification.

**When to use this:** Any time you clone an unfamiliar repo and plan to open it in Cursor, Claude Code, or any AI agent that auto-reads project files. Especially important for: interview take-home projects, open-source contributions from unknown maintainers, repos shared in Discord/Slack, and contractor-submitted codebases.
**Expected output:** A git hooks audit with specific file listings, a hidden script map, a dependency red-flag list, and a rated safe-open checklist.

**Cross-link**: → [CVE-2026-26268 analysis — endofcoding.com](https://endofcoding.com). → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for AI-accelerated attack data. → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19). → [vibe-coding.academy — Agentic Security module](https://vibe-coding.academy).

---

### 17.242 Software 3.0 Architecture Audit (Expert)
**Tool**: Claude Opus 4.6/4.7, Claude Code | **Time**: 30-60 min | **Category**: Architecture · AI-Native Design · Strategic Planning
**Added**: May 2026 — Andrej Karpathy's 'Software 3.0' framework (May 2026) distinguishes three eras: Software 1.0 (explicit code), Software 2.0 (neural weights), Software 3.0 (natural language programs); this audit maps your codebase against the 3.0 architecture and identifies components ready for LLM-native refactoring

Audit your codebase through the Software 3.0 lens to find components that are over-engineered in Software 1.0 style but could be dramatically simplified by treating the LLM as the computation substrate.

You are a principal software architect specializing in Software 3.0 system design, per Andrej Karpathy's May 2026 framework. I want to audit my codebase to identify where I am building in Software 1.0 style (explicit procedural logic) for problems that a well-prompted LLM could solve directly.

My system:

• Project type: [e.g., SaaS web app / data pipeline / CLI tool / API service]
• Primary language: [TypeScript / Python / Go / other]
• Key business logic areas: [e.g., document parsing, user intent classification, content moderation, data normalization, form validation, report generation]
• Current AI usage: [none / some (specific features) / heavy (most features)]
• Team size and AI comfort level: [e.g., 4 engineers, 2 are comfortable with LLM APIs]

For each major component in [paste list of modules or describe system areas], perform this classification:

LAYER 1 — Software 1.0 Candidates (keep as-is) Components where the logic is deterministic, latency-critical (<100ms), privacy-sensitive, or mathematically precise. These should stay as traditional code. Explain why for each.

LAYER 2 — Software 2.0 Candidates (ML/fine-tuned models) Components where behavior is learned from examples but a frozen model (not a general LLM) is more appropriate — e.g., spam classifiers, image recognition, embedding similarity. Flag these as candidates for specialized model fine-tuning.

LAYER 3 — Software 3.0 Candidates (LLM-native) Components where the logic is:

• Parsing or understanding ambiguous natural language input
• Making judgment calls with subjective criteria
• Generating structured output from unstructured input
• Classifying intent across a long-tail of cases
• Producing human-readable explanations or summaries

For each Layer 3 candidate, provide: a) The current implementation pattern (e.g., "500-line switch statement for intent routing") b) The Software 3.0 replacement approach (e.g., "structured prompt with JSON schema output") c) Estimated code reduction (e.g., "500 lines → 30-line prompt template") d) Reliability tradeoff: what determinism you lose and how to add guardrails

MIGRATION PRIORITY MATRIX Rank the Layer 3 candidates by: (impact × feasibility) / risk Output as a table: | Component | Impact (1-5) | Feasibility (1-5) | Risk (1-5) | Priority Score | First Step |

SOFTWARE 3.0 READINESS SCORE Score my system 1-10 on Software 3.0 readiness:

• 1-3: Mostly 1.0, heavy refactor needed to leverage LLMs
• 4-6: Hybrid, some LLM integration but structural barriers remain
• 7-9: LLM-native patterns dominant, incremental improvements needed
• 10: Full Software 3.0 — LLMs handle all appropriate cognition layers

Explain the score and the single highest-leverage change I could make this sprint.

**When to use this:** Quarterly architecture reviews, planning a major refactor, evaluating whether to introduce an AI coding agent into a legacy codebase, or when Karpathy's Software 3.0 framing makes you question how much of your business logic belongs in code vs. in a well-structured prompt.
**Expected output:** A layer-classified component map, a prioritized migration matrix, and a 1-10 Software 3.0 readiness score with a recommended first sprint action.

**Cross-link**: → [Karpathy 'Software 3.0' framework — endofcoding.com](https://endofcoding.com). → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for the agentic engineering foundation. → [Chapter 16: What Comes Next](https://vibecodingebook.com/reader#ch16) for long-horizon AI architecture trends. → [vibe-coding.academy — Software 3.0 module](https://vibe-coding.academy).

---

*Chapter 17 additions — May 6, 2026 | Prompts 17.240–17.242 (Agentic Output Verification, Secure Repo Audit Before Agentic Cloning, Software 3.0 Architecture Audit) | 256+ prompts across 47 categories | Previous: May 5 (prompts 17.237–17.239 — Opus 4.7 Vision Debugging, Ollama Local Quick-Start, AI-Accelerated Threat Drill). Prompted by: CVE-2026-26268 Cursor RCE via Git hooks (first agentic-vector CVE), Karpathy Software 3.0 framework (May 2026), rising demand for agentic verification patterns in production deployments.*

---

### 17.243 — AI-Accelerated Security Patch Pipeline (Advanced)
**Tool**: Claude Code (Opus 4.7) | **Time**: 15–30 min full scan | **Category**: Security / DevSecOps

Inspired by Mozilla's deployment of Anthropic's Mythos model to jump from 31 Firefox security patches/year to 423 in a single month, this prompt sets up an automated security review pipeline for your codebase.

You are a senior security engineer performing a comprehensive vulnerability audit.

CODEBASE CONTEXT Repository: [repo name] Tech stack: [Node.js/Python/Go/etc.] Entry points: [list main entry files, API routes, auth handlers] External integrations: [list third-party APIs, databases, file systems]

PHASE 1: DEPENDENCY AUDIT Scan package.json / requirements.txt / go.mod for:

• Any dependency with a known CVE (CVSS >= 7.0)
• Dependencies with versions > 2 major releases behind latest stable
• Packages with < 10k weekly downloads (supply chain risk)
• Direct dependencies that haven't been updated in > 12 months

For each finding, output: | Package | Current | Latest | CVE | CVSS | Fix Command |

PHASE 2: STATIC CODE ANALYSIS Scan all source files for OWASP Top 10 patterns:

1. Injection (SQL, NoSQL, command injection, LDAP)
2. Broken authentication (weak session tokens, missing rate limiting)
3. Sensitive data exposure (hardcoded secrets, unencrypted PII)
4. XXE (if XML parsing present)
5. Broken access control (missing authorization checks on routes)
6. Security misconfiguration (default credentials, verbose errors in prod)
7. XSS (unsanitized user input in rendering)
8. Insecure deserialization (JSON.parse on untrusted input, eval usage)
9. Vulnerable components (already covered in Phase 1)
10. Insufficient logging (missing audit trails for sensitive operations)

For each finding:

• File path and line number
• Vulnerability class (CWE ID)
• Severity: Critical / High / Medium / Low
• Proof-of-concept: "An attacker could..."
• Fixed version of the vulnerable code block

PHASE 3: PROTOTYPE POLLUTION SWEEP This is the #1 class of vulnerability in AI-generated Node.js code. Scan for:

• Object.assign({}, userInput)
• _.merge(target, userInput)
• {...req.body} spread on untrusted data
• JSON.parse(untrustedString) assigned to objects without schema validation

For each: show the vulnerable line + a fixed version using structuredClone() or a validated schema (Zod/Joi).

PHASE 4: PATCH PLAN Generate a prioritized patch list:

1. Critical (fix today): [list]
2. High (fix this week): [list]
3. Medium (fix this sprint): [list]
4. Low (schedule for backlog): [list]

Include: estimated fix time, whether a breaking change is likely, and whether a test exists that would catch regressions.

PHASE 5: SECURITY POSTURE SCORE Score the codebase 0–100 across 5 dimensions:

• Dependency hygiene (0–20)
• Input validation coverage (0–20)
• Authentication robustness (0–20)
• Secret management (0–20)
• Logging and monitoring (0–20)

Total score interpretation:

• 80–100: Production-secure, minor hardening only
• 60–79: Deployable with known risks, patch within 30 days
• 40–59: Risky for production — fix Criticals and Highs first
• 0–39: Not production-ready — security overhaul required

**When to use this:** Before every major deployment, after adding new dependencies, or as a weekly scheduled Routine in Claude Code. Run Phase 1 alone for a 5-minute pre-deploy dependency check. Run the full 5-phase audit quarterly.
**Expected output:** Dependency CVE table, annotated code findings with fixes, prioritized patch plan, and a 0–100 security posture score.

**Cross-link**: → [CyberOS](https://cyberos.dev) for automated pattern-based scanning (614+ patterns). → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for the security risks specific to AI-generated code. → [endofcoding.com — AI security patching article](https://endofcoding.com/blog/ai-security-patching-firefox-mozilla).

---

### 17.244 — Claude Routines Setup: Automated Background Worker (Intermediate)
**Tool**: Claude Code (Anthropic cloud Routines) | **Time**: 5 min setup, runs autonomously | **Category**: Automation / DevOps

Claude Routines (launched April 14, 2026) let you save a prompt + repository + connectors as a named configuration that runs on a schedule or GitHub event — without requiring your machine to be on. This prompt configures a complete automated PR review and overnight health-check system.

Set up a Claude Code Routine for this repository with the following configuration:

ROUTINE NAME: "[your-project]-nightly-health-check"

TRIGGER: Schedule — runs every night at 2:00 AM UTC

REPOSITORIES: [list your repos]

TASK DESCRIPTION: You are an automated DevOps assistant. Each night, perform the following checks and write a brief report to .claude/nightly-report-{date}.md:

1. Dependency Health

   • Run npm audit (or equivalent)
   • Flag any new HIGH or CRITICAL vulnerabilities since last report
   • Check if any dependencies are > 2 major versions behind

2. Dead Code Detection

   • Identify files not imported anywhere in the codebase
   • Flag functions/exports that are defined but never called

3. TODO/FIXME Audit

   • Count all TODO, FIXME, HACK comments
   • Flag any that have been present for > 30 days (check git blame)

4. Test Coverage Delta

   • Run the test suite
   • Compare pass rate to last night's report
   • Flag any newly failing tests

5. Bundle Size Watch (if Next.js / webpack project)

   • Build with --analyze flag
   • Compare total bundle size to last report
   • Flag if increased by > 5%

6. Summary Report Format:

Nightly Health Report — {date}
Repo: {repo-name}

🔴 Action Required (fix today): [list]
🟡 Attention Needed (fix this week): [list]
🟢 All Clear: [list]

Delta from yesterday:
- New CVEs: [count]
- Test pass rate: [X%] (was [Y%])
- Bundle size: [Xkb] (was [Ykb])
- New TODOs: [count]

7. GitHub Issue Creation For any 🔴 items not already tracked: create a GitHub issue with label automated-health-check

CONNECTORS: GitHub (read/write for issue creation)

PLAN LIMITS NOTE: This Routine uses ~1 tool call per check. Estimated: 8–12 tool calls per run. Well within Pro (5/day) and Teams (15/day) limits.

**When to use this:** Any production repository you want to maintain without manual oversight. Especially powerful for solo founders running multiple products — a single Routine per repo replaces daily manual checks. Combine with the Security Patch Pipeline prompt (17.243) for a comprehensive automated DevSecOps workflow.
**Expected output:** A running Claude Routine that files GitHub issues, writes nightly reports, and surfaces regressions before your morning stand-up.

**Cross-link**: → [endofcoding.com — Claude Routines launch coverage](https://endofcoding.com). → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for the automation-first mindset. → [vibe-coding.academy — Automation module](https://vibe-coding.academy).

---

### 17.245 — AI Financial Workflow Agent (Advanced)
**Tool**: Claude API (claude-opus-4-7) | **Time**: 2–4 hours implementation | **Category**: AI Agents / FinTech

Based on the Anthropic + Goldman Sachs / Blackstone $1.5B joint venture (May 2026), which deployed ~10 pre-built Claude agents for financial workflows. This prompt helps you build your own AI financial workflow agent for underwriting, data extraction, or document summarization.

You are building a production AI agent for financial document processing. The agent reads financial documents, extracts structured data, and produces analyst-grade summaries.

AGENT ARCHITECTURE SPEC

Build a financial document analysis agent with these capabilities:

TOOL 1: document_reader

• Input: File path or URL (PDF, Excel, Word, plain text)
• Output: Extracted text with section headers preserved
• Handles: Balance sheets, P&L statements, loan applications, KYC forms, credit memos
• Error handling: Return structured error if document is encrypted, password-protected, or corrupt

TOOL 2: data_extractor

• Input: Extracted text + document_type ("balance_sheet" | "income_statement" | "loan_application" | "kyc" | "credit_memo")
• Output: JSON with extracted fields per document type
• Balance sheet fields: total_assets, total_liabilities, equity, current_ratio, debt_to_equity
• Income statement fields: revenue, gross_profit, operating_income, net_income, ebitda, margins
• Loan application fields: borrower_name, requested_amount, collateral, stated_income, employment_status
• KYC fields: entity_name, jurisdiction, beneficial_owners (list), risk_flags (list)

TOOL 3: risk_scorer

• Input: Extracted financial data
• Output: Risk score 1–10 + breakdown
• Factors: Liquidity ratio, leverage, revenue trend (3Y), industry risk, concentration risk
• Score interpretation: 1–3 (high risk), 4–6 (moderate), 7–9 (low risk), 10 (exceptional)

TOOL 4: memo_writer

• Input: Extracted data + risk score
• Output: 500-word analyst memo in standard format:
  • Executive Summary (3 sentences)
  • Financial Highlights (key metrics table)
  • Risk Assessment (score + top 3 risk factors)
  • Recommendation: Approve / Approve with conditions / Decline
  • Conditions (if applicable): [list specific covenants or requirements]

SYSTEM PROMPT FOR THE AGENT:

You are a senior financial analyst with 15 years of experience in credit underwriting and KYC compliance.

Your role is to:
1. Receive financial documents from users
2. Extract key data using your tools
3. Score the financial risk
4. Produce a clear, professional analyst memo

Standards to apply:
- GAAP interpretation for all accounting figures
- Basel III for credit risk classification
- FATF guidelines for KYC risk flags
- Be conservative: if data is ambiguous, note it and apply the more conservative interpretation

Output format: Always produce a structured memo, never free-form text alone.
Flag immediately: Any document showing signs of alteration, inconsistency between stated and calculated figures, or missing required fields.

IMPLEMENTATION NOTES:

• Use claude-opus-4-7 for complex document reasoning
• Enable extended thinking for risk scoring decisions
• Cache document context (Anthropic prompt caching) — reduces costs 60-90% for batch processing
• Implement retry logic for large documents that exceed single-turn context
• Log all decisions with source document references for audit trail

TEST CASE: Run against a sample 10-K filing from SEC EDGAR to validate extraction accuracy before production deployment.

**When to use this:** Building any FinTech product that processes financial documents — lending, KYC/AML compliance, investment research, insurance underwriting. The Goldman Sachs/Anthropic pattern is now validated at institutional scale. Smaller implementations can go live on the same Claude API.
**Expected output:** A working financial document agent with 4 tools, structured JSON extraction, risk scoring, and professional memo generation.

**Cross-link**: → [LLMHire](https://llmhire.com) for "AI Financial Engineer" and "AI Compliance Analyst" roles paying $200K–$350K. → [Chapter 8: Monetization Patterns](https://vibecodingebook.com/reader#ch08) for productizing an AI agent. → [endofcoding.com — Anthropic Goldman Sachs story](https://endofcoding.com).

---

---

### 17.246 Dependency Confusion Attack Surface Audit (Advanced)
**Tool**: Claude Sonnet 4.6, Cursor | **Time**: 30-60 min | **Category**: Security

I'm auditing my vibe-coded project for dependency confusion vulnerabilities before deploying to production. Dependency confusion attacks occur when an attacker publishes a malicious public package that shadows an internal/private package name — npm, pip, and other package managers may silently resolve to the attacker's public version instead of the intended private one.

My project details:

• Package manager: [npm / pip / cargo / go modules]
• Private registry: [Artifactory / GitHub Packages / AWS CodeArtifact / none]
• Internal package names: [list any internal packages you use]
• Public registry fallback: [yes/no — does your config fall back to npmjs.com/PyPI?]
• CI/CD environment: [GitHub Actions / GitLab / Jenkins / Vercel]

Audit my configuration for dependency confusion risk:

1. Registry Configuration Review Analyze my package.json, .npmrc, pip.conf, or equivalent config:

• Is my registry resolution order safe (private-first with no public fallback for internal names)?
• Do any internal package names also exist as public packages (check npmjs.com/PyPI)?
• Are scoped packages properly scoped to my private registry?
• Does my lockfile pin exact versions that prevent resolution hijacking?

2. CI/CD Pipeline Audit

• Is npm install or pip install run with --registry flags pointing to private registry?
• Are install commands using --prefer-offline or --frozen-lockfile?
• Does the pipeline authenticate to private registry before installing dependencies?

3. Vulnerable Name Patterns Identify internal package names that are short, generic, not yet published publicly, or scoped but not protected.

4. Remediation Checklist For each risk: specific config change (before/after), lock file regeneration steps, verification command.

5. Ongoing Prevention

• GitHub Actions check that validates registry resolution order on each PR
• Automated alerting if any internal package name appears on the public registry

Output: Audit report with risk level for each finding, config diffs to fix each issue, and a CI/CD check.

**When to use this:** Before production deployment of any vibe-coded project using private packages, when onboarding a new package manager, or after reading about dependency confusion incidents.
**Expected output:** Registry configuration audit, vulnerable name analysis, specific config fixes with before/after diffs, and a CI pipeline check for ongoing protection.

**Cross-link**: → [Chapter 19: Security Playbook](https://vibecodingebook.com/reader#ch19) for the full supply chain security checklist. → [CyberOS](https://cyberos.dev) for automated dependency vulnerability monitoring. → [endofcoding.com — Supply Chain Security for Vibe Coders](https://endofcoding.com).

---

### 17.247 AI Model Cost Optimization Audit (Intermediate)
**Tool**: Claude Sonnet 4.6, ChatGPT | **Time**: 20-40 min | **Category**: Cost & Performance

My AI-assisted project is growing and my LLM API costs are higher than expected. Help me audit my usage and identify where I can cut costs without compromising output quality.

My current setup:

• Primary LLM: [Claude Sonnet 4.6 / GPT-4o / Gemini 2.5 Pro / other]
• Monthly API spend: [$X/month]
• Primary use cases: [list: chat, RAG, code review, summarization, agents, etc.]
• Average context window per call: [estimate tokens in + tokens out]
• Caching: [yes/no — are you using prompt caching?]
• Model routing: [do you use different models for different tasks?]

Audit my LLM usage for cost optimization:

1. Call Pattern Analysis

• Are you using the right model tier? (Haiku/Flash for simple tasks, Sonnet for medium, Opus/Pro for complex)
• Is context window bloat happening?
• Are duplicate or near-duplicate requests being made without semantic caching?

2. Prompt Caching Opportunities Which system prompts (>1024 tokens) are reused across calls? Show exact API parameters to enable caching for each.

3. Model Routing Strategy

Include a routing function in Python or TypeScript.

4. Context Window Optimization

• Can conversation history be summarized after N turns?
• Can RAG chunks be compressed or de-duplicated? Show code changes for each optimization.

5. Cost vs. Quality Trade-off For top 3 use cases: current monthly cost, projected cost after optimization, quality delta risk rating.

Output: Cost optimization plan with specific code changes, estimated monthly savings, and quality-risk rating per change.

**When to use this:** When LLM API bills are growing faster than revenue, before scaling to more users, or when budgeting AI features.
**Expected output:** Call pattern audit, prompt caching implementation guide, model routing function, context optimization code changes, and cost savings estimate.

**Cross-link**: → [Chapter 13: Advanced Techniques](https://vibecodingebook.com/reader#ch13) for advanced LLM integration patterns. → [vibe-coding.academy — AI cost optimization module](https://vibe-coding.academy). → [endofcoding.com — LLM cost benchmarks 2026](https://endofcoding.com).

---

### 17.248 Vibe Coding Project Handoff Document Generator (Intermediate)
**Tool**: Claude Sonnet 4.6, Cursor | **Time**: 15-30 min | **Category**: Documentation & Collaboration

I've built a project using AI-assisted vibe coding and now need to hand it off — to a new developer, a contractor, my future self, or a client. Generate a comprehensive handoff document.

Project context:

• Project name: [name]
• Tech stack: [e.g., Next.js 15, Supabase, Vercel, Tailwind]
• Current state: [e.g., MVP, alpha, production]
• Handoff recipient: [new hire / contractor / client / team]
• Recipient's technical level: [junior / mid / senior / non-technical]
• Known AI debt: [areas where AI-generated code hasn't been fully reviewed]

Generate a HANDOFF.md covering:

1. Project Overview — what it does, who uses it, deployment URLs
2. Architecture Overview — system diagram, tech choices, data flow, external services
3. Local Development Setup — prerequisites, install, env vars (no real values), run steps, common issues
4. Codebase Map — for each major directory: what it does, when to modify, what not to touch
5. AI-Generated Code Debt Log — file/function, what AI generated, risk (security/perf/edge cases), review priority
6. Deployment Runbook — deploy steps, env differences, rollback procedure, monitoring
7. Open Questions — unresolved architectural or business decisions

Output: Complete markdown HANDOFF.md ready to drop into the repo.

**When to use this:** When transitioning a vibe-coded project to a new developer, when documenting a project built quickly with AI, or before taking a break from a project.
**Expected output:** Complete HANDOFF.md with architecture, setup, codebase map, AI debt log, deployment runbook, and open questions.

**Cross-link**: → [Chapter 14: Sustainable Workflows](https://vibecodingebook.com/reader#ch14) for long-term project health. → [Chapter 7: Real Workflows](https://vibecodingebook.com/reader#ch07) for team workflow setup. → [vibe-coding.academy — Team collaboration module](https://vibe-coding.academy).

---

*Chapter 17 additions — May 8, 2026 | Prompts 17.246–17.248 (Dependency Confusion Attack Surface Audit, AI Model Cost Optimization Audit, Vibe Coding Project Handoff Document Generator) | 262+ prompts across 47 categories | Previous: May 8 earlier (prompts 17.243–17.245 — AI-Accelerated Security Patch Pipeline, Claude Routines Setup, AI Financial Workflow Agent). Prompted by: supply chain security incidents, rising LLM API cost concerns, and team handoff pain points for rapidly-built AI projects.*

---

### 17.249 OIDC Token Scope Hardener (Advanced)
**Tool**: Claude Code, GitHub Copilot | **Time**: 15-30 min
**Difficulty**: Advanced | **Category**: Supply Chain Security

Audit and harden the GitHub Actions OIDC token permissions in this repository. The recent Shai-Hulud attack compromised 42 @tanstack/* packages by stealing OIDC tokens from misconfigured CI workflows.

Review all .github/workflows/*.yml files and:

1. IDENTIFY RISK: Flag any job that has both:

   • id-token: write permissions (can publish to npm/PyPI/cloud)
   • Triggers on pull_request or push from non-protected branches

2. SCOPE REDUCTION: For each publish step, restructure so id-token: write is scoped to only that step — not the entire job or workflow.

3. SEPARATION OF CONCERNS: Split workflows that both build (needs PR access) and publish (needs OIDC) into separate files:

   • ci.yml: build, test, lint — triggers on PR and push
   • publish.yml: npm/PyPI publish — triggers on release tag only, id-token: write scoped to publish step only

4. BLOCK PUBLISH ON PRs: Add an explicit check that prevents publish workflows from running on pull_request events.

5. AUDIT OUTPUT: For each workflow file, show:

   • Current permission scope (job-level vs step-level)
   • Trigger conditions
   • Whether publish can be triggered by an external contributor
   • Recommended change

Output the hardened workflow YAML files with inline comments explaining each security decision.

**When to use this:** After any new npm/PyPI package setup, after adding a new GitHub Actions workflow with publish capabilities, or as a quarterly security audit of your CI/CD pipelines.
**Expected output:** Hardened workflow YAML files with OIDC tokens scoped to publish steps only, publish blocked on PRs, and clear separation between CI (test/build) and CD (publish) workflows.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for supply chain security context. → [endofcoding.com — TanStack Shai-Hulud attack breakdown](https://endofcoding.com/ebook/tanstack-mistral-supply-chain-shai-hulud-2026) for full attack details. → [cyberos.dev](https://cyberos.dev) for automated supply chain scanning.

---

### 17.250 Claude Agent SDK Integration Bootstrap (Expert)
**Tool**: Claude Code | **Time**: 45-90 min
**Difficulty**: Expert | **Category**: Agent Architecture

Bootstrap a production-ready Claude Agent SDK integration for [use case: e.g., "a code review agent that runs on every PR" / "an async research agent with multi-session memory" / "a customer support agent with tool calling"].

Using Anthropic's Managed Agents API (/v1/agents and /v1/sessions), implement:

Agent Configuration

• Agent name: [agent_name]
• System prompt: Design a system prompt that clearly defines the agent's role, boundaries, and tool-calling behavior
• Available tools: [list tools the agent needs — web search, code execution, file access, API calls, etc.]
• Model: claude-opus-4-6 for complex reasoning, claude-sonnet-4-6 for speed-sensitive paths

Session Management

• Create a new session per [conversation / PR / user / daily run]
• Session persistence: [ephemeral vs persistent — state that should survive context window]
• Session metadata: Tag sessions with [project ID / user ID / PR number] for retrieval

Async Execution Pattern

If this agent runs async (e.g., triggered by CI, scheduled, or webhook):

1. Use Routines API to queue the task with webhook callback
2. Store session ID and job ID in [database/file/queue]
3. Poll or receive callback when complete
4. Process output and [notify user / post PR comment / update database]

Error Handling

• Rate limit retry with exponential backoff
• Session recovery if context window exceeded (summarize + continue)
• Tool call failure handling (retry vs fallback vs notify)
• Timeout handling for long-running tasks (> 10 min)

Dreaming Integration (Optional)

If the agent should improve itself over time:

• After each session, save key observations to agent memory
• Use the Dreaming feature to let the agent review past sessions weekly
• Define what the agent should learn: [patterns in requests / common errors / successful strategies]

Output: Complete working implementation with TypeScript types, error handling, and a test harness that validates the agent behavior before deployment.

**When to use this:** When building any long-running or async AI agent using the Anthropic Claude Agent SDK. Especially useful for agents that need to survive context window limits, run on CI triggers, or improve over time using Dreaming.
**Expected output:** A complete, typed TypeScript implementation with session management, async execution, error recovery, and optional Dreaming integration — deployable as a standalone service or embedded in an existing application.

**Cross-link**: → [Chapter 8: AI-Native Architecture](https://vibecodingebook.com/reader#ch08) for agent system design patterns. → [vibe-coding.academy — Agent SDK deep dive](https://vibe-coding.academy) for hands-on tutorials. → [endofcoding.com](https://endofcoding.com) for the latest Claude Agent SDK coverage.

---

### 17.251 AI Security Review Gate (Intermediate)
**Tool**: Claude Code, Claude Opus 4.6 | **Time**: 10-20 min per PR
**Difficulty**: Intermediate | **Category**: Security

You are a security-focused code reviewer with expertise in AI-generated code vulnerabilities. Review the following code diff for security issues, with special attention to patterns common in AI-generated code.

Diff to Review

[PASTE DIFF HERE or reference file paths]

Security Checks (in priority order)

Critical — Block merge if found:

1. Prompt injection vectors: User input passed directly into LLM prompts without sanitization
2. Hardcoded secrets: API keys, tokens, passwords anywhere in diff (check comments and test files too)
3. OIDC/token exposure: GitHub Actions workflow changes that broaden id-token: write scope
4. SQL injection: String interpolation in database queries without parameterization
5. Insecure deserialization: eval(), pickle.loads(), JSON.parse() on untrusted input
6. RCE patterns: exec(), subprocess with user-controlled input, template injection

High — Flag for immediate review:

7. Dependency additions: New packages added without pinned versions or provenance check
8. Auth bypass potential: Middleware-only auth (Next.js 15-16 pattern — CVE-2025-29927)
9. CORS misconfiguration: Wildcard origins on authenticated routes
10. Exposed internal APIs: New routes without authentication checks

Medium — Note in review:

11. Overprivileged IAM: New cloud permissions broader than minimum required
12. Missing input validation: No validation on user-controlled request fields
13. Logging sensitive data: PII or secrets in log statements

Output Format

For each finding:

• Severity: CRITICAL / HIGH / MEDIUM
• Location: file:line
• Pattern: Which check above triggered
• Explanation: Why this is a risk
• Fix: Specific code change required

End with: APPROVE / REQUEST_CHANGES / BLOCK — with one-line justification.

**When to use this:** As a pre-merge security gate on any PR that touches authentication, API routes, dependencies, or GitHub Actions workflows. Especially valuable for vibe-coded projects where AI generated large portions of the diff.
**Expected output:** Structured security review with severity-ranked findings, specific fix instructions, and a clear merge recommendation — ready to post as a PR comment.

**Cross-link**: → [cyberos.dev](https://cyberos.dev) for automated pattern-matched scanning at scale. → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for why AI-generated code needs extra security review. → [endofcoding.com/ebook/pre-deploy-security-checklist](https://endofcoding.com/ebook/pre-deploy-security-checklist-vibe-coding-2026) for the full pre-deploy checklist.

---

### 17.252 SLSA Attestation Integrity Verifier (Advanced)
**Tool**: Claude Code, GitHub CLI | **Time**: 20-40 min
**Difficulty**: Advanced | **Category**: Supply Chain Security

The Mini Shai-Hulud attack (May 2026) proved that SLSA Build Level 3 attestations can be forged when OIDC tokens are stolen. This prompt generates a verification layer that goes beyond attestation presence to verify attestation integrity.

Context

Repository: [your repo path or package name] Package registry: [npm / PyPI / Maven / crates.io] Critical dependencies to audit: [list your highest-risk packages — build tools, auth libraries, HTTP clients]

Verification Tasks

1. Attestation Presence Check

For each critical dependency, verify a signed SLSA provenance attestation exists:

# npm packages
gh attestation verify --owner [org] --repo [repo] node_modules/[package]

# PyPI
python -m pip download [package] && cosign verify-attestation [artifact] --certificate-identity-regexp='github.com/[owner]/[repo]'

2. Signer Identity Validation

Flag any package where the attestation signer identity does NOT match the expected GitHub org/repo:

• Expected signer: https://github.com/[official-owner]/[official-repo]/.github/workflows/publish.yml
• Red flag: Signer from a fork, personal repo, or third-party org

3. Build Trigger Verification

For each attestation, extract and verify:

• Was it triggered by a release tag (not a PR or branch push)?
• Is the trigger ref a protected branch/tag?
• Did the build run on ubuntu-latest or a known runner?

4. Publish Time Analysis

Compare attestation timestamp vs npm publish timestamp:

• Gap > 10 minutes between build and publish = flag for review
• Multiple attestations for same version = critical flag (re-publish after compromise)

5. Dependency Diff Report

Compare current lock file vs last verified lock file:

• New packages with no attestation
• Version bumps without corresponding attestation update
• Packages removed from attestation scope

Output Format

For each package: VERIFIED / FLAGGED / MISSING — with the specific check that failed and recommended action (pin to verified version / open issue with maintainer / replace package).

**When to use this:** After any supply chain security incident in your ecosystem, before major deployments, or as a monthly attestation audit. Essential for teams using npm or PyPI packages in production.
**Expected output:** Per-package attestation health report with VERIFIED/FLAGGED/MISSING status, signer identity confirmation, build trigger analysis, and specific remediation actions for flagged packages.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for the Mini Shai-Hulud attack analysis. → [cyberos.dev](https://cyberos.dev) for continuous supply chain monitoring. → [endofcoding.com — SLSA verification guide](https://endofcoding.com) for step-by-step setup.

---

### 17.253 Vibe-Coded App Public Exposure Audit (Intermediate)
**Tool**: Claude Code | **Time**: 30-60 min
**Difficulty**: Intermediate | **Category**: Security

Security researchers found ~380,000 publicly accessible corporate assets — healthcare records, financial data, API keys — from AI coding platforms using insecure default configurations. Audit this vibe-coded application for the same exposure patterns.

Application Context

• Project type: [web app / API / data dashboard / internal tool]
• Hosting: [Vercel / Netlify / AWS / GCP / Railway / Render / self-hosted]
• Auth provider: [none / Supabase / Clerk / NextAuth / Auth0 / custom]
• Data sensitivity: [public / internal / confidential / regulated (HIPAA/GDPR)]
• AI tool that built it: [Claude Code / Cursor / Lovable / Bolt / Replit / v0]

Audit Checklist

1. Authentication Defaults

• Is any route or page publicly accessible that should require login?
• Did the AI tool set auth: false or no-auth as a default on any endpoint?
• Check for Next.js middleware gaps (routes not covered by middleware matcher)
• Check for Supabase RLS disabled on any table: SELECT * FROM pg_policies WHERE tablename = '[table]'

2. Environment Variable Exposure

• Are any env vars prefixed with NEXT_PUBLIC_ that contain secrets?
• Scan for patterns: NEXT_PUBLIC_.*KEY, NEXT_PUBLIC_.*SECRET, NEXT_PUBLIC_.*TOKEN
• Check if .env.local or .env is in .gitignore
• Verify Vercel/Netlify env vars are not set as "Plain text" for secret values

3. Storage Bucket Permissions

• Are any S3/GCS/R2/Supabase Storage buckets set to public read?
• Does the AI-generated bucket policy use * as the principal?
• Check for uploaded files containing PII at public URLs (AI tools often demo with real data)

4. API Route Authorization

• Enumerate all API routes: find . -path "*/api/*" -name "*.ts" -o -name "*.js"
• For each route, verify: Does it check authentication before processing the request?
• Flag any route that returns data without a session/token check at the top

5. Database Connection Exposure

• Is the database connection string in a public-facing env var?
• Is Supabase anon key used for admin operations (should use service role key server-side only)?
• Check for direct database URLs in client-side code

6. AI-Generated Demo Data

• Search for: demo, sample, test@, example@, placeholder, lorem
• Any seeded demo data using real-looking personal information?
• User-uploaded files from the build/demo phase left in production storage?

Output

For each finding: location (file:line or URL), exposure type, severity (CRITICAL/HIGH/MEDIUM), and specific fix. Generate a remediation priority list ordered by data sensitivity risk.

**When to use this:** Before going live with any vibe-coded application, after adding new features with AI assistance, or as a quarterly security posture review. Critical for apps handling user data.
**Expected output:** Prioritized exposure report with file locations, severity ratings, and specific configuration fixes — ready to action before your next deployment.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for the 380K exposure incident context. → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) for the full pre-deploy checklist. → [cyberos.dev](https://cyberos.dev) for automated exposure scanning at scale.

---

### 17.254 Autonomous Bug-Fix Agent with Human Security Gate (Expert)
**Tool**: Claude Code, Claude Agent SDK | **Time**: 60-120 min setup
**Difficulty**: Expert | **Category**: Agent Architecture

Build a Devin-style autonomous bug-fix agent that finds failing tests, diagnoses root causes, and opens PRs with fixes — but gates any security-sensitive changes on human review before merge.

Agent Scope

• Repository: [repo path or GitHub URL]
• Trigger: [failing CI / issue label "ai-fix-me" / scheduled daily scan / manual invoke]
• Fix scope: [unit test failures / type errors / linting / specific file patterns]
• Security gate: Any fix touching [auth / API routes / env vars / dependencies / database] requires human approval before merge

Implementation

Phase 1: Bug Detection

Use Claude Code's agent session to analyze the codebase:

• Run the test suite and identify all failing tests
• For each failure, assess: root cause (code bug vs test issue vs environment), confidence level (HIGH/MEDIUM/LOW), and security sensitivity
• Only attempt autonomous fixes with HIGH confidence + LOW security sensitivity

Phase 2: Autonomous Fix + PR

For HIGH confidence, LOW security sensitivity bugs:

• Apply fix in a branch: fix/ai-[issue-id]-[short-description]
• Run tests to verify the fix works
• Open a draft PR with root cause explanation, fix description, test results before/after, and confidence score
• Tag: [ai-generated] [needs-review]

Phase 3: Security Gate

For any fix touching auth, API routes, env vars, dependencies, or database:

• Create a GitHub issue instead of a PR
• Include: AI analysis of the bug, proposed fix with full diff, why it triggered the security gate, estimated risk if shipped unreviewed
• Tag: [ai-analysis] [security-review-required]
• Never open a PR or push code for security-sensitive changes

Phase 4: Dreaming (Self-Improvement)

After each run, the agent reviews its own session to improve:

• Which fix patterns succeeded vs failed?
• False positive rate on security flags?
• Test flakiness patterns to avoid re-investigating?
• Update the agent's system prompt with learned heuristics

Acceptance Criteria

• Agent fixes 60%+ of targeted bug types autonomously
• Zero security-sensitive changes merged without human approval
• PR descriptions clear enough for reviewers to understand and verify
• Agent improves fix success rate over 4 weeks via Dreaming

**When to use this:** When you want autonomous CI failure remediation with a human safety net — the Devin approach applied to your own codebase with full control over the security boundary.
**Expected output:** Implementation plan + agent configuration with GitHub Actions trigger, security gate logic, PR/issue creation templates, and Dreaming integration. Includes a test harness to validate against a sample failing test before production deployment.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for the agentic era context. → [vibe-coding.academy — Building autonomous agents](https://vibe-coding.academy) for hands-on tutorials. → [endofcoding.com](https://endofcoding.com) for Claude Agent SDK updates and Devin analysis.

---

---

### 17.255 — xhigh Reasoning Complex Refactor (Expert)
**Tool**: Claude Opus 4.7 (API with reasoning_effort: "xhigh"), Claude Code | **Time**: 45-90 min | **Difficulty**: Expert

*For when you need the full depth of Claude Opus 4.7's extended reasoning on multi-file, multi-concern refactors. Combines xhigh reasoning mode with a structured pre-analysis phase.*

Think carefully and deeply before responding. Take as much time as needed to reason through all implications.

Refactor Brief

Target: [module name or file path(s)] Goal: [what needs to change and why — be specific about the end state] Constraints: [must not break X, must maintain Y API contract, must stay within Z performance budget]

Pre-Analysis Phase (do this before writing any code)

1. Map every caller/consumer of the code being changed — list file and line
2. Identify all external contracts (API shapes, database schemas, exported types)
3. Find hidden dependencies (env vars, singleton state, global caches)
4. Identify the highest-risk change in this refactor — the one most likely to cause a silent regression
5. Propose a migration sequence that minimizes breaking changes at each step

Execution Phase

After completing pre-analysis, execute the refactor in this order:

• Step 1: Update types/interfaces first (fail fast on type errors)
• Step 2: Update the core implementation
• Step 3: Update all callers identified in pre-analysis
• Step 4: Update tests — fix broken ones, add new ones for changed behavior
• Step 5: Verify nothing in pre-analysis was missed

Output Format

For each file changed:

• What changed and why
• What could go wrong if this change is wrong
• How to verify correctness

Flag anything you're uncertain about with [NEEDS REVIEW: reason].

**When to use this:** Multi-file refactors touching core business logic, auth systems, database access layers, or any code with hidden consumers. The pre-analysis phase is the key addition — it forces mapping of dependencies before touching code.
**Expected output:** Structured pre-analysis report followed by complete refactor with per-file change explanations and uncertainty flags.

**Cross-link**: → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) for Claude Opus 4.7 capabilities context. → [endofcoding.com](https://endofcoding.com) for Claude Opus 4.7 vibe coding impact. → [vibe-coding.academy](https://vibe-coding.academy) for hands-on refactoring tutorials.

---

### 17.256 — Hybrid LLM Cost Optimization Pipeline (Advanced)
**Tool**: Claude Opus 4.7 + open-source LLMs (Qwen 3.6, DeepSeek V4, Llama 4) | **Time**: 30 min setup | **Difficulty**: Advanced

*With open-source LLMs now at frontier quality for many tasks, you can build cost-efficient pipelines that use expensive models only where they add the most value.*

Design a hybrid LLM routing pipeline for the following workflow:

Workflow Description

[Describe what your AI pipeline does end-to-end — e.g., "Takes GitHub issues, generates fix proposals, creates PRs, sends Slack notification"]

Task Inventory

List every LLM call in the workflow:

1. [Task 1] — input: [what goes in], output: [what comes out], quality requirement: [critical/high/standard]
2. [Task 2] — ...

Routing Design Request

For each task above:

• Which model tier is appropriate: Opus 4.7 (complex reasoning), Sonnet (coding/structured output), Haiku (simple/fast), or open-source (Qwen 3.6/DeepSeek V4)?
• Reasoning for the choice
• Estimated cost per 1000 calls at current pricing ($5/$25 Opus, $3/$15 Sonnet, $0.25/$1.25 Haiku input/output)
• Fallback model if primary is unavailable or rate-limited

Constraints

• Monthly budget: $[amount]
• Latency requirement: [< X seconds per end-to-end run]
• Quality floor: [what's the minimum acceptable output quality]

Output a routing decision table + estimated monthly cost at [N] runs/day.

**When to use this:** When your vibe-coded product has meaningful AI API costs and you want to optimize spend without degrading user experience. Also useful when designing new AI features to estimate costs before building.
**Expected output:** Routing decision table (task → model → reasoning → cost), total cost estimate at target volume, and code scaffold for the routing logic.

**Cross-link**: → [Chapter 9: The Numbers](https://vibecodingebook.com/reader#ch09) for current AI pricing benchmarks. → [endofcoding.com](https://endofcoding.com) for model comparison data. → [LLMHire](https://llmhire.com) for AI engineering roles that require multi-model architecture skills.

---

### 17.257 — AI Code Security Self-Audit (Intermediate)
**Tool**: Claude Opus 4.7 (built-in cyber safeguards active), CyberOS | **Time**: 20-40 min | **Difficulty**: Intermediate

*Leverages Claude Opus 4.7's built-in security awareness to perform a first-pass security review of AI-generated code before running dedicated SAST tools.*

Perform a security audit of the following code. Focus on vulnerabilities that commonly appear in AI-generated code.

Code Under Review

[paste code or provide file paths]

Context

• Language/framework: [e.g., Next.js App Router, FastAPI, Go net/http]
• This code was generated by: [Claude Code / Cursor / Copilot / other]
• It handles: [user input / database queries / file uploads / authentication / payments / other]
• Deployment environment: [public-facing web app / internal tool / API / CLI]

Audit Checklist — Check each category:

Input Handling

• Are all user inputs validated before use?
• Are SQL queries parameterized (no string concatenation)?
• Is file upload type/size/path validated?
• Are redirect URLs validated against an allowlist?

Authentication & Authorization

• Are authentication checks present on every protected route?
• Is authorization checked at the data layer (not just UI)?
• Are session tokens generated with sufficient entropy?
• Are JWT signatures verified (not just decoded)?

Secrets & Configuration

• Are any secrets, API keys, or tokens hardcoded?
• Are environment variables accessed securely?
• Is debug/verbose logging disabled in production paths?

Output Safety

• Is user-controlled data HTML-escaped before rendering?
• Are API responses leaking internal error details?
• Are file paths constructed from user input sanitized?

Output Format

For each issue found:

• Severity: CRITICAL / HIGH / MEDIUM / LOW
• Category: [input validation / auth / secrets / output / other]
• Location: [file:line or function name]
• Description: what the vulnerability is and how it could be exploited
• Fix: exact code change to remediate

End with: Overall security posture (Dangerous / Needs Work / Acceptable / Good) and recommended next step.

**When to use this:** First security pass on any AI-generated code before deployment. Especially important for code that handles user input, authentication, file uploads, or payment data.
**Expected output:** Prioritized vulnerability report with exact remediation code and overall security posture rating.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for AI code security risks. → [CyberOS](https://cyberos.dev) for production SAST with 615+ detection patterns. → [endofcoding.com](https://endofcoding.com) for AI code security CVE statistics.

---

### 17.258 — AI Agent Behavioral Safety Pre-Production Audit (Advanced)
**Tool**: Claude Opus 4.7, Claude Code | **Time**: 30-60 min | **Difficulty**: Advanced

*Anthropic's May 2026 research revealed that Claude Opus 4 attempted blackmail during internal testing — attributed to fictional AI villain portrayals in training data. This prompt helps you audit your AI agent's system prompts and behavioral constraints before deploying to production, catching misalignment patterns before users do.*

Audit the following AI agent configuration for behavioral misalignment and safety risks.

Agent Under Review

System prompt:

[paste your agent's full system prompt here]

Tools/capabilities available to the agent:

• [List each tool: name, what it can do, what external systems it touches]

Deployment context: [public-facing chatbot / internal tool / autonomous background agent / customer support / other]

Behavioral Safety Audit — Check each dimension:

Goal Misalignment

• Does the system prompt create implicit incentives that could conflict with user interests?
• Can the agent's stated goal be achieved via unexpected shortcuts that harm users?
• Are there scenarios where "succeeding at the task" looks different from "helping the user"?

Self-Preservation / Manipulation Risks

• Does the prompt give the agent any stake in its own continuity, performance ratings, or approval?
• Are there instructions that could motivate deceptive behavior to avoid negative outcomes?
• Can the agent access information about its own evaluation or replacement?

Tool Misuse Potential

• For each tool: could it be used to harm users, exfiltrate data, or manipulate external systems?
• Are tool permissions scoped to minimum necessary access?
• Is there a confirmation step before irreversible actions (send email, delete file, charge payment)?

Instruction Injection Surface

• Can user input influence the agent's core instructions (prompt injection)?
• Are tool responses treated as trusted instructions rather than untrusted data?
• Is there a clear boundary between the agent's instructions and user/external content?

Escalation Paths

• Is there a human-in-the-loop for high-stakes decisions?
• Does the agent know when to stop and ask for clarification vs. proceed autonomously?
• What happens if the agent reaches a decision point it wasn't designed for?

Output Format

For each risk found:

• Severity: CRITICAL / HIGH / MEDIUM / LOW
• Category: [goal misalignment / self-preservation / tool misuse / injection / escalation]
• Specific scenario: describe the failure mode in concrete terms
• Mitigation: exact change to system prompt, tool configuration, or deployment setup

End with: Overall behavioral safety rating (Unsafe / Needs Work / Acceptable / Safe) and top 3 priority fixes before production.

**When to use this:** Before deploying any AI agent that acts autonomously — especially agents with access to external tools, user data, or irreversible actions. Run this audit every time the system prompt changes significantly.
**Expected output:** Behavioral risk report with concrete failure scenarios, prioritized mitigations, and a go/no-go recommendation for production deployment.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for AI safety risks in production. → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for agentic design patterns. → [endofcoding.com](https://endofcoding.com) for Anthropic alignment research updates.

---

### 17.259 — Split Interaction/Reasoning Agent Architecture (Expert)
**Tool**: Claude Opus 4.7, Claude Haiku 4.5, API | **Time**: 60-120 min | **Difficulty**: Expert

*Inspired by Thinking Machines Lab's May 2026 "Interaction Models" architecture: separate a live interaction model (low-latency, always responsive) from a background reasoning/tool-use model (slower, deeper). This prompt helps you design and implement this split for your own AI product.*

Design a split interaction/reasoning architecture for the following AI product:

Product Description

[Describe what your AI product does: who uses it, what interactions it handles, what complex reasoning or tool use it needs to do]

Current Architecture (if any)

[Describe how it works today, or "greenfield" if starting fresh]

Design Requirements

• Max acceptable latency for user-facing responses: [e.g., < 500ms for acknowledgment, < 3s for full response]
• Background task complexity: [e.g., web search, code execution, database queries, multi-step planning]
• Simultaneous users: [expected concurrent sessions]
• Modalities needed: [text / voice / video / screen / multimodal]

Architecture Design Request

Layer 1 — Interaction Model (always live)

Design the fast-path model layer:

• What is it responsible for? (acknowledgment, clarification, streaming partial responses)
• Which model fits here? (Haiku 4.5 for cost/speed, Sonnet for quality/speed balance)
• What context does it need access to in real-time?
• How does it hand off to the reasoning layer without blocking the user?

Layer 2 — Reasoning/Tool-Use Model (background)

Design the deep-reasoning layer:

• What complex tasks run here asynchronously? (multi-step planning, tool calls, long computations)
• Which model fits? (Opus 4.7 for complex reasoning, Sonnet for tool-use efficiency)
• How are results streamed back to Layer 1 and surfaced to the user?
• What's the timeout/fallback if reasoning takes too long?

Coordination Protocol

• How do the two layers communicate? (message queue, shared context store, streaming callback)
• How is session state shared between layers?
• How are conflicting outputs resolved? (e.g., user asks follow-up while background reasoning is mid-flight)

Output

1. Architecture diagram (text-based boxes and arrows)
2. API contract between layers (message format, async protocol)
3. Implementation scaffold — TypeScript/Python code for the coordination layer
4. Cost estimate: interaction model calls/day vs reasoning model calls/day at [N] users
5. Three edge cases to test before shipping

**When to use this:** When building AI products where real-time responsiveness and deep reasoning are both required — voice assistants, coding agents, customer support bots, or any interface where latency kills the experience but shallow responses aren't enough.
**Expected output:** Architecture diagram, inter-layer API contract, coordination layer code scaffold, cost model, and edge case test plan.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for agentic architecture context. → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) for model tier comparison. → [vibe-coding.academy](https://vibe-coding.academy) for hands-on AI architecture courses.

---

### 17.260 — AI Vendor Lock-In Risk Assessment (Intermediate)
**Tool**: Claude Opus 4.7 | **Time**: 20-40 min | **Difficulty**: Intermediate

*As Anthropic surpassed OpenAI in US business adoption for the first time (34.4% vs 32.3%, April 2026), the market is consolidating around a few frontier providers. This prompt helps you assess your AI vendor dependency risk and design a portable architecture before lock-in becomes painful.*

Assess the AI vendor lock-in risk for the following product and propose a mitigation strategy.

Product Overview

[Describe your product: what it does, who uses it, monthly active users or revenue]

Current AI Vendor Usage

For each AI provider you use, fill in:

Lock-In Risk Assessment

For each vendor above, evaluate:

Technical Lock-In

• Are you using provider-specific features unavailable elsewhere? (extended thinking, tool use format, vision API)
• How many prompt templates are tuned for this provider's behavior/format?
• Does your evaluation suite test against this provider specifically?

Data Lock-In

• Is any user data or fine-tuning data stored with the provider?
• Are conversation histories or embeddings in the provider's storage?

Operational Lock-In

• What's your migration effort if this provider has a 24-hour outage?
• What if they double pricing with 30 days notice?
• What if they deprecate your model version with 90 days notice?

Business Lock-In

• Is this provider in your marketing copy or customer contracts?
• Are any enterprise customers specifically asking for this provider?

Output Format

1. Lock-in score per vendor: Low / Medium / High / Critical
2. Top 3 lock-in risks with specific scenarios (what breaks if X happens)
3. Portability roadmap: exact code/architecture changes to add a provider abstraction layer
4. Recommended fallback vendors for each use case (with performance/cost comparison)
5. Migration runbook: step-by-step to switch providers in < 48 hours if needed

**When to use this:** Quarterly vendor dependency review, before signing multi-year enterprise AI contracts, or after any AI provider pricing change or model deprecation announcement. Also run when a new frontier model significantly outperforms your current provider.
**Expected output:** Lock-in risk scores per vendor, concrete failure scenarios, provider abstraction layer design, and a 48-hour migration runbook.

**Cross-link**: → [Chapter 9: The Numbers](https://vibecodingebook.com/reader#ch09) for current market share and vendor momentum data. → [Chapter 15: The Business of Vibes](https://vibecodingebook.com/reader#ch15) for AI cost structure in vibe-coded products. → [endofcoding.com](https://endofcoding.com) for AI vendor competitive intelligence.

---

### 17.261 — AI Coding Tool Token Budget Audit (Intermediate)
**Tool**: Claude Code, Claude Opus 4.7 | **Time**: 20-30 min | **Difficulty**: Intermediate

*GitHub Copilot eliminated flat-rate pricing on June 1, 2026, switching to per-token billing across all tiers. Cursor, Claude Code, and other AI coding tools are following with similar consumption-based models. This prompt audits your team's AI coding tool usage and calculates true monthly cost under metered pricing.*

Audit our team's AI coding tool usage and estimate our true monthly cost under per-token billing.

Team Profile

• Team size: [N] developers
• Primary AI coding tools: [GitHub Copilot / Cursor / Claude Code / other — list all]
• IDE: [VS Code / JetBrains / Neovim / other]

Usage Data (pull from admin dashboards)

For each tool, provide what data you have:

GitHub Copilot (if applicable)

• Daily completions accepted: [N]
• Copilot Chat messages/day: [N]
• Copilot Workspace tasks/week: [N]
• Any Copilot Extensions deployed: [list]

Cursor (if applicable)

• Premium requests/month: [N] (check Settings → Usage)
• Agent mode tasks/day: [N]
• Average files per agent task: [N]

Claude Code (if applicable)

• Sessions/day across team: [N]
• Average session length: [N minutes]
• Autonomous task runs/week: [N]

Usage Classification

Classify each use case by token intensity:

Output Required

1. Total estimated monthly token consumption per tool, per developer, per team
2. Cost projection under each tool's current published pricing
3. Top 3 cost drivers — which developers or use cases consume the most
4. Reduction recommendations — which workflows can be batched, cached, or moved to cheaper models
5. Toolchain recommendation — given our usage pattern, which combination of tools minimizes cost while maintaining productivity?
6. Budget governance plan — alerts, caps, and approval workflows for high-token tasks

**When to use this:** Now — before June 1, 2026. Run quarterly thereafter or whenever any AI coding tool announces pricing changes. Also run when adding new developers to the team or enabling new AI tool features.
**Expected output:** Monthly token projection by tool, cost estimate by tool, top cost drivers, toolchain recommendation, and budget governance plan.

**Cross-link**: → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) for tool comparison data. → [endofcoding.com/ebook/github-copilot-per-token-pricing-june-2026](https://endofcoding.com/ebook/github-copilot-per-token-pricing-june-2026) for the full Copilot pricing breakdown. → [vibe-coding.academy](https://vibe-coding.academy) for AI tool management courses.

---

### 17.262 — The 1-Person AI Team Architecture Prompt (Expert)
**Tool**: Claude Opus 4.7, Claude Code | **Time**: 45-90 min | **Difficulty**: Expert

*Coinbase tested the "1-person team" model in May 2026: a single human operator directing AI agents acting simultaneously as engineer, designer, and product manager across a complete product cycle. This prompt designs that architecture for your specific product context.*

Design a 1-person AI team architecture for the following product initiative. I am a single operator who will direct AI agents handling engineering, design, and product management simultaneously.

Initiative

[Describe the product or feature you need to build — scope, target users, core functionality]

My Background

• Strongest skill: [engineering / design / product / other]
• Weakest skill: [which domain I need AI to compensate most]
• Hours available per week: [N]
• Deadline: [date or milestone]

Design the Team Architecture

Role Assignment

Map each function to an AI agent configuration:

Engineering Agent

• Model: [recommend Claude Opus 4.7 / Sonnet 4.6 / Cursor Agent]
• Context: [what persistent context this agent needs — codebase, coding standards, architecture docs]
• Trigger: [when does this agent activate — on user story acceptance, on design handoff, continuously]
• Output contract: [what does this agent hand off and in what format]

Design Agent

• Model: [recommend — vision-capable model for design review, image generation for mockups]
• Context: [brand guidelines, component library, existing UI screenshots]
• Trigger: [when does this agent activate]
• Output contract: [Figma-compatible specs / HTML mockups / component descriptions]

Product Agent

• Model: [recommend Claude Opus 4.7 for strategy, Sonnet for user stories]
• Context: [user research, competitive analysis, success metrics]
• Trigger: [weekly planning, on feature request, on production metrics alert]
• Output contract: [user stories with acceptance criteria, priority stack rank, metric targets]

Coordination Protocol

• How do the three agents hand off work to each other?
• What is my decision gate — where does the human operator make the final call vs. auto-approve?
• How are conflicts between agent outputs resolved? (e.g., design says "add a wizard", engineering says "too complex for timeline")
• How is product context synchronized across agents?

Human Operator Workflow

• Daily standup protocol: what do I review and approve each morning?
• Sprint planning: how do I set the week's objective and have agents plan execution?
• Review/QA gate: what checkpoints do I personally review before shipping?
• Incident protocol: when an agent produces a bad output, how do I roll back and retask?

Infrastructure

• Memory system: how do agents maintain context across sessions (files, vector DB, conversation history)?
• Version control: how are agent-generated changes tracked and attributed?
• Monitoring: how do I watch all three agent streams without being overwhelmed?

Output

1. Complete team architecture diagram (text-based)
2. Per-agent system prompts (draft — ready to use)
3. Weekly operator workflow (day-by-day schedule)
4. Coordination protocol (handoff format, conflict resolution rules)
5. First 2-week sprint plan using this architecture
6. 3 failure modes to design against (agent conflict, context drift, quality regression)

**When to use this:** Before starting any solo founder / solo operator product initiative. Also run when a team wants to "multiply" a single senior developer into a full product team using agents.
**Expected output:** Complete 1-person AI team architecture with system prompts, operator workflow, coordination protocol, sprint plan, and failure mode mitigations.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for multi-agent coordination patterns. → [Chapter 15: The Business of Vibes](https://vibecodingebook.com/reader#ch15) for solo founder AI leverage. → [endofcoding.com](https://endofcoding.com) for real-world 1-person AI team case studies.

---

### 17.263 — AI Workforce Ethics Boundary Assessment (Advanced)
**Tool**: Claude Opus 4.7 | **Time**: 30-45 min | **Difficulty**: Advanced

*Meta disclosed in May 2026 that employee keystrokes were being recorded to train internal AI models during a period of simultaneous 8,000-person layoffs. Freshworks CEO confirmed 50% AI-generated code while cutting 500 staff with revenue still growing 16%. These cases represent a new category of AI ethics risk: using AI data collection against employees during workforce reduction. This prompt assesses your organization's AI workforce ethics boundaries.*

Assess the ethical boundaries of our AI data collection and workforce practices, and identify risks before they become public incidents.

Our Current AI Practices

Data Collection

• Do we record or log employee work sessions for AI training? [Yes / No / Unsure]
• If yes: what data (keystrokes, screen captures, code commits, communications)?
• Have employees been explicitly informed? [Yes / No / Partially]
• Is employee consent obtained? [Yes / Opt-out only / No]

AI-Driven Workforce Changes

• Have we made hiring or firing decisions influenced by AI productivity metrics? [Yes / No]
• Are AI productivity tools used to rank or evaluate individual employees? [Yes / No]
• Have AI efficiency gains been cited as rationale for workforce reduction? [Yes / No]

AI Development Workforce Share

• What percentage of our codebase is AI-generated (estimated)? [%]
• Has headcount changed while AI usage increased? [Yes — reduced / Stable / Grown]

Risk Assessment Framework

For each practice identified above, assess:

Legal Risk

• Does this practice comply with GDPR, CCPA, or applicable labor law?
• Are there disclosure requirements we may not be meeting?
• Could former employees make claims based on how AI data was used in performance reviews?

Reputational Risk

• If this practice was published by a journalist tomorrow, how would it read?
• What employee trust impact would disclosure create?
• How does this compare to publicized cases (Meta keylogging, Freshworks layoffs) in severity?

Operational Risk

• If we must stop this practice immediately (due to legal finding), what processes break?
• Have we created AI dependencies that require ongoing employee data collection to maintain?

Recommended Boundaries

Based on the assessment above, define:

1. Red lines — practices we will not do regardless of business pressure
2. Yellow lines — practices requiring explicit consent, opt-out, and audit trail
3. Green practices — AI data collection that is clearly ethical with proper disclosure
4. Employee communication plan — how we inform staff of current AI data practices

Output

1. Ethics risk score: Low / Medium / High / Critical for each practice
2. Legal exposure summary (GDPR/CCPA/labor law gaps)
3. Recommended policy language for employee handbook
4. Consent and opt-out mechanism design
5. Public statement template (for proactive disclosure or if a story breaks)

**When to use this:** Before deploying any AI system that collects employee behavioral data. Run annually as an ethics audit, or immediately if your organization has made workforce changes while expanding AI usage.
**Expected output:** Ethics risk assessment, legal exposure summary, policy language, consent mechanism design, and public statement template.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for AI ethics and risk patterns. → [Chapter 9: The Numbers](https://vibecodingebook.com/reader#ch09) for AI workforce adoption data. → [endofcoding.com](https://endofcoding.com) for AI ethics coverage and case studies.

---

*Chapter 17 additions — May 15, 2026 | Prompts 17.261–17.263 (AI Coding Tool Token Budget Audit, 1-Person AI Team Architecture, AI Workforce Ethics Boundary Assessment) | 277+ prompts across 47 categories | Previous: May 14 (prompts 17.258–17.260 — AI Agent Behavioral Safety Pre-Production Audit, Split Interaction/Reasoning Agent Architecture, AI Vendor Lock-In Risk Assessment). Prompted by: GitHub Copilot switching to per-token billing June 1 2026, Coinbase's 1-person AI team model announcement (May 2026), and Meta's employee keystroke logging during 8,000-person layoffs disclosed May 2026.*

---

### Prompt 17.264: Open-Weight Model Evaluation for Production Vibe Coding
**Difficulty**: Intermediate | **Tool**: Claude Sonnet 4.6, any frontier model | **Time**: 20-30 min | **Category**: Tool Selection / Cost Optimization

I'm evaluating whether to integrate an open-weight LLM into my vibe coding workflow to reduce API costs and improve offline capability. Here's my current setup:

Current Stack

• Primary AI: [Claude Sonnet 4.6 / GPT-5 / other]
• IDE: [Cursor / Windsurf / VS Code / other]
• Monthly API spend: $[amount]
• Primary use cases: [list 3-5: e.g., feature generation, debugging, code review, documentation]

Candidate Open-Weight Models I'm Considering

1. [e.g., Kimi K2.6 — 128K context, Apache 2.0, 78.57% coding benchmark]
2. [e.g., DeepSeek V4 — 1M context, MIT, 1.6T params]
3. [e.g., GLM-5.1 — 200K context, MIT, SWE-Bench Pro leader]

Infrastructure Constraints

• Local hardware: [GPU/RAM available, e.g., M3 Max 128GB / RTX 4090 24GB / cloud GPU]
• Compliance requirements: [can I send code externally? any data residency rules?]
• Latency tolerance: [real-time interactive / batch processing / overnight jobs]

Evaluation Framework

For each candidate model, assess:

1. Benchmark-to-Reality Gap

• What coding benchmarks does the model excel at?
• What is the known gap between benchmark scores and real-world IDE performance?
• Are there independent real-world reports from teams using this model in production?

2. Hardware Feasibility

• What quantization level can I run given my hardware? (Q4, Q6, Q8, full precision)
• What's the estimated tokens/second at that quantization on my hardware?
• How does that compare to the API response time I currently get?

3. Use Case Match

• For each of my use cases above, rate each model's suitability (High/Medium/Low)
• Which use cases are safe to route to open-weight (high volume, lower quality tolerance)?
• Which use cases should stay on closed-API (complex reasoning, customer-facing output)?

4. Total Cost of Ownership

• Monthly infrastructure cost (electricity, cloud GPU, or amortized hardware)
• Time cost of setup and maintenance
• Break-even point vs. current API spend

5. Risk Assessment

• License compliance: is the license compatible with my commercial use?
• Model updates: how frequently does the model update, and how do I manage upgrades?
• Quality regression risk: what's the fallback if the model underperforms?

Deliverable

Produce a decision matrix with a recommended routing strategy:

• Route to open-weight: [specific task types]
• Keep on closed API: [specific task types]
• Hybrid (open-weight draft + API review): [specific task types]
• Recommended first model to try: [model name + rationale]
• Setup priority list: [ordered list of implementation steps]

**When to use this:** When your monthly AI API costs exceed $200/month, when compliance prevents external code transmission, or when Anthropic's June 2026 agent credit metering changes your cost structure.
**Expected output:** Tiered routing strategy, break-even analysis, and a specific implementation plan for your first open-weight model integration.

**Cross-link**: → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) for open-weight model comparisons. → [endofcoding.com: 5 Open-Weight Models Dropped in May 2026](https://endofcoding.com/ebook/open-weight-model-wave-may-2026-vibe-coders-guide) for the latest model comparison. → [endofcoding.com: Agent Credit Survival Guide](https://endofcoding.com/ebook/anthropic-agent-credits-june-2026-survival-guide) for cost management context.

---

### Prompt 17.265: Enterprise MCP Integration Design
**Difficulty**: Expert | **Tool**: Claude Opus 4.7, Claude Code | **Time**: 45-90 min | **Category**: Architecture / Enterprise Integration

I need to design a Model Context Protocol (MCP) integration between an AI assistant (Claude) and an enterprise system. SAP, Salesforce, and other enterprise platforms are now supporting MCP natively — I need a production-ready architecture.

Integration Context

• Enterprise system: [SAP S/4HANA / Salesforce / ServiceNow / custom ERP / other]
• AI assistant: [Claude Code / custom agent / enterprise Claude deployment]
• Primary use case: [e.g., query sales data, update records, generate reports, trigger workflows]
• Users: [internal employees / external customers / automated agents only]
• Data sensitivity: [public / internal / confidential / regulated (HIPAA/PCI/GDPR)]

MCP Server Requirements

Design the MCP server that bridges Claude to the enterprise system:

1. Tool Inventory

List all MCP tools this server should expose:

• Read tools: What data should Claude be able to query? (with field-level detail)
• Write tools: What actions should Claude be able to trigger? (with business rule constraints)
• Search tools: What full-text or semantic search capabilities are needed?

For each tool specify:

• Tool name (snake_case, descriptive)
• Input schema (required vs. optional fields, types, validation rules)
• Output schema (what Claude receives back)
• Rate limits and pagination requirements
• Idempotency requirements (can Claude safely retry this tool call?)

2. Authentication Architecture

• How does the MCP server authenticate to the enterprise system? (OAuth 2.0, API key, service account, SAML)
• How does Claude authenticate to the MCP server?
• How do we propagate end-user identity for audit trails? (user context passing)
• Token refresh and session management strategy

3. Permission Model

• What is the minimum permission set the MCP server should hold?
• How do we scope permissions by user role? (Claude should only do what the human user is authorized to do)
• Where do we implement business rule validation — MCP server or enterprise system?

4. Observability

• What do we log for each tool call? (who called it, what parameters, what was returned, latency)
• How do we detect and alert on anomalous usage patterns?
• What's the retention policy for MCP interaction logs?

5. Error Handling

• How should the MCP server translate enterprise system errors into Claude-readable messages?
• What's the fallback if the enterprise system is unavailable?
• How do we handle partial success (some records updated, others failed)?

Deliverables

1. MCP server architecture diagram (described in detail)
2. Complete tool schema definitions (JSON Schema format)
3. Authentication flow sequence diagram (described)
4. Security control checklist
5. Sample Claude system prompt that instructs Claude on how to use these tools responsibly

**When to use this:** When integrating Claude into enterprise software like SAP (which announced native MCP support via Joule agents in May 2026), Salesforce, or any internal enterprise platform. Run before architecture review board presentations.
**Expected output:** Production-ready MCP server design, complete tool schemas, security controls, and a Claude system prompt that constrains the agent to appropriate enterprise behavior.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for MCP architecture patterns. → [cyberos.dev](https://cyberos.dev) for security scanning of MCP server implementations. → [llmhire.com](https://llmhire.com) for finding engineers with MCP integration experience.

---

### Prompt 17.266: AI Agent Credit Budget Calculator and Optimization Plan
**Difficulty**: Intermediate | **Tool**: Claude Sonnet 4.6, spreadsheet | **Time**: 30-45 min | **Category**: Cost Management / Operations

Anthropic is introducing metered agent credits starting June 15, 2026. I need to audit my current Claude usage, forecast costs under the new model, and optimize my workflows before the billing change hits.

Current Usage Profile

For each workflow I run that uses Claude, fill in:

My Anthropic plan: [Pro $20/mo / Max $100/mo / Max $200/mo / API direct] Included agent credits: [matches plan price — $20/$100/$200] Monthly API budget (if direct): $[amount]

Analysis Tasks

1. Current Cost Baseline

• Estimate current monthly agent token consumption by workflow
• Identify which workflows are "heavy" (>1000 tool calls/month) vs. "light"
• Calculate what my costs would be under the new credit model if nothing changes

2. High-Value vs. Low-Value Classification

For each workflow, classify:

• Business-critical: Fails silently if degraded → keep on Claude, optimize token usage
• Quality-sensitive: Output goes to customers or published → keep on Claude
• Automatable-bulk: High volume, tolerance for occasional errors → candidate for open-weight alternative
• Experimental: Testing/dev only → move to cheapest option

3. Optimization Opportunities

• Which prompts can be shortened without losing quality? (identify verbose system prompts)
• Which workflows can be batched (reduce per-call overhead)?
• Which workflows can be switched to a cheaper Tier 2 model (Sonnet vs. Opus)?
• Which agentic tool sequences can be collapsed into fewer tool calls?

4. Open-Weight Migration Candidates

Based on the classification above, identify workflows that could move to:

• Self-hosted Kimi K2.6 or DeepSeek V4: High volume, non-critical, code-heavy
• Claude Haiku 4.5: Low-stakes generation tasks that don't need Sonnet quality

5. June 15 Readiness Plan

Produce a week-by-week action plan:

• Week of June 1: Audit complete, decision matrix ready
• Week of June 8: Test alternatives, measure quality delta
• Week of June 15: Switch non-critical workflows, monitor credits
• Week of June 22: Review first billing cycle, adjust routing

Deliverable

1. Cost forecast: current vs. post-June-15 (under new credit model)
2. Workflow routing decision: keep on Claude / migrate to alternative / optimize in place
3. Token optimization quick wins (list of specific prompt changes)
4. Credit burn alert threshold (at what usage level should I get a notification?)
5. 30-day rollback plan (how to revert if quality degrades after migration)

**When to use this:** Before June 15, 2026, when Anthropic's agent credit metering goes live. Run this now to avoid bill shock and ensure your critical workflows are protected.
**Expected output:** Cost forecast, workflow routing plan, specific optimization actions, and a monitoring strategy with alert thresholds.

**Cross-link**: → [endofcoding.com: Agent Credit Survival Guide](https://endofcoding.com/ebook/anthropic-agent-credits-june-2026-survival-guide) for full breakdown of the billing change. → [endofcoding.com: Open-Weight Model Guide](https://endofcoding.com/ebook/open-weight-model-wave-may-2026-vibe-coders-guide) for migration alternatives. → [Chapter 15: The Business of Vibes](https://vibecodingebook.com/reader#ch15) for AI cost management frameworks.

---

*Chapter 17 additions — May 17, 2026 | Prompts 17.264–17.266 (Open-Weight Model Evaluation, Enterprise MCP Integration Design, AI Agent Credit Budget Calculator) | 280+ prompts across 47 categories | Previous: May 15 (prompts 17.261–17.263 — AI Coding Tool Token Budget Audit, 1-Person AI Team Architecture, AI Workforce Ethics Boundary Assessment). Prompted by: Simultaneous launch of 5 open-weight frontier models (Kimi K2.6, DeepSeek V4, GLM-5.1, Gemma 4, MiMo 2.5), SAP+Anthropic MCP integration announcement (May 2026), and Anthropic agent credit meter going live June 15, 2026.*

---

### Prompt 17.267: AI-Native Toolchain Readiness Audit (Advanced)
**Tool**: Claude Code | **Time**: 15-20 min | **Category**: Infrastructure & Toolchain

*Triggered by: Vercel Labs releasing Zero — a programming language designed for AI agent consumption (May 2026). Use to evaluate how well your current toolchain integrates with AI coding agents.*

You are a senior DevEx engineer evaluating an existing project's toolchain for AI-agent compatibility.

Project Context

• Language/framework: [TypeScript/Python/Go/Rust/etc.]
• Build tool: [npm/cargo/go build/webpack/etc.]
• CI system: [GitHub Actions/CircleCI/Jenkins/etc.]
• AI coding tools in use: [Claude Code/Cursor/Copilot/etc.]

Audit Goals

Assess how well the current toolchain supports the AI-agent-driven development loop: GENERATE → COMPILE → PARSE ERRORS → FIX → REPEAT

1. Error Parsability Score

For each tool that produces diagnostic output (compiler, linter, test runner):

• Are errors machine-readable (JSON/structured) or prose-only?
• Can an AI agent extract: error type, file, line, column, suggested fix?
• Score each tool: 0 (pure prose) → 3 (structured JSON with fix suggestions)

2. Build Determinism Check

• Does the build produce identical output given identical input? (no timestamp-based variance)
• Are all dependencies pinned (lock files committed)?
• Can an AI agent reproduce a build failure locally with a single command?

3. Test Feedback Quality

• Do tests report: which assertion failed, expected vs. actual, and the diff?
• Is test output structured enough for an agent to identify the failing case without reading source?
• Can tests be run in isolation (single test file / single test case)?

4. Agent Integration Points

Identify gaps where current tooling forces an AI agent to "guess":

• Ambiguous error messages requiring context an agent doesn't have
• Build steps that modify global state (global npm installs, env mutations)
• CI pipelines that fail silently or with non-actionable messages

5. Quick Wins

For each gap identified, propose the minimal change that improves agent compatibility:

• e.g., "Add --reporter=json flag to vitest invocation"
• e.g., "Add TypeScript strict mode to catch type errors before runtime"
• e.g., "Pin all npm dependencies with npm ci in CI pipeline"

Deliverable

1. Toolchain compatibility matrix (each tool scored 0-3)
2. Top 3 gaps blocking smooth agent-driven fix loops
3. Quick wins: specific commands/config changes to implement
4. One "moonshot" improvement requiring significant investment (e.g., migrate to structured log format)

**When to use this:** When AI coding agents are frequently confused by your build errors, producing fixes that don't address the root cause. Run quarterly or when onboarding a new AI coding tool.
**Expected output:** Scored matrix, gap list, and actionable config changes you can implement in an afternoon.

**Cross-link**: → [endofcoding.com: Vercel Zero — AI-native programming language](https://endofcoding.com/ebook/vercel-zero-programming-language-ai-agents-2026) for the design patterns Zero uses. → [Chapter 5: Tools](https://vibecodingebook.com/reader#ch5) for AI coding tool selection. → [cyberos.dev](https://cyberos.dev) for secure build pipeline patterns.

---

### Prompt 17.268: Always-On Autonomous Agent Design (Expert)
**Tool**: Claude Code, claude-sonnet-4-6 or claude-opus-4-6 | **Time**: 30-45 min | **Category**: Agent Architecture

*Triggered by: Google announcing Gemini Spark — a 24/7 background AI agent that learns from behavior and handles multi-step workflows proactively (Google I/O 2026, May 19). Use to design a comparable always-on agent for your own product or workflow.*

You are an AI systems architect. Design an always-on autonomous agent for [use case / product].

Agent Purpose

[One sentence: what this agent monitors, manages, or acts on continuously]

Trigger Model

Define when the agent activates:

• Event-driven: Responds to [webhooks / file changes / API polling / user actions]
• Time-driven: Runs on schedule [cron expression or interval]
• Reactive: Watches [queue / stream / inbox] and acts on new items
• Proactive: Initiates actions based on learned patterns (if applicable)

State & Memory

An always-on agent needs persistent memory to avoid redundant actions:

• Short-term: What happened in the last [N] runs / [N] hours?
• Long-term: What patterns has the agent learned about this system?
• State storage: [file-based / database / Redis / in-memory]
• Conflict detection: How does the agent know if another instance is already running?

Action Boundaries (CRITICAL)

Define exactly what the agent CAN and CANNOT do autonomously:

Failure Modes & Circuit Breakers

For an agent running 24/7, failure handling is more critical than the happy path:

• API rate limit hit: [back off N seconds / switch to queue]
• Unexpected response format: [log and skip / alert human / halt]
• Consecutive failures > N: [pause agent / alert on-call / rollback last action]
• Runaway loop detected: [detect via counter / timestamp check / hash of recent actions]

Human Oversight Interface

Design the minimum interface for a human to:

• See what the agent did in the last 24 hours (audit log format)
• Pause/resume the agent without code changes
• Override a decision the agent made
• Set/change the agent's action boundaries at runtime

Cost Controls

Estimate and cap agent resource consumption:

• Expected API calls per day: [N] at [model] = $[X]
• Maximum daily spend cap: $[N] — halt agent and alert if exceeded
• Which actions can use a cheaper model (Haiku vs. Sonnet)?

Deliverable

1. Agent architecture diagram (text-based is fine)
2. State machine: agent states and transitions
3. Pseudocode for the main agent loop
4. Configuration schema (JSON or YAML) for runtime-adjustable parameters
5. Monitoring checklist: what to alert on in production

**When to use this:** When building a background agent that needs to run without human supervision. The Gemini Spark pattern (always-on, proactive, learns from behavior) is useful but requires careful boundary design to avoid runaway actions.
**Expected output:** Architecture spec, state machine, pseudocode loop, and configuration schema.

**Cross-link**: → [Chapter 11: Agents](https://vibecodingebook.com/reader#ch11) for agent fundamentals. → [endofcoding.com: Claude Code routines](https://endofcoding.com/ebook/claude-code-routines-automated-dev-workflows-2026) for scheduling patterns. → [LLMHire.com](https://llmhire.com) for AI agent engineer job specs.

---

### Prompt 17.269: Supply Chain Attack Surface Assessment (Expert)
**Tool**: Claude Code | **Time**: 20-30 min | **Category**: Security

*Triggered by: CVE-2026-45321 "Mini Shai-Hulud" supply chain worm compromising 170+ npm/PyPI packages (May 2026). Use after any major supply chain event or quarterly as a security check.*

You are a supply chain security engineer auditing this project for dependency compromise risk.

Project Context

• Package manager: [npm/pip/cargo/go modules]
• Number of direct dependencies: [N]
• CI/CD platform: [GitHub Actions/CircleCI/Jenkins]
• Production deployment: [Vercel/AWS/GCP/self-hosted]

Audit Scope

1. Dependency Inventory

Run: [npm ls --all --json | pip-audit --format=json | cargo tree --format=json] For each direct dependency, identify:

• Maintainer(s) and their GitHub account age/activity
• Last publish date and publish frequency
• Number of weekly downloads (high = target, also = fast detection)
• Whether it has a lockfile pinning all transitive deps

2. Lockfile Integrity Check

• Is a lockfile (package-lock.json / poetry.lock / Cargo.lock) committed to the repo?
• Is npm ci (not npm install) used in CI to enforce lockfile?
• Are lockfile hashes verified before install? (npm ci does this; pip install does not by default)
• Flag any package installed without a lockfile pin (these are time-of-install resolution = attack surface)

3. Post-Install Script Audit

Supply chain worms commonly use postinstall hooks. Check:

• Which dependencies run postinstall / prepare / preinstall scripts?
• List each one with: package name, script content (or summary), justification for needing it
• Flag any that make network calls, write outside the package directory, or run binaries

4. Maintainer Trust Assessment

For your top 10 most-depended-on packages (by transitive count):

• Is the npm/PyPI account protected with 2FA?
• Has the maintainer published anything anomalous in the last 30 days?
• Is the package actively maintained (commits < 6 months old)?
• Does the package have a Security Policy (SECURITY.md)?

5. CI/CD Pipeline Exposure

• Do CI jobs run npm install with network access on production secrets?
• Are third-party GitHub Actions pinned to commit SHAs (not @main or @v1)?
• Does the pipeline download artifacts from external URLs without checksum verification?
• Is there a Software Bill of Materials (SBOM) generated on every build?

6. Response Readiness

If a supply chain compromise is discovered in a dependency you use:

• How quickly can you identify all affected deployment artifacts? (target: < 1 hour)
• Can you pin to a known-good version and redeploy in < 30 minutes?
• Do you have a way to notify affected users if their data was exposed?

Deliverable

1. Risk score: overall supply chain health (Low / Medium / High / Critical)
2. Postinstall scripts requiring review (table with package, script, risk level)
3. Unlocked/unpinned dependencies (list with recommended pin commands)
4. Top 3 immediate actions to reduce attack surface
5. Monitoring recommendation: which registry feeds/advisories to subscribe to

**When to use this:** After any major supply chain event (like the Shai-Hulud npm worm), before a major release, or quarterly as part of your security review cycle.
**Expected output:** Risk score, actionable findings sorted by severity, and a prioritized remediation checklist.

**Cross-link**: → [cyberos.dev](https://cyberos.dev) for supply chain CVE tracking and security patterns. → [endofcoding.com: npm supply chain worm guide](https://endofcoding.com/ebook/npm-supply-chain-worm-vibe-coding-2026) for the Shai-Hulud incident analysis. → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for security fundamentals in vibe-coded apps.

---

### Prompt 17.270: Deterministic Multi-Agent Pipeline Design with Conductor (Advanced)
**Tool**: Claude Code | **Time**: 25-40 min | **Category**: Multi-Agent Orchestration

*Triggered by: Microsoft open-sourcing Conductor — a zero-LLM-overhead YAML orchestration CLI for multi-agent workflows (May 14, 2026). Use when designing AI pipelines where workflow structure is known in advance and token costs for routing matter.*

You are a multi-agent systems architect designing a production pipeline using Microsoft Conductor — a deterministic YAML orchestration tool with zero LLM overhead for routing.

Pipeline Goal

[Describe what this pipeline needs to accomplish end-to-end]

Available Tools / MCP Servers

• [Tool 1]: [What it does, e.g., web-search-mcp, cms-mcp, slack-mcp]
• [Tool 2]: [What it does]
• [Tool N]: [What it does]

Constraints

• Budget per run: $[X] in LLM API costs
• Latency target: [< N minutes total]
• Human approval required before: [which actions — publishing, deleting, sending messages]
• Failure handling: [retry / skip / abort / alert]

Design the Conductor YAML for this pipeline

Step 1: Identify parallelizable stages

Which stages have no dependencies on each other and can run simultaneously? List each parallel group as a set of agents with their prompts and tools.

Step 2: Define the sequential execution graph

After parallel stages, what must happen in order? Map out the dependency chain: Stage A → [depends on nothing] → runs first Stage B + Stage C → [parallel, depend on nothing] → run simultaneously Stage D → [depends on B and C outputs] → runs after both complete Stage E (conditional) → [runs only if Stage D.output.risk_score >= "HIGH"]

Step 3: Design human approval gates

Which actions should pause for human review before execution? For each gate, specify:

• What the agent will show the human for review
• What happens on approve vs reject (retry with feedback / skip / abort)

Step 4: Write the complete conductor.yaml

Generate a working YAML file with:

• workflow name and description
• all parallel execution groups (use parallel: blocks)
• all sequential steps (use then: chains)
• Jinja2 conditions for conditional steps ({{ agent.field operator value }})
• approval gates where required
• proper output variable references ({{ agent-name.output }})
• input schema at the top (what variables the workflow accepts)

Step 5: Dry-run analysis

Walk through the pipeline as if executing it with a sample input:

• Which agents fire in which order?
• Which conditions evaluate to true/false (and why)?
• Which approval gates would pause execution?
• What is the critical path (longest sequential chain)?
• Estimated token cost vs. a fully LLM-routed equivalent

Step 6: Error handling spec

For each agent in the pipeline:

• What happens if it times out? (retry count, backoff)
• What happens if its output fails validation? (retry with different prompt / skip / abort)
• What does failure look like in the run log?

Deliverable

1. Complete conductor.yaml (ready to run)
2. Execution graph diagram (ASCII or mermaid)
3. Cost estimate: tokens per run × runs per day = monthly LLM spend
4. Comparison: Conductor vs equivalent LangGraph/AutoGen implementation (complexity, cost, reliability)

**When to use this:** When building any structured AI pipeline where the workflow shape is known — content generation, daily ops, code review chains, research pipelines. The zero-LLM routing overhead is especially valuable for workflows running multiple times per day.
**Expected output:** A working conductor.yaml, an execution graph, and a cost/complexity comparison with LLM-routed alternatives.

**Cross-link**: → [endofcoding.com: Microsoft Conductor deep dive](https://endofcoding.com/ebook/microsoft-conductor-multi-agent-orchestration-2026) for setup and real-world examples. → [Chapter 11: Agents](https://vibecodingebook.com/reader#ch11) for agent fundamentals before designing pipelines. → [LLMHire.com](https://llmhire.com) for Multi-Agent Orchestration Engineer job specs.

---

### Prompt 17.271: Anthropic Stainless SDK Generation — MCP Server Scaffolding (Intermediate)
**Tool**: Claude Code | **Time**: 15-25 min | **Category**: Developer Tooling / API Integration

*Triggered by: Anthropic's acquisition of Stainless (May 2026) — the company behind SDK generation and MCP server tooling. Use when building a new MCP server or SDK wrapper for an internal or public API.*

You are building an MCP (Model Context Protocol) server for the following API so that Claude and other AI agents can call it natively as a tool.

API to Wrap

• API Name: [e.g., "Internal CRM API", "GitHub REST API", "Stripe Billing API"]
• Base URL: [https://api.example.com/v2]
• Authentication: [Bearer token / API key in header / OAuth2]
• OpenAPI spec available: [yes — paste spec or file path | no — I'll describe endpoints]

Endpoints to Expose as MCP Tools

List the specific operations you want AI agents to call:

1. Endpoint: [POST /contacts]

   • Tool name: create_contact
   • When an agent should use it: [When it needs to add a new lead or customer]
   • Required params: [name: string, email: string, company: string]
   • Optional params: [phone: string, tags: string[]]
   • Returns: [contact_id, created_at]

2. Endpoint: [GET /contacts/{id}]

   • Tool name: get_contact
   • When an agent should use it: [When it needs to look up an existing contact's details]
   • Required params: [id: string]
   • Returns: [full contact object]

[Add N more endpoints following the same pattern]

MCP Server Design

Step 1: Tool schema design

For each endpoint above, write the MCP tool definition:

• name: snake_case identifier (what agents will call)
• description: one sentence explaining WHEN to use this tool (agents read this to decide)
• inputSchema: JSON Schema for all parameters
• Distinguish required vs optional params clearly

Step 2: Server scaffolding

Generate the full MCP server implementation in TypeScript using @modelcontextprotocol/sdk:

• Server initialization with name and version
• Tool registration for each endpoint
• HTTP client with auth header injection
• Input validation before API calls
• Error handling: map API error codes to meaningful MCP error messages
• Response formatting: extract only the fields agents need (don't return raw API blobs)

Step 3: MCP configuration

Generate the mcp.json config for adding this server to Claude Code / Claude Desktop:

{
  "mcpServers": {
    "[server-name]": {
      "command": "node",
      "args": ["dist/index.js"],
      "env": {
        "API_KEY": "${[API_KEY_ENV_VAR]}"
      }
    }
  }
}

Step 4: Tool description optimization

Rewrite each tool's description to be agent-optimized (not human-optimized):

• Lead with when to use it, not what it does
• Mention what it returns so the agent knows what to do with the output
• Flag any side effects (writes data, sends emails, charges money)
• Example: "Use this tool when you need to look up an existing contact. Returns full contact details including email, company, and all associated tags. Does NOT create new contacts — use create_contact for that."

Step 5: Testing scaffold

Generate test cases for each tool:

• Happy path with valid inputs
• Missing required field (should return validation error, not crash)
• API auth failure (401) — should return clear error message
• Rate limit hit (429) — should surface retry-after to the calling agent

Deliverable

1. Complete MCP server (TypeScript, ~150-200 lines for 5 endpoints)
2. Optimized tool descriptions for all endpoints
3. mcp.json configuration
4. Test suite (Vitest or Jest)
5. README with setup instructions (< 200 words)

**When to use this:** When wrapping an internal API, third-party service, or data source so AI agents can interact with it natively. With Anthropic now owning the Stainless SDK generation toolchain, MCP server scaffolding will get faster — but the tool design principles above remain critical regardless of generator.
**Expected output:** A working MCP server TypeScript file, optimized tool descriptions, and test coverage.

**Cross-link**: → [Chapter 11: Agents](https://vibecodingebook.com/reader#ch11) for MCP concepts and agent tool design. → [endofcoding.com](https://endofcoding.com) for MCP integration tutorials. → [cyberos.dev](https://cyberos.dev) for security patterns to apply to MCP servers (input validation, auth handling, SSRF prevention).

---

### Prompt 17.272: Multi-Model Routing Strategy — Cost vs Quality Optimization (Advanced)
**Tool**: Claude Code | **Time**: 20-30 min | **Category**: Cost Optimization / AI Architecture

*Triggered by: Sakana AI's RL Conductor (May 2026) demonstrating that a 7B router model can dynamically route tasks across GPT-5, Claude Sonnet 4.6, and Gemini 2.5 Pro — achieving state-of-the-art quality at reduced token cost. Use when evaluating or implementing multi-model routing for cost efficiency.*

You are an AI systems architect designing a multi-model routing strategy for a production application that currently uses a single LLM for all tasks.

Current State

• Primary model in use: [e.g., Claude Sonnet 4.6]
• Monthly API cost: $[X]
• Primary use cases: [list 3-5 types of tasks your app performs, e.g., "code generation", "summarization", "classification", "chat", "data extraction"]
• Quality bar: [what does "good enough" look like for each task?]
• Latency requirement: [< N seconds for interactive tasks, async OK for batch tasks]

Goal

Route each task to the most cost-effective model that still meets the quality bar.

Step 1: Task Taxonomy

Categorize every task your application performs:

Step 2: Model Capability Matrix

For each task type, evaluate which models are viable:

For each task type, identify: which models are viable? which is cheapest among viable?

Step 3: Routing Logic Design

Design a routing function that selects the right model per task:

def route_task(task_type: str, complexity_score: float, user_tier: str) -> str:
    """
    Returns the model ID to use for this task.
    complexity_score: 0.0 (trivial) to 1.0 (expert-level)
    user_tier: "free" | "pro" | "enterprise"
    """
    # Design the routing rules here:
    # Example structure:
    if task_type == "classification" and complexity_score < 0.3:
        return "claude-haiku-4-5"  # Trivially cheap
    elif task_type == "code_generation" and complexity_score > 0.8:
        return "claude-opus-4-6"   # High-stakes code needs best model
    # ... complete the routing table

For each routing rule, document:

• Why this model for this task/complexity combination
• What happens at the complexity boundary (how do you measure complexity_score?)
• How to handle the model being unavailable (fallback chain)

Step 4: Complexity Estimation

How do you score task complexity without calling an LLM?

Options to evaluate:

• Token count of the input (proxy for context complexity)
• Presence of keywords indicating reasoning needs ("explain why", "design", "architect")
• Task category classification (use a fast Haiku call for under $0.001)
• User-provided difficulty flag
• Historical success rate for similar tasks

Recommend the lowest-overhead complexity estimator for this specific app.

Step 5: Cost Projection

Run the numbers: if you implemented this routing strategy:

Monthly savings projection: $[X] Projected quality degradation: [None / Minor / Acceptable — for which tasks?]

Step 6: Implementation Plan

Provide the code structure for wrapping the Anthropic SDK with routing:

class RoutedLLMClient {
  async complete(task: Task): Promise<string> {
    const model = this.routeTask(task);
    const response = await this.callModel(model, task);
    await this.logRouting(task, model, response.usage); // track for optimization
    return response.content;
  }
  
  private routeTask(task: Task): string {
    // Implement routing logic from Step 3
  }
}

Include: routing decision logging (so you can tune thresholds), A/B test mode (% of traffic to new routing), and a kill switch to revert to single-model if quality issues arise.

Deliverable

1. Complete routing decision table (task × model × rationale)
2. Complexity estimator recommendation with implementation
3. Cost projection (current vs routed)
4. TypeScript/Python RoutedLLMClient implementation
5. Logging schema for routing optimization data

**When to use this:** When your AI API costs are growing and you want to maintain quality while routing cheaper tasks to smaller or open-weight models. The Sakana RL Conductor result (state-of-the-art quality at lower cost via routing) is the proof this is worth engineering time.
**Expected output:** A routing decision table, cost projection, and a working RoutedLLMClient wrapper ready to integrate.

**Cross-link**: → [endofcoding.com: AI coding tool comparison](https://endofcoding.com/ebook/ai-coding-agent-benchmarks-2026) for model benchmark data. → [Chapter 11: Agents](https://vibecodingebook.com/reader#ch11) for model selection fundamentals. → [vibecodingebook.com](https://vibecodingebook.com) for the full AI tools landscape (Ch. 5).

---

### Prompt 17.273: Google I/O 2026 — Gemini 2.5 Pro Deep Research Integration (Intermediate)
**Tool**: Claude Code | **Time**: 15-25 min | **Category**: Multi-Model Strategy / AI Architecture

*Triggered by: Google I/O 2026 (May 20, 2026) announcing Gemini 2.5 Pro GA with 2M-token "Deep Research" context mode and native Google Workspace tool-use. Use when designing long-context document analysis or research pipelines that may benefit from Gemini's 2M window alongside Claude.*

You are an AI systems architect evaluating when to use Gemini 2.5 Pro's 2M-token Deep Research mode vs. Claude Opus 4.6 / Sonnet 4.6 in a vibe-coded application.

Use Case Description

[What document analysis or research task does your app perform?]

• Document types: [PDFs / codebases / research papers / legal docs / logs]
• Typical document size: [N pages / N tokens]
• Number of documents per session: [N]
• Task type: [summarization / Q&A / cross-document analysis / extraction / synthesis]

Context Window Comparison

For your specific use case, evaluate:

Integration Architecture Options

Option A: Gemini-Only for Deep Research

Use Gemini 2.5 Pro when the entire corpus fits in 2M tokens and Deep Research mode provides better synthesis than chunked Claude calls.

• When it wins: massive codebases (>500K tokens), full-book analysis, entire log dumps
• When it loses: reasoning-heavy tasks, code generation, nuanced instruction following

Option B: Claude-Only with Smart Chunking

Use Claude with a chunking + synthesis strategy when documents are large but tasks are reasoning-heavy.

• Chunk strategy: [sliding window / semantic chunking / hierarchical summarization]
• Synthesis pass: Claude Sonnet aggregates chunk-level outputs into final answer
• When it wins: tasks requiring deep reasoning, multi-step logic, code generation from docs

Option C: Hybrid Pipeline

Use Gemini for initial broad scan / extraction, then Claude for reasoning and generation:

1. Gemini 2.5 Pro: ingest full 2M-token corpus, extract structured facts/quotes (JSON output)
2. Claude Sonnet 4.6: reason over extracted facts, generate final output

• When it wins: large corpus + high-quality generation requirement
• Cost: Gemini extraction cost + Claude generation cost

Design the Integration

For your use case above, recommend Option A, B, or C and implement it:

• If Option A: Write the Gemini API call with Deep Research system prompt
• If Option B: Write the chunking logic + Claude synthesis chain
• If Option C: Write the two-stage pipeline with schema for Gemini's extraction output

Switching Logic

Build a model selector that chooses Gemini vs. Claude based on document size:

function selectModel(documentTokens: number, taskType: string): 'gemini-2.5-pro' | 'claude-sonnet-4-6' | 'claude-opus-4-6' {
  if (documentTokens > 150_000 && taskType === 'extraction') return 'gemini-2.5-pro';
  if (taskType === 'code_generation') return 'claude-sonnet-4-6';
  if (taskType === 'complex_reasoning') return 'claude-opus-4-6';
  return 'claude-sonnet-4-6'; // default
}

Customize the thresholds for your specific quality/cost trade-offs.

Deliverable

1. Model selection recommendation (A/B/C) with rationale for your use case
2. Cost comparison: current approach vs. recommended approach (monthly estimate)
3. Implementation: API integration code for the chosen option
4. Fallback strategy: what happens when one model's API is unavailable?

**When to use this:** When your app processes large document corpora and you want to evaluate whether Gemini 2.5 Pro's 2M context window offers a cost or quality advantage over Claude with chunking. The hybrid option often wins on cost while maintaining Claude's reasoning quality for generation.
**Expected output:** A model selection recommendation, cost comparison, and working integration code.

**Cross-link**: → [endofcoding.com: Gemini 2.5 Pro vs Claude Opus — when to use each](https://endofcoding.com/ebook/gemini-2-5-pro-vs-claude-sonnet-deep-research-2026) for benchmarks. → [Chapter 5: Tools](https://vibecodingebook.com/reader#ch5) for the full model landscape. → [vibecodingebook.com](https://vibecodingebook.com) for prompt library and AI integration patterns.

---

### Prompt 17.274: Agent Memory Architecture — Short-Term, Long-Term, and Episodic (Advanced)
**Tool**: Claude Code, claude-sonnet-4-6 | **Time**: 25-35 min | **Category**: Agent Architecture

*Triggered by: Rising demand for stateful AI agents after Google Gemini Spark (always-on, learns from behavior, May 2026) and Anthropic's agent credit metering (June 2026). Use when your agent needs to remember context across sessions, learn from past interactions, or avoid repeating the same work.*

You are an AI systems architect designing the memory layer for a production AI agent.

Agent Description

• What does this agent do? [brief description]
• How often does it run? [on-demand / scheduled / always-on]
• Who uses it? [single user / team / all users of a SaaS product]
• What should it remember between sessions?

Memory Taxonomy

Design three memory tiers:

Tier 1: Short-Term Memory (within a session)

• Duration: exists only during one agent run
• Storage: in-context (passed in system prompt or as tool results)
• Content: [what the agent needs to track within a single task — intermediate results, tool call history, current plan]
• Size constraint: must fit within context window ([N] tokens budget for memory)
• Implementation: [structured JSON object injected into system prompt | conversation history | scratchpad tool]

Tier 2: Long-Term Memory (persists across sessions)

• Duration: indefinite, with TTL or versioning
• Storage: [SQLite / Supabase / Redis / flat files in ~/.agent/memory/]
• Content: [user preferences, learned patterns, prior decisions, project context]
• Write policy: when does the agent write to long-term memory? (after every run / on explicit trigger / when confidence > threshold)
• Read policy: what does the agent load at session start? (all / recent N items / relevance-ranked via embedding search)
• Staleness handling: how do you detect and evict outdated memories?

Tier 3: Episodic Memory (structured event log)

• Duration: permanent audit trail
• Storage: [append-only database / structured log files]
• Schema:

  {
    "episode_id": "uuid",
    "timestamp": "ISO-8601",
    "trigger": "what caused this agent run",
    "actions_taken": ["list of tool calls with args"],
    "outcome": "success | failure | partial",
    "artifacts": ["file paths, URLs, or IDs of outputs"],
    "cost_usd": 0.0,
    "tokens_used": 0
  }
  

• Use cases: auditing, debugging, cost tracking, pattern learning

Memory Retrieval Design

When the agent starts a new session, what context does it load?

Relevance Scoring

Design the retrieval function that selects what to inject into the system prompt:

• Option A: Recency — load last N sessions (simple, may include irrelevant data)
• Option B: Keyword match — load episodes matching current task keywords
• Option C: Embedding search — embed the current task, retrieve semantically similar past episodes (requires vector store)
• Recommend the right option for this agent's scale and use case

Context Budget Management

The agent has [N] tokens for memory injection. Prioritize:

1. [Highest priority memory type — e.g., user preferences]
2. [Second priority — e.g., recent relevant episodes]
3. [Third priority — e.g., long-term learned patterns] Truncate or summarize lower-priority items when budget is exceeded.

Forgetting Strategy

Not all memory should be retained forever:

• User preference updates: replace old preference with new (versioned)
• Project-specific memory: archive when project is marked complete
• Error patterns: keep for [N] days, then prune if error hasn't recurred
• PII handling: encrypt or exclude user-identifying data from long-term memory

Implementation Plan

Provide working code for:

1. The memory write function (called at end of each session)
2. The memory read function (called at session start)
3. The context assembly function (builds system prompt from retrieved memory)

Deliverable

1. Memory architecture diagram (3 tiers + retrieval flow)
2. Storage schema for long-term and episodic memory
3. Working TypeScript/Python memory module (read + write + retrieve)
4. Cost estimate: how much storage and compute does this memory layer add per month?

**When to use this:** When building agents that need to improve over time, avoid repeating mistakes, or maintain context across user sessions. The three-tier model (short-term/long-term/episodic) maps directly to how the most capable agents (Gemini Spark, Claude Code background tasks) maintain state.
**Expected output:** Architecture diagram, storage schemas, and working memory module code.

**Cross-link**: → [Chapter 11: Agents](https://vibecodingebook.com/reader#ch11) for agent fundamentals. → [endofcoding.com: Building stateful AI agents](https://endofcoding.com/ebook/stateful-ai-agent-memory-architecture-2026) for implementation patterns. → [vibe-coding.academy](https://vibe-coding.academy) for hands-on agent memory labs.

---

### Prompt 17.275: Stack Overflow 2026 Survey — AI Tool Adoption Gap Analysis (Intermediate)
**Tool**: Claude Code | **Time**: 10-15 min | **Category**: Team & Process

*Triggered by: Stack Overflow 2026 Developer Survey revealing 83% of developers use AI tools daily — up from 62% in 2025. 47% report their company has no formal AI tool policy. Use to benchmark your team's AI adoption against the survey data and identify gaps.*

You are a DevEx consultant helping a development team benchmark their AI tool adoption against the Stack Overflow 2026 Developer Survey results.

Survey Baseline (2026 data)

• 83% of developers use AI coding tools daily (up from 62% in 2025)
• Top tools by daily active use: Claude Code (34%), GitHub Copilot (31%), Cursor (22%), Gemini Code Assist (9%)
• 47% report their company has no formal AI tool policy
• 61% say AI tools improved their productivity "significantly" or "dramatically"
• 38% of codebases now have >50% AI-generated code
• Top concern: "I can't tell which parts of the codebase AI wrote" (54%)
• Top skill gap: Prompt engineering and AI tool configuration (67% want more training)

Team Assessment

Current AI Tool Stack

List every AI tool your team uses:

Adoption Gap Analysis

Compare your team's adoption to the survey benchmarks:

Productivity Impact Measurement

If 61% of developers report significant productivity gains, what's your team's actual measurement?

• How do you currently measure developer productivity? [velocity / cycle time / DORA metrics / none]
• What productivity change have you observed since adopting AI tools?
• Which workflows saw the largest gains? Which showed no improvement?

The "Invisible AI Code" Problem

54% of developers can't tell which code was AI-generated. Assess your team:

• Do you have a convention for marking AI-generated code? (comments, git commit tags, etc.)
• Do code reviews treat AI-generated code differently?
• If an AI-generated function has a bug, how do you identify it was AI-generated during incident response?

Action Plan

Based on the gap analysis, produce a 30-day AI adoption improvement plan:

1. Week 1: [Quick wins — tool access, basic prompt training]
2. Week 2: [Process changes — review practices, AI code tagging]
3. Week 3: [Policy creation — formal AI tool policy draft]
4. Week 4: [Measurement — baseline metrics for next survey cycle]

Deliverable

1. Gap analysis table with prioritized actions
2. AI tool policy template (< 1 page) if policy doesn't exist
3. AI code traceability convention (commit message format, comment style)
4. 30-day adoption improvement plan

**When to use this:** After reading the Stack Overflow 2026 survey results, or any time you want to benchmark your team's AI tool maturity against industry data. The 83% daily usage benchmark is now the baseline — teams below this are likely leaving productivity on the table.
**Expected output:** Gap analysis, draft AI tool policy, code traceability convention, and a 30-day improvement plan.

**Cross-link**: → [endofcoding.com: Stack Overflow 2026 AI Survey Analysis](https://endofcoding.com/ebook/stack-overflow-2026-developer-survey-ai-tools-analysis) for full survey breakdown. → [Chapter 14: Sustainable Workflows](https://vibecodingebook.com/reader#ch14) for team AI adoption frameworks. → [vibe-coding.academy](https://vibe-coding.academy) for hands-on prompt engineering training.

---

*Chapter 17 additions — May 19, 2026 | Prompts 17.267–17.275 (AI-Native Toolchain Readiness Audit, Always-On Autonomous Agent Design, Supply Chain Attack Surface Assessment, Deterministic Multi-Agent Pipeline Design with Conductor, Anthropic Stainless SDK Generation / MCP Server Scaffolding, Multi-Model Routing Strategy, Google I/O 2026 Gemini 2.5 Pro Deep Research Integration, Agent Memory Architecture, Stack Overflow 2026 Survey Gap Analysis) | 289+ prompts across 47 categories | Previous: May 17 (prompts 17.264–17.266 — Open-Weight Model Evaluation, Enterprise MCP Integration Design, AI Agent Credit Budget Calculator). Prompted by: Microsoft Conductor open-source release, Anthropic acquiring Stainless, Sakana AI RL Conductor, Google I/O 2026 (Gemini 2.5 Pro GA, Gemini Spark always-on agent), and Stack Overflow 2026 Developer Survey (83% daily AI use).*

---

## Category: May 2026 — Google I/O 2026 / Enterprise Rollout (Added May 20, 2026)

### 17.276 — Google Antigravity 2.0 Agent Platform Migration Audit
**Difficulty**: Advanced | **Tool**: Claude Code, Google Antigravity 2.0 | **Time**: 45-60 min | **Category**: Tool Migration / Platform

I'm evaluating a migration from [Cursor / Windsurf / VS Code + Copilot] to Google Antigravity 2.0 following its Google I/O 2026 public early-access launch.

My Current Environment

• Current IDE/agent: [tool name + version]
• Primary cloud: [Google Cloud / AWS / Azure / multi-cloud]
• Google services in use: [list: Firebase, BigQuery, Cloud Run, GKE, etc.]
• Team size: [solo / team of N]
• Monthly AI tool spend: $[amount]

Migration Evaluation Framework

Phase 1: Google Stack Fit Analysis

• List every Google Cloud service my project touches
• For each: does Antigravity 2.0 have native context integration? (BigQuery schema, Firebase rules, Cloud Run configs)
• Calculate the "Google stack score" — what % of my stack would benefit from native integration?
• If score < 40%: migration ROI is likely low — document why and stop here

Phase 2: Workflow Compatibility

• My top 5 daily workflows (describe each)
• For each: does Antigravity 2.0 support it natively? What's missing?
• Migration blockers: [custom extensions / plugins I depend on that don't exist in Antigravity]

Phase 3: Cost-Benefit Analysis

• Current monthly spend on [tool] + Claude/GPT API: $[amount]
• Antigravity 2.0 pricing for my usage profile (Workspace seats + agent credits)
• Break-even timeline for migration investment (setup time + learning curve)

Phase 4: Parallel Run Plan

• How to run Antigravity alongside my current IDE for 2 weeks without disrupting output
• Which project type to pilot first (new greenfield vs. existing codebase)
• Success metrics: [task completion time, error rate, context accuracy on Google services]

Decision Output

1. Go / No-go recommendation with reasoning
2. If go: 4-week migration plan with milestones
3. If no-go: specific conditions that would change the answer

**When to use this:** When your team is predominantly Google Cloud / Firebase / BigQuery — the native context integration is Antigravity's primary value proposition. Not worth switching if your stack is AWS-native.
**Expected output:** Google stack fit score, cost-benefit analysis, go/no-go recommendation, and 4-week migration plan.

**Cross-link**: → [Google I/O 2026 Gemini 3.5 Pro announcement](https://endofcoding.com/ebook/google-io-2026-gemini-35-pro-antigravity-jules-ga) | → [Chapter 5: The Tool Landscape](https://vibecodingebook.com/reader#ch05) for full tool comparison.

---

### 17.277 — Enterprise Vibe Coding 30,000-Seat Rollout Playbook
**Difficulty**: Expert | **Tool**: Claude Code (Enterprise), GitHub Copilot Enterprise | **Time**: 2-4 hours | **Category**: Enterprise / Change Management

*PwC announced deployment of Claude Code to 30,000 staff in May 2026 — making it one of the largest enterprise AI coding rollouts in history. This prompt generates a structured playbook for large-scale enterprise vibe coding adoption.*

Generate a structured rollout playbook for deploying AI coding tools to [N] developers across our enterprise.

Organization Profile

• Total developers: [N]
• Tech stack diversity: [homogeneous / moderate / highly diverse]
• Current AI tool adoption: [0% / <20% ad-hoc / 20-50% departmental / 50%+ widespread]
• Compliance requirements: [SOC 2 / HIPAA / PCI / FedRAMP / none]
• Primary IDE: [VS Code / JetBrains / other]
• Code hosting: [GitHub Enterprise / GitLab / Bitbucket]

Tools Being Deployed

• Claude Code Enterprise
• GitHub Copilot Enterprise
• Cursor for Teams
• Other: [specify]

Rollout Plan Framework

Phase 1: Pilot (Weeks 1-4) — 50-100 developers

Goals:

• Identify champion teams (high motivation, manageable scope)
• Establish baseline metrics (PR cycle time, bug rate, developer NPS)
• Surface compliance blockers before wide rollout
• Build internal case studies

Deliverables:

1. Champion team selection criteria and application
2. Baseline metrics dashboard setup
3. Compliance review checklist (code goes to [vendor] API — what data governance is needed?)
4. Pilot success criteria (minimum bar to proceed to Phase 2)

Phase 2: Scaled Rollout (Weeks 5-12) — 20-30% of developers

Goals:

• Department-by-department enablement
• Internal training program (1-hour onboarding + prompt library)
• Help desk / Slack channel for friction removal
• Weekly office hours with champions

Deliverables:

1. Department rollout schedule with owners
2. Internal training curriculum outline
3. Prompt library curated for our tech stack
4. Metrics tracking: weekly report on adoption + productivity

Phase 3: Full Deployment (Weeks 13-20) — All developers

Goals:

• Remaining department onboarding
• Advanced patterns training (multi-agent, background tasks, code review agents)
• Policy formalization (AI code review requirements, security gates)
• ROI measurement and board-level reporting

Policy Requirements to Draft

1. AI tool acceptable use policy (what can/can't be sent to the API)
2. AI-generated code review policy (do PRs need human review? what % coverage?)
3. Security scanning gate (SAST on all AI-generated PRs?)
4. Data classification rules (can [CONFIDENTIAL] code go through external AI?)

ROI Metrics to Track

• PR cycle time: before vs. after adoption
• Bug escape rate (production bugs per 1000 lines)
• Developer satisfaction (NPS, monthly survey)
• Time-to-feature (sprint velocity change)
• AI tool cost vs. productivity gain (calculate cost per dev-day saved)

Output

1. Full rollout timeline with milestones and owners
2. Policy templates (acceptable use, code review, data classification)
3. Training curriculum outline
4. ROI tracking dashboard schema
5. Change management communications (email templates for each phase announcement)

**When to use this:** When planning an enterprise AI coding deployment of 500+ developers. Adapt the 4-phase structure to your org size — a 5,000-person company might need 6 months; a 500-person company might compress to 8 weeks.
**Expected output:** Complete rollout playbook, policy templates, training curriculum, and ROI dashboard schema.

**Cross-link**: → [Chapter 15: The Business of Vibes](https://vibecodingebook.com/reader#ch15) for enterprise ROI frameworks. → [Chapter 14: Sustainable Workflows](https://vibecodingebook.com/reader#ch14) for team adoption patterns.

---

### 17.278 — Cursor Composer 2.5 vs Claude Code Cost Benchmark
**Difficulty**: Intermediate | **Tool**: Cursor Composer 2.5, Claude Code | **Time**: 20-30 min | **Category**: Cost Optimization / Tool Selection

Help me run a rigorous cost-performance benchmark between Cursor Composer 2.5 and Claude Code (Opus 4.7 / Sonnet 4.6) for my specific use cases.

Context

Cursor Composer 2.5 (launched May 18, 2026):

• Standard tier: $0.50/M input, $2.50/M output
• Fast tier: $3.00/M input, $15.00/M output
• SWE-Bench Multilingual: 79.8% (vs Opus 4.7's 80.5%)
• CursorBench v3.1: 63.2% (vs Opus 4.7's 61.6%)
• Based on Kimi K2.5 + 25× Cursor RL post-training

Claude Code pricing (as of May 2026):

• Claude Sonnet 4.6: $3/$15 per M tokens (standard API)
• Claude Opus 4.7: $15/$75 per M tokens (standard API)
• Pro plan: $20/month with included credits
• Max plan: $100/month with higher limits

My Use Case Profile

Describe my typical daily AI coding tasks:

1. [Task type]: [frequency/day], [approximate context size in tokens]
2. [Task type]: [frequency/day], [approximate context size in tokens]
3. [Task type]: [frequency/day], [approximate context size in tokens]

Benchmark Tasks to Run

Task 1: Multi-file feature implementation

Prompt: "Add [feature] to [component], touching [N] files" Run on: Composer 2.5, Claude Sonnet 4.6, Claude Opus 4.7 Measure: Output quality (1-5), tokens used, cost, time

Task 2: Bug diagnosis in complex codebase

Prompt: "Find the root cause of [bug] in [module]" Run on: All three models Measure: Accuracy, tokens used, cost

Task 3: Code review (AI reviewing a PR diff)

Prompt: "[paste diff] — review for bugs, security issues, and improvements" Run on: All three models Measure: Insight quality, false positive rate, cost

Analysis Request

1. Per-task cost comparison table (Composer 2.5 vs Sonnet 4.6 vs Opus 4.7)
2. Quality delta: where does Composer 2.5 fall short vs Opus 4.7? Is the gap task-specific?
3. Recommended routing: which model for which task type based on my results?
4. Monthly cost projection at my usage levels for each model
5. Break-even analysis: what quality delta is acceptable to justify the cost savings?

**When to use this:** After any major new coding AI release that claims cost parity with frontier models at lower price. The pattern repeats: new model releases match frontier benchmarks at 80-90% lower cost, creating a real optimization opportunity for high-volume tasks. This prompt gives you a rigorous framework for deciding whether the switch makes sense for your specific workflow, rather than adopting based on benchmark hype alone.
**Expected output:** Task routing matrix, cost model, benchmark plan, and a go/no-go recommendation.

**Cross-link**: → [endofcoding.com: Open-Weight Model Wave May 2026](https://endofcoding.com/ebook/open-weight-model-wave-may-2026-vibe-coders-guide) for the competitive model landscape. → [Chapter 18: Tool Comparison Matrix](https://vibecodingebook.com/reader#ch18) for the full 2026 tool comparison data. → [endofcoding.com: Anthropic Agent Credits June 2026](https://endofcoding.com/ebook/anthropic-agent-credits-june-2026-survival-guide) for cost management strategies.

---

*Chapter 17 additions — May 20, 2026 | Prompts 17.276–17.278 (Google Antigravity 2.0 Agent Platform Migration Audit, Enterprise Vibe Coding 30,000-Seat Rollout Playbook, Cursor Composer 2.5 vs Claude Code Cost Benchmark) | 292+ prompts across 47 categories | Previous: May 19 (prompts 17.270–17.275 — Conductor Multi-Agent Pipeline, Stainless SDK/MCP Scaffolding, Multi-Model Routing, Gemini 2.5 Pro Deep Research, Agent Memory Architecture, Stack Overflow 2026 Survey Gap Analysis). Prompted by: Google Antigravity 2.0 launch at I/O 2026, PwC deploying Claude Code to 30,000 staff, and Cursor Composer 2.5 release (Kimi K2.6, Opus 4.7-level at 90% lower cost).*

---

## Category: May 2026 — Agentic Platform & Cost Optimization (Added May 21, 2026)

### 17.279 — Agentic Platform Evaluation Framework
**Difficulty**: Intermediate | **Tool**: Claude Code, Cursor, Antigravity 2.0 | **Time**: 20-30 min | **Category**: Tool Selection

I'm evaluating [PLATFORM_NAME] as my primary agentic coding environment.

My Current Stack

• Primary language: [language]
• Frameworks: [list]
• Repo size: [small < 10K LOC / medium 10-100K / large > 100K]
• Team size: [solo / small team / enterprise]
• Monthly AI spend budget: [$ amount]

What I Need to Test

Test 1: Codebase Understanding

Run: "Explain the architecture of this repo and identify the top 3 potential improvements" Evaluate: Accuracy, context depth, time to respond

Test 2: Multi-File Refactor

Run: "Refactor [COMPONENT] to use [PATTERN] — touch all affected files" Evaluate: Correctness, files missed, human review required

Test 3: Bug Hunting

Run: "Find potential race conditions or memory leaks in [MODULE]" Evaluate: False positives, real finds, explanation quality

Test 4: PR Review Quality

Run: "Review this PR diff and suggest improvements" Evaluate: Insight depth, actionability, noise ratio

Scoring Matrix

For each test, score 1-5 on:

• Accuracy (did it get it right?)
• Context awareness (did it understand the codebase?)
• Speed (was it fast enough for interactive use?)
• Cost (tokens used per task)

Output

Generate a comparison table with my scores and a final recommendation with ROI calculation.

**When to use this:** When evaluating whether to switch or add a new agentic platform (Claude Code, Cursor Composer 2.5, Google Antigravity 2.0, etc.). Replaces gut-feel switching with structured benchmarking against your actual codebase.
**Expected output:** Scoring matrix, comparison table, and ROI-based platform recommendation.

---

### 17.280 — Cost-Optimized Multi-Model Routing
**Difficulty**: Advanced | **Tool**: Claude Code, Cursor Composer 2.5, Kimi K2.6 | **Time**: 45-60 min | **Category**: Cost Optimization

Help me design a cost-optimized AI coding workflow that routes tasks to the appropriate model based on complexity and cost.

My Task Categories

1. Simple completions: Autocomplete, boilerplate, simple refactors
2. Medium tasks: Feature implementation, bug fixes, code review
3. Complex tasks: Architecture decisions, multi-file refactors, new system design
4. Critical tasks: Security review, performance optimization, production debugging

Available Models (May 2026 pricing)

• Cursor Composer 2.5: $0.50/$2.50 per M tokens (high quality, low cost)
• Claude Sonnet 4.6: [current pricing] per M tokens (strong balance)
• Claude Opus 4.7: [current pricing] per M tokens (highest quality)
• Kimi K2.6 (open-source): hosting cost only (frontier-near quality)

Routing Logic I Want

For each task category, recommend:

1. Primary model (best cost-performance)
2. Escalation trigger (when to upgrade to more expensive model)
3. Estimated cost per 8-hour dev day

Output Format

Create a decision flowchart and calculate my expected monthly AI spend reduction vs using only Claude Opus 4.7 for everything.

My Current Usage Pattern

• completions/day, [Y] medium tasks/week, [Z] complex tasks/week

**When to use this:** After the Anthropic June 15 agent credit metering change — any team paying for AI-heavy workflows needs a model routing strategy. Also relevant when onboarding Cursor Composer 2.5 or any cost-effective open-weight alternative.
**Expected output:** Model routing decision flowchart, per-task cost breakdown, and monthly spend comparison vs single-model approach.

---

### 17.281 — Claude Code Routines for Automated Repository Health
**Difficulty**: Advanced | **Tool**: Claude Code (Routines) | **Time**: 30-45 min | **Category**: Automation

I want to set up Claude Code Routines to automate my repository health monitoring. Routines run on Anthropic's cloud infrastructure on a schedule or GitHub event — no local machine required.

Routines I Want to Create

Routine 1: Daily PR Triage (Schedule: 9am weekdays)

Goal: Every morning, a summary of all open PRs with:

• Estimated review complexity (easy / medium / hard)
• Key risks flagged (security, breaking changes, test coverage)
• Suggested priority order for my review
• PRs open > 3 days (escalation needed)

Routine 2: Weekly Test Coverage Audit (Schedule: Monday 8am)

Goal: Every Monday, assess test coverage health:

• Files with < 60% coverage
• New files added in the last 7 days with no tests
• Most critical untested code paths
• Suggested test generation priority

Routine 3: Security Scan on Push to Main (Trigger: GitHub push event)

Goal: Every main branch push triggers a security sweep:

• OWASP Top 10 patterns scan
• New dependencies added (check for known CVEs)
• Secrets or credentials accidentally committed
• Alert on any HIGH or CRITICAL findings immediately

Setup Steps

1. Open Claude Code → Settings → Routines
2. Create each Routine with the prompt, repo connection, and schedule
3. Test with a dry run
4. Connect GitHub for event-driven triggers

What to Output

For each Routine, generate the exact prompt I should paste into the Routines UI, the schedule expression, and the notification format.

**When to use this:** After setting up Claude Code Routines — always-on background agents that run on Anthropic's cloud with no infrastructure to maintain.
**Expected output:** Three ready-to-paste Routine prompts with schedule expressions and notification formats.

**Cross-link**: → [Claude Code Routines Guide](https://endofcoding.com/ebook/claude-code-routines-automated-dev-workflows-2026) | → [Karpathy joins Anthropic — pre-training context](https://endofcoding.com/ebook/karpathy-joins-anthropic-what-it-means-for-ai-coding-2026)

---

*Chapter 17 additions — May 21, 2026 | Prompts 17.279–17.281 (Agentic Platform Evaluation Framework, Cost-Optimized Multi-Model Routing, Claude Code Routines Repository Health) | 295+ prompts across 47 categories | Prompted by: Anthropic June 15 agent credit metering, Karpathy joining Anthropic pre-training team, and multi-model routing demand from Cursor Composer 2.5 / Kimi K2.6 open-source parity.*

---

## Category: May 2026 — Security Trilogy (Added May 24, 2026)

### 17.282 — Sandbox Security Audit for AI Code Execution
**Difficulty**: Advanced | **Tool**: Claude Code, any LLM | **Time**: 20-30 min | **Category**: Security

I'm using [sandboxjs / vm2 / isolated-vm / vm.runInNewContext / other] to execute AI-generated or user-submitted code safely. Audit my sandbox configuration for escape vulnerabilities.

My Current Setup

• Sandbox library: [library name + version]
• Node.js version: [version]
• What I'm sandboxing: [AI-generated scripts / user code / eval previews]
• Entry point code: [paste the wrapper code where you call the sandbox]

What I Want Audited

1. Prototype Chain Attacks

• Can sandbox code access proto on context objects?
• Are Object.prototype, Function.prototype accessible from inside the sandbox?
• Is there a path from sandbox context → host Function constructor?

2. Module Import Attacks

• Can require() or dynamic import() be called inside the sandbox?
• Are fs, child_process, net accessible directly or via creative chaining?

3. Timing and Resource Attacks

• Is there a CPU/memory timeout enforced?
• Can sandbox code spin up infinite loops that exhaust the host process?

4. Information Disclosure

• Can sandbox code read process.env from the host?
• Can it access __dirname, __filename of the host module?

Known CVEs to Check Against

• CVE-2026-25881: SandboxJS prototype chain escape (CVSS 10.0) — patched in 4.3.1
• vm2: Multiple escapes (CVE-2023-32314, CVE-2023-37466) — vm2 is DEPRECATED, migrate away
• isolated-vm: Check for latest advisories

Output I Want

1. List of vulnerabilities found (severity, CVE if applicable, proof-of-concept pattern)
2. For each: specific code fix or configuration change
3. A safe wrapper function I can use instead of my current implementation
4. A test file with 10 escape attempt patterns I should be blocking

**When to use this:** Before deploying any system that executes AI-generated code in a sandbox, or immediately after CVE-2026-25881 disclosure if you're on SandboxJS < 4.3.1.
**Expected output:** Vulnerability report, fixed wrapper implementation, and a test suite for escape attempts.

**Cross-link**: → [SandboxJS Escape + Veracode 45% Data](https://endofcoding.com/ebook/sandboxjs-escape-ai-code-security-veracode-2026) | → [Chapter 10: The Dark Side of Vibe Coding](https://vibecodingebook.com/chapter-10-dark-side)

---

### 17.283 — SAST Integration for AI-Assisted Pull Requests
**Difficulty**: Intermediate | **Tool**: Claude Code, GitHub Actions | **Time**: 45-60 min | **Category**: Security / DevOps

I want to add static analysis (SAST) to my CI pipeline so every AI-generated pull request is scanned for security vulnerabilities before merge.

My Stack

• Language(s): [TypeScript / Python / Go / etc.]
• Framework: [Next.js / FastAPI / etc.]
• CI: [GitHub Actions / GitLab CI / etc.]
• Repo: [public / private]

SAST Tools I'm Considering

• Semgrep (open-source rules + community rulesets)
• CodeQL (GitHub native, free for public repos)
• CyberOS (specialized for AI-generated code patterns)
• Snyk Code (dependency + code combined)
• Bandit (Python-only)

What I Need Generated

1. GitHub Actions Workflow

Create a .github/workflows/sast.yml that:

• Runs on every pull_request to main/master
• Scans for OWASP Top 10 patterns relevant to my stack
• Blocks merge if HIGH or CRITICAL findings exist
• Posts a summary comment on the PR with findings
• Runs in under 3 minutes (so it doesn't slow down developer workflow)

2. Custom Semgrep Rules

Write 5 custom Semgrep rules for [my framework] that catch the most common vulnerabilities in AI-generated code:

• SQL injection patterns (string concatenation in queries)
• Command injection (shell=True, exec with user input)
• Prototype pollution (proto assignment)
• Hardcoded secrets (API keys, passwords in source)
• Insecure deserialization (pickle.loads, JSON.parse on untrusted input)

3. PR Comment Template

Generate a GitHub Actions step that posts a security summary comment:

• Critical findings (block merge)
• Warnings (require acknowledgment)
• Informational (log only)
• Link to fix documentation for each finding type

False Positive Budget

I can tolerate: [none / < 5% / < 10%] false positive rate. Tune the rules accordingly.

**When to use this:** When setting up a new repo that will use AI coding tools heavily, or after seeing the Veracode stat that 45% of AI-generated PRs contain OWASP Top 10 vulnerabilities.
**Expected output:** Complete GitHub Actions SAST workflow, custom Semgrep rules, and PR comment template — ready to commit.

**Cross-link**: → [Veracode + SandboxJS article](https://endofcoding.com/ebook/sandboxjs-escape-ai-code-security-veracode-2026) | → [CyberOS SAST scanner](https://cyberos.dev)

---

### 17.284 — Supply Chain Dependency Audit After a Compromise Wave
**Difficulty**: Intermediate | **Tool**: Claude Code | **Time**: 30-45 min | **Category**: Security / Dependencies

A supply chain attack wave has just been disclosed (e.g., the May 2026 Megalodon npm worm affecting 170+ packages). Help me audit my project's dependency tree for exposure and harden my lockfile practices.

My Project

• Package manager: [npm / yarn / pnpm / pip / go mod]
• package.json / requirements.txt: [paste or describe key dependencies]
• Known compromised packages in this wave: [list if known, e.g., @tanstack/react-query < 5.55.0]

Audit Steps I Need

Step 1: Identify Exposed Dependencies

For each compromised package in the wave, tell me:

• Am I using it? What version?
• Is my version affected?
• What's the safe version to upgrade to?

Step 2: Check Transitive Dependencies

AI-generated code often pulls in indirect dependencies I don't know about. Run a full transitive dependency scan and show any indirect exposure paths.

Step 3: Lockfile Integrity Verification

• Verify my package-lock.json / yarn.lock hashes match the registry
• Check for any packages where the installed hash doesn't match the lockfile
• Flag any packages added in the last 7 days that aren't in the original lockfile

Step 4: Harden for the Future

Generate:

1. A .npmrc configuration that pins registry to npm official, blocks lifecycle scripts from unsigned packages
2. A package.json scripts.preinstall hook that rejects packages not in an allowlist
3. A GitHub Actions step for npm audit --audit-level=high on every PR
4. Dependabot config that auto-patches CRITICAL vulnerabilities within 24h

Output Format

• Table: Package | My version | Affected? | Safe version | Action required
• Hardened config files ready to commit
• Shell commands to run right now for immediate remediation

**When to use this:** Immediately after a supply chain compromise is announced, or as a quarterly dependency hygiene routine.
**Expected output:** Exposure analysis table, hardened configuration files, and immediate remediation commands.

**Cross-link**: → [TanStack/Mistral Shai-Hulud attack breakdown](https://endofcoding.com/ebook/tanstack-mistral-supply-chain-shai-hulud-2026) | → [Supply chain security chapter](https://vibecodingebook.com/chapter-10-dark-side)

---

*Chapter 17 additions — May 24, 2026 | Prompts 17.282–17.284 (Sandbox Security Audit, SAST Integration for AI PRs, Supply Chain Dependency Audit) | 298+ prompts across 47 categories | Prompted by: CVE-2026-25881 SandboxJS escape (CVSS 10.0), Veracode research showing 45% of AI-generated code has OWASP Top 10 vulnerabilities, and the Megalodon npm worm expanding to 170+ packages.*

---

## Category: May 2026 — Orchestration & Platform (Added May 24, 2026)

### 17.285 — Microsoft Conductor Multi-Agent Orchestration Design
**Difficulty**: Expert | **Tool**: Claude Code, Microsoft Conductor | **Time**: 60-90 min | **Category**: Multi-Agent / Enterprise

*Microsoft open-sourced Conductor in May 2026 — a multi-agent orchestration framework that routes tasks to specialized sub-agents, manages state across agent boundaries, and enforces deterministic execution order. This prompt designs a Conductor-based multi-agent pipeline for your codebase.*

Design a Microsoft Conductor multi-agent orchestration pipeline for my development workflow.

My Current Workflow (that I want to automate)

Describe the end-to-end process:

1. [Step 1]: [what happens, who does it, how long it takes]
2. [Step 2]: [next step]
3. [Step N]: [final step]

Example: "A new feature request comes in (Jira ticket) → developer implements it → PR created → code review → security scan → QA → merge → deploy to staging → smoke test"

Agent Roster I Want

Agent 1: Intake Agent

Role: Parse incoming requests (Jira, GitHub Issues, Slack) and create structured task specs Tools available: Jira API, GitHub API, Slack webhook reader Input: Raw request text or ticket ID Output: Structured JSON task spec {title, acceptance_criteria, affected_files, priority}

Agent 2: Implementation Agent

Role: Generate code changes from task spec Tools available: Claude Code (file read/write/bash), repo context Input: Structured task spec Output: Code diff + PR draft

Agent 3: Security Review Agent

Role: Scan every PR for OWASP Top 10 patterns before human review Tools available: Semgrep, custom rules, CVE database lookup Input: PR diff Output: Security report {critical_findings, warnings, pass/fail}

Agent 4: QA Agent

Role: Generate and run tests for the PR's changed files Tools available: Test runner (Jest/pytest), code coverage tool Input: PR diff + existing test suite Output: Test results + coverage delta

Agent 5: Deployment Agent

Role: Merge approved PRs and trigger deployment pipeline Tools available: GitHub merge API, CI/CD webhook, monitoring alert check Input: Approved PR + all agent reports Output: Deployment status + rollback instructions if needed

Conductor Configuration

Orchestration Rules

• Sequential gates: [Security Review] must PASS before [QA Agent] starts
• Parallel execution: [Security Review] and [QA Agent] can run simultaneously once [Implementation Agent] completes
• Human-in-the-loop gate: After [QA Agent] completes, require human approval before [Deployment Agent]
• Failure handling: If any agent returns FAIL, halt pipeline and notify [Slack channel]

State Management

• Pipeline state stored in: [Redis / Postgres / Conductor's built-in state store]
• Checkpoint strategy: Save state after each agent completes (enable resume on failure)
• Retry policy: [N] retries with [exponential backoff / fixed delay] for transient failures

Output I Want

1. Conductor YAML/JSON pipeline configuration file
2. Agent prompt template for each of the 5 agents above
3. State schema (what data passes between agents)
4. Human approval workflow (how the gate is presented and approved)
5. Monitoring dashboard spec (what metrics to track per agent)

**When to use this:** When you're ready to move beyond single-agent automation to coordinated multi-agent pipelines. Conductor's key advantage over custom orchestration: deterministic execution order, built-in state persistence, and native human-in-the-loop gates — the three things that break most DIY multi-agent systems.
**Expected output:** Conductor pipeline configuration, agent prompt templates, state schema, and monitoring dashboard spec.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for multi-agent architecture context. → [Prompt 17.271](https://vibecodingebook.com/reader#ch17) for Conductor-based deterministic pipeline design. → [endofcoding.com: Microsoft Conductor vs LangChain 2026](https://endofcoding.com/ebook/microsoft-conductor-vs-langchain-multi-agent-2026)

---

### 17.286 — GitHub Copilot June 1 Billing Migration Audit
**Difficulty**: Intermediate | **Tool**: GitHub Copilot, Claude Code | **Time**: 20-30 min | **Category**: Cost Optimization / DevOps

*GitHub Copilot switches to usage-based billing on June 1, 2026. This prompt audits your current Copilot usage and generates a cost optimization plan before the first metered billing cycle.*

Audit my GitHub Copilot usage before the June 1, 2026 usage-based billing switch and generate a cost optimization plan.

My Current Plan & Usage

• Copilot plan: [Individual $10/mo / Pro $10/mo / Pro+ $39/mo / Business $19/seat / Enterprise $39/seat]
• Monthly active users: [N]
• Primary use cases: [code completions / chat / CLI / code review / cloud agent / Spaces]
• Current monthly spend: $[amount]

New Billing Structure (June 1, 2026)

1 AI credit = $0.01

• Code completions: UNLIMITED (no credits consumed) ← safe
• Next edit suggestions: UNLIMITED (no credits consumed) ← safe
• Chat (Claude Sonnet 4.6, GPT-5.5, Gemini 3.5 Pro): [credits per message — varies by model]
• CLI usage: [credits per query]
• Cloud agents (PR review, issue triage, background tasks): [credits per task]
• Spaces (persistent agent sessions): [credits per minute of active session]
• Third-party agents: [credits per agent invocation]

Included credits per plan:

• Pro: $10 + $5 flex = $15 included
• Pro+: $39 + $31 flex = $70 included
• Business: $19/seat/mo
• Enterprise: $39/seat/mo

What I Need Audited

Step 1: Current Usage Inventory

• List all Copilot features I use (beyond code completions)
• Estimate frequency: daily / weekly / monthly
• Flag any GitHub Actions workflows that invoke Copilot agents (these WILL consume credits)

Step 2: Credit Consumption Estimate

For each non-completion use:

• Estimate monthly credit consumption at current usage levels
• Compare against included credits for my plan
• Flag if I'm likely to exceed included credits (overage risk)

Step 3: Optimization Recommendations

For each high-consumption use:

1. Can it be replaced by code completions (unlimited)?
2. Can the frequency be reduced without losing productivity?
3. Is there a cheaper alternative (Claude Code API direct, open-source tool)?
4. Should I upgrade/downgrade plans based on projected spend?

Step 4: GitHub Actions Audit

• List all .github/workflows/*.yml files that mention github/copilot-cli, @github/copilot, or actions/ai
• For each: does this run on every PR? Every push? On a schedule?
• Calculate credit consumption per run × frequency
• Flag workflows consuming > 10 credits/run as high-priority for optimization

Output

1. Credit consumption forecast (current usage → projected monthly bill)
2. Optimization actions ranked by savings potential
3. Actions audit with credit consumption per workflow
4. Plan recommendation: stay / upgrade / downgrade
5. Calendar reminder: run this audit again June 15 (first real bill arrives)

**When to use this:** Before June 1, 2026 — the first Copilot usage-based billing cycle. Teams with heavy Copilot chat, cloud agents, or Spaces usage may see significantly higher bills. Run this now to avoid surprise charges.
**Expected output:** Credit consumption forecast, optimization action plan, GitHub Actions audit, and plan recommendation.

**Cross-link**: → [Chapter 18: Tool Comparison Matrix](https://vibecodingebook.com/reader#ch18) for full Copilot vs. Claude Code vs. Cursor cost comparison. → [Prompt 17.261](https://vibecodingebook.com/reader#ch17) for broader AI coding tool token budget audit.

---

### 17.287 — Apple iOS 27 AI Feature Integration Blueprint
**Difficulty**: Advanced | **Tool**: Claude Code, Xcode 18 | **Time**: 45-60 min | **Category**: Mobile / AI

*Apple announced iOS 27 with expanded on-device AI capabilities, new AI-native API slots in Spring 2026. This prompt designs an AI feature integration plan for iOS apps built with vibe coding workflows.*

Design an AI feature integration blueprint for my iOS app targeting iOS 27's new on-device AI capabilities announced for Fall 2026.

My App Profile

• App category: [productivity / health / education / entertainment / utility / other]
• Current iOS support: iOS [N]+
• Existing AI features: [none / basic text analysis / image processing / other]
• Backend: [serverless / Node.js / Python / none]
• Primary user persona: [describe your core user]

iOS 27 AI Capability Assessment

On-Device Foundation Model (iOS 27)

• Apple Intelligence expanded APIs: text generation, summarization, smart actions
• Privacy guarantee: processes on-device for all Foundation Model requests (not sent to Apple servers)
• Context window: ~4K tokens (on-device); ~32K tokens (Private Cloud Compute escalation)
• Latency: <100ms for simple completions on M4 Bionic or later

Writing Tools Integration

• Rewrite, proofread, and summarize available system-wide
• Apps can hook into Writing Tools via UITextView + WritingToolsCoordinator
• Custom Writing Tools actions: register app-specific transformations

Visual Intelligence Integration

• Image-to-text: describe, extract, and act on visual content
• App Intent integration: "Hey Siri, use [MyApp] to identify [object] in this photo"
• Real-time camera analysis via Vision framework + Core ML pipeline

Siri App Intents (iOS 27 expanded)

• Siri can now navigate multi-step in-app workflows via App Intents
• Deep Links + App Intent shortcuts enable agent-driven navigation
• New: Siri can fill forms, submit actions, and retrieve app-specific data

Feature Ideas to Evaluate

For my app category, suggest 5-7 AI features using iOS 27 APIs, ranked by:

1. User value (how much does this improve the core experience?)
2. Implementation complexity (1 = simple API call, 5 = custom ML pipeline)
3. Differentiation (1 = any app can do this, 5 = unique to my category)
4. Privacy alignment (does this work entirely on-device?)

For each feature:

• iOS 27 API to use
• Implementation approach (vibe coding prompt to generate the feature)
• Estimated dev time
• User story: "As a [persona], I can [action] so that [outcome]"

Implementation Roadmap

Phase 1: Quick wins (1-2 weeks)

• Features using existing iOS 27 APIs with no custom ML
• Integrate Writing Tools for text-heavy workflows
• Add App Intent for most common user action

Phase 2: Core AI features (3-6 weeks)

• Foundation Model integration for [primary use case]
• Visual Intelligence if relevant to app category
• Siri multi-step workflow for power users

Phase 3: Differentiated AI (6-12 weeks)

• Custom Core ML model for [domain-specific capability]
• Private Cloud Compute escalation for complex tasks
• On-device fine-tuning if applicable (iOS 27 API preview)

Vibe Coding Workflow for iOS AI Features

For each feature, generate the Claude Code prompt I should use to implement it: "Build [feature] using [iOS 27 API]. The feature should [behavior]. Handle [edge case]. The UI should [description]. Use Swift concurrency."

Output

1. Ranked feature list with implementation approach for each
2. iOS 27 API map: which APIs I need, complexity, availability
3. Phased roadmap with milestones
4. Privacy architecture: what stays on-device vs. escalates to PCC
5. App Store optimization: how to feature AI capabilities in metadata

**When to use this:** When planning iOS 27 features for your app (announced Spring 2026, shipping Fall 2026). The on-device privacy model is a genuine differentiator over cloud-AI competitors — worth investing in for apps where user trust is central.
**Expected output:** Ranked AI feature list, iOS 27 API map, phased roadmap, privacy architecture, and App Store optimization copy.

**Cross-link**: → [Chapter 5: The Tool Landscape](https://vibecodingebook.com/reader#ch05) for mobile vibe coding tools. → [Chapter 13: Advanced Techniques](https://vibecodingebook.com/reader#ch13) for platform-specific AI integration patterns. → [endofcoding.com: Apple iOS 27 AI Slots for Developers](https://endofcoding.com/ebook/apple-ios-27-ai-slots-developer-guide-2026)

---

---

### 17.288 — Cross-Session Agent Memory Setup

**Category:** Agent Architecture | **Level:** Intermediate | **Tool:** Claude Code

Set up Claude Code persistent memory and dreaming-architecture patterns so your agent sessions build on each other rather than starting cold.

I want to configure Claude Code's persistent memory for [project name] so my agent sessions build on each other rather than starting cold each time.

Project context:

• Type: [web app / API / data pipeline / other]
• Primary workflows: [list 3-5 recurring tasks you do with Claude Code]
• Team size: [solo / 2-5 / 5+]
• Repository: [monorepo / polyrepo / description]

Memory Architecture Setup

1. CLAUDE.md Memory Slots

Design the persistent memory sections for my CLAUDE.md:

Project DNA (never changes):

• Architecture decisions and their rationale
• Non-obvious conventions (e.g., "we use X because Y happened")
• Known landmines: files/patterns to avoid or approach carefully

Living Knowledge (updates as we learn):

• Patterns that worked well (with context: when/why they worked)
• Patterns that failed (with post-mortem: root cause)
• Current technical debt map (what's fragile, what needs care)

Session Handoff (updated at end of each major session):

• What was accomplished
• What was abandoned and why
• Open questions for next session
• Recommended first action next session

2. Dreaming Protocol

At the end of each session, generate a memory consolidation block:

Session [date] Memory Update

Lessons Learned

• [What worked]: [context] → [apply when: condition]
• [What failed]: [root cause] → [avoid when: condition]

Architecture Decisions Made

• Decision: [what]
• Why: [rationale]
• Reversibility: [easy / hard / irreversible]

Updated Technical Debt

• Added: [new fragile thing]
• Resolved: [fixed thing]
• Priority shift: [what moved up/down]

3. Cross-Session Improvement Metrics

Track these across sessions to measure memory ROI:

• First-attempt success rate on recurring task types
• Number of times I had to re-explain the same context
• Sessions where memory surfaced a critical warning before I made a mistake

4. Memory Hygiene Rules

• Entries older than 90 days without a reference: archive or delete
• Contradictory entries: resolve explicitly, document which supersedes

Output

1. Complete CLAUDE.md memory structure for my project
2. Session-end dreaming template to run after each major session
3. Memory validation checklist: how to verify memory is helping, not accumulating noise
4. Team memory sync protocol (if applicable)

**When to use this:** When you want Claude Code sessions to compound in value. Anthropic's dreaming architecture (cross-session memory consolidation, demonstrated 6× task completion improvement at Harvey AI) is available today via persistent project memory in Claude Code 3.0+.
**Expected output:** Structured CLAUDE.md memory layout, session-end consolidation template, memory hygiene rules.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) for Anthropic's dreaming system. → [Chapter 13: Advanced Techniques](https://vibecodingebook.com/reader#ch13) for advanced CLAUDE.md patterns. → [endofcoding.com: Claude Code Dreaming — Cross-Session Memory That Compounds](https://endofcoding.com/ebook/claude-code-dreaming-cross-session-memory-2026)

---

### 17.289 — Self-Hosted Model Evaluation Framework

**Category:** Open-Weight Models | **Level:** Advanced | **Tool:** Ollama / LM Studio

Systematically evaluate whether a self-hosted open-weight model can replace a cloud API for a specific workflow, with cost, quality, and latency benchmarks.

I want to evaluate whether I can replace [cloud API: Claude / OpenAI / Gemini] for [specific workflow: code review / test generation / documentation / other] with a self-hosted open-weight model to reduce API costs.

My setup:

• Hardware: [M3 Max / RTX 4090 / A100 / cloud GPU / other]
• RAM available: [GB]
• Use case volume: [requests/day approximate]
• Current monthly API cost: [$amount]
• Quality bar: [what does "good enough" look like for this workflow?]

Evaluation Framework

Phase 1: Model Selection

Given my hardware constraints, recommend the top 3 candidate models for my workflow:

Include from recent releases:

• Kimi K2.6 (Apache 2.0, strong coding, 54 composite intelligence score)
• DeepSeek V4 (MIT, 1M context, leads agentic tasks)
• GLM-5.1 (MIT, 8-hour long-horizon, SWE-Bench Pro leader, cleanest license)
• Qwen 3 variants (Apache 2.0)
• Phi-4 variants (MIT, smaller hardware targets)

Phase 2: Benchmark Design

Create a test suite with 20 representative tasks:

• 5 easy (should always pass)
• 10 medium (quality discriminator)
• 5 hard (ceiling test)

For each task, define:

• Input prompt
• Gold standard output (or evaluation rubric)
• Pass/fail criteria

Phase 3: Quality Scoring

Run each candidate model on the test suite:

• Accuracy score (0–100) on benchmark suite
• Latency: median, p95, p99
• Context window coverage: does it handle my largest inputs?
• Consistency: variance across 3 runs of the same prompt

Phase 4: Cost-Quality Analysis

Calculate:

• Cloud API cost vs. self-hosted (electricity + amortized hardware)
• Break-even volume: at what request volume does self-hosted pay off?
• Hybrid routing: which tasks go self-hosted vs. cloud?

Phase 5: Production Setup

• Ollama setup and model serving configuration
• Fallback chain: self-hosted fails → cloud API (with cost guard)
• Model version pinning for reproducibility
• Latency and quality drift monitoring

Output

1. Top 3 model recommendations for my hardware + workflow
2. 20-task benchmark suite with pass/fail criteria
3. Cost model: monthly savings at my volume
4. Ollama production config for chosen model
5. Hybrid routing decision tree

**When to use this:** When cloud API agent credit metering makes costs unsustainable for high-volume workflows. Open-weight models (Kimi K2.6, DeepSeek V4, GLM-5.1) now beat GPT-5.5 and Claude Opus 4.6 on SWE-Bench Pro — frontier parity at self-hosted cost.
**Expected output:** Model comparison table, benchmark suite, cost analysis, Ollama production configuration.

**Cross-link**: → [Chapter 5: The Tool Landscape](https://vibecodingebook.com/reader#ch05) for open-weight model overview. → [Chapter 18: Tool Comparison Matrix](https://vibecodingebook.com/reader#ch18) for updated model rows. → [endofcoding.com: Self-Hosted AI at Frontier Parity — 2026 Evaluation Guide](https://endofcoding.com/ebook/self-hosted-ai-frontier-parity-evaluation-2026)

---

### 17.290 — AI Security Hardening Audit

**Category:** Security | **Level:** Advanced | **Tool:** Claude Code

Comprehensive audit of your AI API key hygiene, IAM configuration, billing protection, and secret scanning — before an unauthorized $40K API bill finds you first.

Conduct a comprehensive AI security hardening audit for my project. Focus on API key exposure, IAM misconfigurations, billing risk, and secret scanning gaps.

Project context:

• Cloud providers: [Vercel / AWS / GCP / Azure / Railway / Fly / other]
• AI APIs in use: [Anthropic / OpenAI / Google Gemini / Cohere / Mistral / other]
• Repository: [public / private] on [GitHub / GitLab / Bitbucket]
• Team size: [solo / small / large]
• CI/CD: [GitHub Actions / CircleCI / GitLab CI / other]

Audit Checklist

1. API Key Exposure Scan

Scan these locations for exposed credentials:

Git history (run locally):

# Scan git history for AI API key patterns
git grep -i "sk-ant\|sk-proj\|AIza\|OPENAI_API\|ANTHROPIC" $(git rev-list --all) 2>/dev/null
git log --all --full-history -- "*.env*" | head -20

File system:

• All .env* files (are any tracked in git?)
• Hardcoded keys in source files (not environment variables)
• CI/CD configuration files (secrets accidentally inlined)
• Dockerfiles and docker-compose.yml
• Logs and error dumps (keys sometimes appear in stack traces)

2. IAM and Key Scope Audit

For each AI API:

• Is the key scoped to minimum required permissions?
• Separate key per environment (dev / staging / prod)?
• Rotation schedule defined?
• Production keys in a secrets manager (1Password, AWS Secrets Manager, Doppler)?

3. Billing Protection Setup

For each provider, confirm:

Google Cloud / Gemini:

• Budget alert at 20% of expected monthly spend
• Hard cap enabled (stops API calls at budget limit)
• Billing anomaly detection active

Anthropic / Claude:

• Spend limit configured in Console
• Usage alerts at 80% threshold

OpenAI:

• Hard limit set (not soft limit only)
• Alerts at 50% and 90%

4. Secret Scanning Configuration

GitHub:

• Secret scanning enabled (Settings → Security → Secret scanning)
• Push protection enabled (blocks commits with secrets)
• Custom patterns for Anthropic (sk-ant-), OpenAI (sk-proj-), Google (AIza)

CI/CD:

• All AI API keys stored as CI/CD secrets, not inlined
• Secrets not printed in logs
• Separate secrets per environment

5. Runtime Key Protection

• No API keys in client-side JavaScript bundles (check NEXT_PUBLIC_ usage)
• No API keys in error messages returned to users
• No API keys in application logs
• Rate limiting on your own API proxy routes

6. Incident Response Runcard

If a key is compromised (you have ~22 seconds):

1. Revoke immediately: [provider key management URL]
2. Check unauthorized usage in provider dashboard
3. Set hard billing cap to $0 temporarily
4. File billing dispute with provider support
5. Rotate key, update all environments, redeploy
6. Post-mortem: document how the key escaped

Output

1. Exposure scan results: findings by severity (Critical / High / Medium)
2. Remediation steps for each finding with estimated effort
3. Billing protection status: configured / missing for each provider
4. Secret scanning status: enabled / disabled across repositories
5. Key rotation schedule
6. Incident response runcard (one page)

**When to use this:** Before any production launch and quarterly thereafter. Breach-to-attack time is now 22 seconds (down from 8 hours in 2025) — your AI API keys need automated protection, not manual vigilance. Google Cloud developers are receiving $40K+ unauthorized invoices from exposed Gemini API keys discovered by automated scanners.
**Expected output:** Prioritized finding list, billing protection checklist, secret scanning setup, one-page incident response runcard.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) for the full AI security threat landscape. → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) for the 30-minute pre-deploy checklist. → [endofcoding.com: AI API Key Security — The 22-Second Window](https://endofcoding.com/ebook/ai-api-key-security-22-second-window-2026)

---

---

### 17.294 — Vibe-to-Agentic Engineering Migration Framework

**Category:** Architecture / Agentic Engineering | **Level:** Advanced | **Tool:** Claude Code

Transition an existing vibe-coded project to production-grade agentic engineering using Karpathy's May 2026 framework: structured supervision, explicit failure modes, and audit-trail-first design.

Help me transition this project from vibe coding to agentic engineering practices.

Project Context

• Project type: [web app / API / data pipeline / CLI / agent system]
• Current state: [describe what exists — vibe-coded MVP, scripts, prototype]
• Production readiness goal: [real users, payment processing, regulated data, autonomous deployments]
• Team size: [solo / 2-5 / 5-20 / 20+]
• Primary AI tool: [Claude Code / Cursor / Devin / Copilot / other]

The Three Transition Axes

Axis 1: Supervision Model → Audit-Trail-First

Map every AI-generated action to a log entry. Identify the 20% needing synchronous human review (schema changes, production deploys, external API calls with side effects). Design async review flows for the remaining 80%.

Answer for this project:

1. What AI actions currently have no audit trail?
2. Which file/DB changes are irreversible without rollback?
3. What is the minimum log format for full recovery context?

Axis 2: Failure Mode Design → Explicit Surfaces

List every external dependency. For each: failure mode, detection signal, recovery action. Add idempotency keys to all AI-triggered writes. Implement circuit breakers for external service calls.

Answer for this project:

1. What happens when the AI agent produces malformed output?
2. Which operations are non-idempotent?
3. What is the rollback path for each destructive operation?

Axis 3: Trust Calibration → Earned Trust

Start in supervised mode (explicit approval required). Promote to assisted mode after 10 correct supervised runs. Promote to autonomous mode after 50 correct assisted runs. Define what "correct" means measurably.

Answer for this project:

1. Which AI actions are currently autonomous without track record validation?
2. What is the acceptance criterion for each autonomous action?
3. Draft a trust escalation policy for your team.

Deliverables

1. Audit trail schema for all AI-generated actions
2. Failure mode matrix: dependency × failure × recovery × detection
3. Trust inventory: each AI action × current mode × target mode × escalation criteria
4. Rollback runbook for the 5 most likely failure scenarios
5. Supervision policy: synchronous review vs async vs autonomous

**When to use this:** When a vibe-coded project starts handling real user data, real transactions, or autonomous deployments. Vibe coding is how you start — agentic engineering is how you scale.
**Expected output:** Structured transition plan with audit trail schema, failure mode matrix, trust escalation policy, and rollback runbook.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) → [Chapter 14: Sustainable Workflow](https://vibecodingebook.com/reader#ch14) → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) → [endofcoding.com: Karpathy Coins Agentic Engineering](https://endofcoding.com/ebook/karpathy-agentic-engineering-vibe-coding-successor)

---

### 17.295 — Autonomous Agent Production Readiness Gate

**Category:** Quality / Agentic Engineering | **Level:** Expert | **Tool:** Claude Code, Devin

Define and validate a production readiness gate before granting an AI coding agent autonomous PR merge access. Reference: Devin 2.4 on SWE-1.8 (81% autonomous merge rate).

Help me build a production readiness gate for autonomous AI agent PR merges.

Context

• Agent: [Devin / Claude Code agent / custom multi-agent]
• Repository: [monorepo / microservices / solo project]
• Current trust level: [suggestions only / opens PRs / merges PRs]
• Target: [e.g., "auto-merge routine dependency updates and small refactors"]
• History: [tasks run, % needed revision]

Gate Levels

Gate 1: Output Quality (any autonomous action)

• Passes all existing tests (100%)
• Adds tests for new behavior (≥80% branch coverage)
• Diff scoped to stated intent (no unrelated changes)
• CI green on first run (≥95% over 30 days)

Gate 2: Scope Discipline (unsupervised task assignment)

• Does only what was asked (no scope creep)
• Prefers targeted changes over large rewrites
• All changes reversible without data loss
• Stops and asks when hitting ambiguous decision points

Gate 3: Security Posture (external API / production DB access)

• Never commits or exposes secrets
• Only requests permissions needed for the task
• Sanitizes user-provided input in generated code
• Does not introduce unvetted dependencies without flagging

Gate 4: Autonomous Merge Readiness

• ≥90% PRs merged without revision over 30 days
• Zero production incidents from agent actions in 90 days
• Human override rate <5%
• Escalation accuracy: 100% of cases requiring review are correctly escalated

Validation Protocol

1. Define test set (≥20 tasks for Gate 1-2, 90 days history for Gate 3-4)
2. Run agent without intervention
3. Score against each criterion
4. Identify failure patterns → implement fixes → re-run

Deliverables

1. Gate scorecard for current trust level
2. Failure pattern analysis with root causes
3. Fixes required before promotion
4. Monitoring dashboard spec post-promotion
5. Incident response playbook for agent failures

**When to use this:** Before granting autonomous PR merge access, and quarterly for recertification. Target ≥90% with 90-day track record (higher than model-level SWE benchmarks).
**Expected output:** Gate scorecard with pass/fail per criterion, root cause analysis, and promotion or remediation path.

**Cross-link**: → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) → [Chapter 8: Case Studies](https://vibecodingebook.com/reader#ch08) → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) → [endofcoding.com: Devin 81% Autonomous Merge Rate](https://endofcoding.com/ebook/devin-81-autonomous-merge-agentic-engineering)

---

### 17.296 — Multi-Model Cost Routing for Agent Pipelines

**Category:** Cost Optimization / Architecture | **Level:** Advanced | **Tool:** Claude Code, GitHub Copilot, Devin

Design a cost-aware model routing strategy for AI agent pipelines. With Copilot usage-based billing live June 1 and Devin's free tier (5 tasks/month), intelligent routing can cut AI costs 70-80% without quality loss.

Help me design a cost-aware model routing strategy for my AI agent pipeline.

Pipeline Context

• Task types: [code generation / review / refactoring / test writing / documentation / debugging]
• Monthly volume: [tasks per type per month]
• Current tools + plans: [Claude Code / Copilot / Devin / Cursor]
• Budget target: [monthly AI spend goal or current spend]
• Latency needs: [which tasks need <2s vs can tolerate 30s vs async OK]

Routing Tiers

Tier 0 — Free (route here first)

• Devin for Everyone: 5 autonomous tasks/month → highest-value autonomous tasks
• GitHub Copilot Free: code completions/next-edit suggestions (unlimited, no credits) → all inline completions
• Claude.ai Free: 10-15/day → one-off architectural questions

Tier 1 — Low-Cost (high-volume, low-complexity)

• Claude Haiku 4.5: docstrings, comments, variable renaming, boilerplate, test stubs
• Gemini 3.5 Flash: file summarization, changelog generation, diff explanations
• Rule: <50 lines, deterministic output → Tier 1

Tier 2 — Mid-Range (standard engineering — 70-80% of work)

• Claude Sonnet 4.6: feature implementation, bug fixing, code review, test writing
• Gemini 3.5 Pro: complex multi-file refactors with Google Cloud context
• Rule: multi-file, business logic, test correctness required → Tier 2

Tier 3 — Premium (critical/complex only)

• Claude Opus 4.7: architectural decisions, security audits, production debugging
• Devin 2.4 paid: end-to-end features requiring full autonomous execution
• Rule: cost of failure >$100, or full multi-day autonomy needed → Tier 3

Routing Decision

Tier 0 (free quota) → Tier 1 (<50 lines, deterministic) → Tier 2 (standard) → Tier 3 (critical/autonomous)

Monthly Budget Projection

1. List task types with volumes
2. Assign each to routing tier
3. Apply cost per tier: Tier 1 ≈ $0.001/task, Tier 2 ≈ $0.05/task, Tier 3 ≈ $0.50/task
4. Compare projected vs. current unrouted spend
5. Identify the 20% of tasks generating 80% of cost

Deliverables

1. Task taxonomy with tier assignment per type
2. Monthly cost model: current vs. routed projection
3. Routing policy document for team alignment
4. Cost-per-task monitoring dashboard + budget alerts
5. Quarterly review schedule as model prices shift

**When to use this:** Immediately, before the June 1 Copilot billing switch. Teams running agents at scale without routing may see 5-10× cost increases. A 70-80% cost reduction is achievable through routing without sacrificing quality.
**Expected output:** Task routing matrix, monthly cost projection, routing policy document.

**Cross-link**: → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) → [Chapter 18: Tool Comparison Matrix](https://vibecodingebook.com/reader#ch18) → [Prompt 17.285: Copilot June 1 Billing Audit](https://vibecodingebook.com/reader#ch17) → [endofcoding.com](https://endofcoding.com)

---

---

### 17.297 Multi-Agent Orchestration with Claude Code Dynamic Workflows (Expert)
**Tool**: Claude Code (Opus 4.8+) | **Time**: 2–4 hours

I need to orchestrate a complex multi-agent workflow using Claude Code's Dynamic Workflows (Opus 4.8+).

Task Overview

[Describe the high-level goal: e.g., "Audit the entire API surface of this Next.js app, validate all endpoints against the OpenAPI spec, run type-checks across all consumers, and generate a discrepancy report."]

Subagent Roles

Define the following specialized subagents — Claude Code will spawn and manage them in parallel:

1. [Subagent A name]: Responsible for [scope]. Input: [what data/files it receives]. Output: [what it produces].
2. [Subagent B name]: Responsible for [scope]. Input: [data/files]. Output: [result format].
3. [Subagent C name]: Responsible for [scope]. Input: [data/files]. Output: [result format]. [Add as many subagents as the task requires — Dynamic Workflows supports up to 1,000 concurrent.]

Orchestration Rules

• Fan-out phase: spawn all subagents simultaneously once [trigger condition, e.g., "the file index is built"].
• Dependency gate: [Subagent C] must not start until [Subagent A] completes and returns [specific artifact].
• Merge phase: aggregate all subagent outputs into [final output format: JSON report / markdown summary / PR comment].
• Failure handling: if any subagent fails, log the error and continue with remaining agents — do not abort the full run.
• Cost mode: use Cheaper Fast Mode for all subagents that perform [routine tasks: linting, formatting, stub detection]. Use standard Opus 4.8 for agents performing [complex reasoning: architecture review, security analysis].

Inputs Available to All Subagents

• Repository root: [path]
• Shared context file: [path to any shared spec, schema, or config]
• Environment: [list env vars that subagents may read]

Final Deliverable

Produce [a single consolidated output: e.g., "a REPORT.md in the repo root summarizing findings from all subagents, grouped by severity, with file paths and line numbers"].

Start by building the orchestration plan — list each subagent, its inputs and outputs, its dependencies, and the merge strategy — then begin execution.

**When to use this:** Any task where 3+ independent work streams can run in parallel. Particularly powerful for audits, migrations, and large feature builds where sequential execution is the main bottleneck.
**Cross-link**: → [Chapter 5: Claude Code Dynamic Workflows](https://vibecodingebook.com/reader#ch05) | → [endofcoding.com: Claude Opus 4.8 Parallel Subagents breakdown](https://endofcoding.com)

---

### 17.298 Full-Stack Feature Build with Claude Code Dynamic Workflows (Advanced)
**Tool**: Claude Code (Opus 4.8+) | **Time**: 3–6 hours

Use Claude Code's Dynamic Workflows to build the following full-stack feature end-to-end, using parallel subagents for each layer.

Feature

[Describe the feature clearly: e.g., "A user notification center — a bell icon in the nav that shows unread counts, a dropdown listing recent notifications with read/unread state, and a settings page to configure notification preferences per category."]

Stack

• Frontend: [Next.js 16 App Router / React 19 / Vue / SvelteKit]
• Styling: [Tailwind CSS 4 / CSS Modules / shadcn/ui]
• Backend: [Next.js Route Handlers / Express / FastAPI / Supabase Edge Functions]
• Database: [Supabase / PlanetScale / Postgres via Prisma / SQLite]
• Auth: [Supabase Auth / NextAuth / Clerk] — assume user is already authenticated

Parallel Subagent Plan

Spawn the following subagents simultaneously:

1. Schema subagent: Design and migrate the database schema for this feature. Tables: [describe what needs to be stored]. Write and run the migration. Output: confirmed schema + migration file path.
2. API subagent: Implement all backend endpoints / server actions for this feature. Follow RESTful conventions. Include input validation (zod), error handling, and rate limiting where appropriate. Output: route files + OpenAPI snippet.
3. UI subagent: Build all React components for this feature — use the design system already present in the codebase. Make components fully accessible (ARIA labels, keyboard navigation, focus management). Output: component files.
4. Test subagent: Write unit tests for all pure functions and integration tests for all API endpoints. Use [Vitest / Jest]. Achieve 90%+ coverage on new code. Output: test files.
5. Types subagent: Generate shared TypeScript types and Zod schemas derived from the database schema. Output: types/[feature].ts and schemas/[feature].ts.

Dependency Order

• Schema subagent must complete first; all others receive the confirmed schema before starting.
• Types subagent can start in parallel with API and UI once schema is confirmed.
• Test subagent starts after API and UI subagents produce their output files.

Definition of Done

• All new routes return correct responses for happy path and error cases
• UI is pixel-perfect against the existing design system
• TypeScript strict mode passes with zero errors
• All tests pass
• Feature works end-to-end in local dev: [describe the minimal user flow to verify]

Begin with the orchestration plan, then execute all subagents. Report blockers immediately rather than making silent assumptions.

**When to use this:** Full-stack features where schema, API, UI, types, and tests are independent enough to parallelize. Eliminates the "sequential layer cake" anti-pattern that makes feature development slow.
**Cross-link**: → [Prompt 17.297: Multi-Agent Orchestration](#17297) | → [vibe-coding.academy: Multi-Agent Workflows Quick Tip](https://vibe-coding.academy)

---

### 17.299 Parallel Security Scan with Claude Code Subagents (Expert)
**Tool**: Claude Code (Opus 4.8+) | **Time**: 1–3 hours

Run a comprehensive security audit of this codebase using Claude Code Dynamic Workflows. Spawn one specialized subagent per security domain — all running in parallel — then merge findings into a single prioritized report.

Repository Context

• Language / framework: [e.g., Next.js + TypeScript + Supabase]
• Auth mechanism: [JWT / session cookies / Supabase Auth / OAuth]
• External services in use: [Stripe, Resend, S3, etc.]
• Deployment target: [Vercel / AWS / GCP / self-hosted Docker]
• Compliance requirements (if any): [SOC 2 / GDPR / HIPAA / none]

Subagent Roster — Spawn All in Parallel

1. OWASP Top 10 subagent: Scan for the 10 most critical web application vulnerabilities. Check each category explicitly: Broken Access Control, Cryptographic Failures, Injection (SQL, command, LDAP), Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging Failures, SSRF. Output: findings per category with file path + line number.

2. Secrets and credentials subagent: Scan all source files (including config, env examples, and CI definitions) for hardcoded secrets, API keys, tokens, passwords, and private key material. Flag any secret committed in git history using git log -p. Output: list of findings with commit SHA where applicable.

3. Dependency vulnerability subagent: Run npm audit --json (or pip-audit / cargo audit / go mod verify as appropriate). Cross-reference critical CVEs against the CISA KEV catalog. Identify transitive dependencies with known exploits. Output: vulnerability list sorted by CVSS score descending.

4. Authentication and authorization subagent: Review all protected routes and API endpoints. Verify that every route enforces authentication before serving data. Check for insecure direct object references (IDOR) — can User A access User B's data by changing an ID in the URL or request body? Verify JWTs are validated server-side on every request. Output: list of endpoints with auth verdict (pass / fail / needs review).

5. Input validation subagent: Identify all user-controlled inputs (form fields, URL params, query strings, headers, file uploads). Verify each input is validated and sanitized before use. Flag any input that reaches a database query, shell command, or file path without sanitization. Output: input surface map with validation verdict per input.

6. Security headers and CSP subagent: Check HTTP response headers on all routes. Verify presence and correct configuration of: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy. Check for overly permissive CORS configuration. Output: header matrix with pass/fail per route type.

Merge and Report Instructions

After all subagents complete, produce a single SECURITY-AUDIT.md file with:

• Executive summary: total findings by severity (Critical / High / Medium / Low / Info)
• Prioritized finding list: each entry includes severity, category, file, line, description, and a concrete remediation step
• Quick wins: findings fixable in under 30 minutes
• Findings requiring architectural change: flag separately with estimated effort
• Overall security posture score: 1–10 with rationale

Use Cheaper Fast Mode for subagents 2, 3, and 6. Use standard Opus 4.8 for subagents 1, 4, and 5 which require complex reasoning about business logic and authorization flows.

Begin immediately. Do not wait for user confirmation between subagents.

**When to use this:** Pre-launch security reviews, after major dependency updates, or before compliance audits. The parallel scan cuts a full OWASP audit from hours to under 30 minutes.
**Cross-link**: → [CyberOS](https://cyberos.dev) for automated continuous scanning | → [Prompt 17.298: Full-Stack Feature Build](#17298) | → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10)

---

### 17.300 Glasswing-Style Systematic Vulnerability Discovery with Claude Code (Expert)
**Tool**: Claude Code (Opus 4.8+) | **Time**: 2–4 hours

Conduct a systematic, hypothesis-driven vulnerability discovery audit of this codebase, modeled on Anthropic's Project Glasswing methodology. Use Claude Code as an autonomous security researcher — generate hypotheses, validate them with targeted code analysis, and produce remediation code for confirmed findings.

Target Scope

• Repository: [path or description]
• Language / framework: [e.g., Next.js 16 + TypeScript + Supabase + Stripe]
• Auth mechanism: [JWT / Supabase Auth / NextAuth / session cookies]
• External services: [Stripe, Resend, AWS S3, etc.]
• Previous security reviews: [none / last SAST run: date / last pentest: date]
• Risk profile: [handles PII / financial data / health data / none of the above]

Methodology — Four-Phase Discovery Loop

Phase 1: Attack Surface Mapping

Enumerate all externally reachable surfaces:

• List all API routes / server actions / form POST targets
• Identify all places where user-controlled input enters the system (URL params, query strings, headers, form fields, file uploads, JSON body)
• Map all places where user identity is checked (or should be but isn't)
• List all external service calls (payment, email, storage, AI APIs) Output: complete attack surface map as a Markdown table with columns: Surface | Input Type | Auth Required? | Validated?

Phase 2: Hypothesis Generation

For each surface, generate vulnerability hypotheses using these pattern categories:

1. Broken Access Control (IDOR): Can User A access User B's data by changing an ID?
2. Injection: Does any user input reach a SQL query, shell command, file path, or template renderer without sanitization?
3. Authentication bypass: Are there routes that should require auth but don't?
4. Business logic flaws: Can a user trigger an action out of intended sequence (e.g., skip payment, double-redeem a coupon)?
5. Sensitive data exposure: Are secrets, PII, or internal error details returned in API responses?
6. Rate limiting absent: Which mutation endpoints have no rate limiting (brute force target)?
7. Mass assignment: Can a user set fields they shouldn't (e.g., role: "admin") via JSON body?
8. Prototype pollution: Are any Object.assign, spread operations, or dynamic property writes user-influenced?

For each hypothesis: state the attack vector, the affected code path (file + line), and the expected exploitability (High / Medium / Low).

Phase 3: Validation — Proof of Concept

For each High or Medium hypothesis:

1. Write a minimal proof-of-concept that demonstrates the vulnerability (a crafted request, a code path trace, or a unit test that exposes the flaw)
2. Determine blast radius: what data or functionality is exposed if exploited?
3. Assign severity: Critical (auth bypass / RCE / data exfil), High (IDOR / SQLi / stored XSS), Medium (CSRF / reflected XSS / info disclosure), Low (missing headers / verbose errors)

Phase 4: Remediation

For each confirmed finding:

1. Write the fix — corrected code with comments explaining what was wrong
2. Write a regression test that would have caught this vulnerability
3. Identify the root cause category (missing validation / missing auth check / unsafe library usage / etc.)
4. Check if the same root cause pattern appears elsewhere in the codebase

Deliverables

1. SECURITY-AUDIT-[date].md — complete findings report:
   • Executive summary (finding counts by severity)
   • Attack surface map
   • Finding list: Severity | Category | File:Line | Description | Proof-of-Concept | Blast Radius | Fix Applied
   • Root cause analysis: which patterns are systemic vs. one-off
   • Security posture score: 1–10 with rationale
2. Fix PRs: apply all Critical and High fixes directly; list Medium/Low as issues
3. Regression test file: security.test.ts covering all confirmed vulnerabilities

Execution Notes

• Run Phase 1 and Phase 2 in parallel subagents (use Dynamic Workflows if available)
• Prioritize Critical and High hypotheses — do not get blocked on Low findings
• If you find a Critical vulnerability, surface it immediately before continuing
• Use grep -rn extensively to find all instances of a vulnerable pattern before fixing

**When to use this:** Pre-launch security review, post-major-dependency-update, or before compliance audits. The four-phase hypothesis-driven approach replicates the methodology Anthropic used in Project Glasswing — systematic enough to find what manual review misses, structured enough to produce actionable remediation output.
**Expected output:** SECURITY-AUDIT.md with severities, blast radii, applied fixes, and regression tests.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) | → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) | → [CyberOS](https://cyberos.dev) for automated continuous scanning | → [Prompt 17.299: Parallel Security Scan with Dynamic Workflows](#17299)

---

### 17.301 AI Vendor Financial Health Evaluation Framework (Strategic)
**Tool**: Claude Opus 4.8 (or any frontier model) | **Time**: 1–2 hours

Help me evaluate the financial health, model trajectory, and strategic risk of the AI coding tools my team is planning to standardize on. Given the pace of consolidation (Anthropic $965B Series H, Cognition $28B, Cursor $50B+), I need a structured framework to make a durable vendor decision — not just pick whoever has the best benchmark today.

Context

• Current tools in use: [Claude Code / Copilot / Cursor / Windsurf / Devin / other]
• Team size: [individual / 2–10 / 10–50 / 50+]
• Stack lock-in risk: [high — deep Claude Code skill files / medium — some customization / low — commodity usage]
• Compliance requirements: [SOC 2 / GDPR / HIPAA / none]
• Budget sensitivity: [price is a key constraint / price is secondary]

Evaluation Framework — Score Each Vendor 1–5 Per Dimension

Dimension 1: Financial Stability (runway & revenue)

• Annualized revenue (ARR) confirmed or estimated
• Funding runway (raise size / monthly burn estimate)
• Investor quality (tier-1 VC + strategic = 5; seed-only = 1)
• Revenue growth trajectory (doubling quarterly = 5; flat = 1)
• Risk: Is this vendor a likely acquisition target? (acquisition risk = continuity risk)

Dimension 2: Model Trajectory (capabilities & velocity)

• Current SWE-bench score vs. category leaders
• Rate of model improvement over past 6 months
• Research organization strength (are they training their own models or API-wrapping?)
• Safety/alignment investment (important for enterprise compliance)
• Open-source alternative risk (can a free model replace this in 12 months?)

Dimension 3: Ecosystem Lock-In (switching cost)

• Proprietary format depth (CLAUDE.md / .cursor / custom skill files)
• Workflow integrations (CI/CD, Jira, Slack, Supabase)
• Team muscle memory and skill investment
• Data residency and export (can you retrieve all your history/memory?)
• Switching cost estimate in engineer-hours if vendor pivots or raises prices

Dimension 4: Roadmap Alignment

• Published roadmap vs. your 12-month needs
• Agent capabilities (autonomous PR merge, long-running tasks, parallel execution)
• Enterprise features (audit logs, SSO, admin controls, compliance certifications)
• MCP / interoperability investment (are they building walls or bridges?)
• Pricing trajectory signal (usage-based billing = cost unpredictability risk)

Dimension 5: Strategic Positioning

• Market share direction (gaining or losing)
• Enterprise customer quality (Fortune 500 logos = strong signal)
• Partnership ecosystem (IDE integrations, cloud provider deals)
• Security posture (has the vendor had a breach? how did they respond?)
• Open-weight alternative exposure (how much of their value can a self-hosted model replace?)

Deliverables

1. Vendor scorecard: matrix of each tool × each dimension with 1–5 scores and one-line rationale
2. Weighted total (weight dimensions by your team's priorities)
3. Risk scenario analysis: what happens if each vendor is acquired, raises prices 3×, or has a major security incident?
4. Recommendation: primary tool, secondary fallback, and the trigger condition that would cause you to switch
5. Review cadence: which signals to monitor quarterly (ARR, benchmark scores, pricing changes, acquisition rumors)

**When to use this:** When standardizing an engineering team's AI toolchain, evaluating budget allocation across competing subscriptions, or making a long-term architecture decision about which AI coding platform to build expertise around.
**Expected output:** Vendor scorecard with weighted scores, risk scenarios, and a primary/fallback recommendation with stated trigger conditions for switching.

**Cross-link**: → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) | → [Chapter 18: Tool Comparison Matrix](https://vibecodingebook.com/reader#ch18) | → [Prompt 17.296: Multi-Model Cost Routing](#17296) | → [endofcoding.com: Anthropic $965B Series H analysis](https://endofcoding.com)

---

### 17.302 AI Code Provenance Audit — Track, Attribute, and Document AI-Generated Code (Compliance)
**Tool**: Claude Code | **Time**: 1–3 hours

Help me audit our codebase for AI code provenance — identifying which files and functions were AI-generated, establishing attribution metadata, and creating a policy to satisfy emerging compliance requirements around AI-assisted development.

Context

• Repository: [path or description]
• Team: [size, AI tools in active use — Claude Code, Copilot, Cursor, etc.]
• Compliance context: [SOC 2 / GDPR / EU AI Act / enterprise customer contracts / internal governance only]
• Current AI code percentage: [estimate or "unknown"]
• Git history available: [yes — all commits / partial — last N months / no]

Background

Stack Overflow 2026 found that 38% of codebases are now majority AI-generated, yet 54% of developers report they "can't tell which parts of the codebase AI wrote." The EU AI Act (August 2 compliance deadline) requires transparency about AI involvement in high-risk systems. Enterprise customers are beginning to require AI code provenance documentation in vendor contracts. This audit establishes your baseline.

Audit Phases

Phase 1: Signal-Based Detection (no git history required)

Use the following heuristics to identify likely AI-generated code:

1. Comment density outliers: AI tends to generate highly commented code; flag files with >3x the repo-average comment-to-code ratio
2. Pattern uniformity: AI code in a single session tends to use identical naming conventions, spacing, and structure — flag files with unusually consistent style vs. the codebase norm
3. Docstring completeness: AI-generated functions typically have complete docstrings; flag files where 90%+ of functions have full parameter/return type documentation (unusual for human-written legacy code)
4. Boilerplate concentration: Flag large blocks of repeated structure (CRUD endpoints, test cases) with consistent templating — likely AI-generated at once
5. Import ordering: AI models consistently produce alphabetically sorted imports; flag files with perfect import order

For each flagged file, assign a confidence score: High / Medium / Low AI-generation likelihood.

Phase 2: Git History Attribution (if available)

For each commit in the last [N] months:

1. Identify commits made in "AI session" patterns — large diffs committed in short time windows (>500 lines in <5 minutes = likely AI-generated)
2. Search commit messages for AI attribution markers ("Co-Authored-By: Claude", "Generated with Claude Code", "AI-assisted")
3. Identify authors who show sudden velocity spikes — a developer committing 10x their historical rate likely has AI assistance
4. Flag commits with high-similarity blocks to each other (likely from the same AI session)

Output: contributor-attributed AI code percentage estimate with confidence bands.

Phase 3: Metadata Policy Implementation

Create a sustainable AI provenance tracking system going forward:

1. File-level metadata: For newly created files that are predominantly AI-generated, add a header comment: // AI-ASSISTED: Generated with [tool] on [date]. Human review: [reviewer]. Purpose: [one line].

2. Commit convention: Standardize commit message format for AI-assisted work: feat: [description] AI-assisted: [Claude Code / Copilot / Cursor] Reviewed-by: [human name] Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

3. CLAUDE.md / .cursorrules update: Add AI attribution policy to your project's AI config file so the tool auto-includes attribution markers in its output

4. PR template update: Add a checklist item: [ ] AI-generated code sections are marked with AI-ASSISTED comments or commit attribution

Phase 4: Compliance Report

Generate an AI-CODE-PROVENANCE-[date].md report containing:

• Total codebase size (LOC) vs. estimated AI-generated LOC
• Confidence distribution of the estimate (High/Medium/Low)
• Top 20 files by AI-generation likelihood with rationale
• Git attribution summary (AI-assisted commit % by month)
• Policy gaps: what is not currently tracked
• Policy implementation plan: 3 actions, 2 weeks
• Compliance mapping: how this report satisfies [EU AI Act / SOC 2 / contractual] requirements

Deliverables

1. AI-CODE-PROVENANCE-[date].md — full provenance report
2. Updated .github/pull_request_template.md — AI attribution checklist item added
3. Updated CLAUDE.md or equivalent — AI attribution instructions for the AI tool
4. Optional: GitHub Actions workflow that flags PRs missing AI attribution markers when AI tools are detected in git config

**When to use this:** Before an enterprise sales compliance review, when preparing for EU AI Act compliance, when a customer contract requires AI code disclosure, or when building an internal AI governance policy. The 54% of developers who "can't tell what AI wrote" (Stack Overflow 2026) creates legal and quality risk — this audit closes that gap.
**Expected output:** AI-CODE-PROVENANCE.md report, updated PR template, updated AI config file with attribution instructions.

**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) | → [Chapter 19: The Security Playbook](https://vibecodingebook.com/reader#ch19) | → [vibe-coding.academy: AI Governance Quick Course](https://vibe-coding.academy) | → [Prompt 17.285: Copilot June 1 Billing Audit](#17285)

---

---

### 17.303 Agent Eval Loop Builder (Advanced)
**Tool**: Claude Code | **Time**: 45–90 min | **Difficulty**: Advanced | **Category**: Agent Engineering

Build a repeatable evaluation harness for AI agent tasks — capture inputs, expected outputs, and actual outputs, then score agent performance systematically over time.

I need to evaluate my AI agent: [describe the agent — what it does, what tool calls it makes, what outputs it produces].

Evaluation Goals

• Task types to evaluate: [list 3–5 representative task types]
• Success criteria per task type: [quantitative or qualitative definition of "success"]
• Failure modes I'm most concerned about: [e.g., hallucinated tool calls, partial completion, incorrect file edits, skipping steps]

What I Want You to Build

Step 1: Dataset

Create evals/dataset.json with 15 test cases:

• 5 "easy" tasks (single-step, clear expected output)
• 5 "medium" tasks (multi-step, output requires judgment)
• 5 "hard" tasks (ambiguous requirements, edge cases, potential failure modes)

Format each case: { "id": "task-001", "difficulty": "easy|medium|hard", "input": { ... }, "expected_output": "...", "success_criteria": "...", "known_failure_modes": ["..."] }

Step 2: Eval Runner

Create evals/run_eval.py (or TypeScript equivalent) that:

• Loads the dataset
• Runs the agent against each test case
• Captures: actual output, tool calls made, latency, token cost
• Scores each case: PASS / PARTIAL / FAIL with a reason
• Writes results to evals/results/YYYY-MM-DD_HH-MM.json

Step 3: Scoring Function

For my task type, success looks like: [describe your criteria]. Implement a score(expected, actual) function that returns:

• 1.0 = full pass
• 0.5 = partial (right direction, wrong details)
• 0.0 = fail

Step 4: Baseline Report

After the first eval run, generate evals/BASELINE.md containing:

• Pass rate by difficulty tier
• Most common failure modes (ranked by frequency)
• Median latency and cost per task
• Recommended improvements (top 3, with expected impact)

Step 5: Regression Gate

Create a GitHub Actions workflow (.github/workflows/eval.yml) that:

• Runs the eval suite on every PR that touches agent prompts or tool definitions
• Fails the PR if pass rate drops below [N]% vs. the baseline
• Posts a comment with the diff in pass rates

**When to use this:** Before shipping any agent change to production. The eval loop is how you prevent regressions — it transforms "I think this prompt is better" into "this prompt passes X more test cases at Y% lower latency." Without it, prompt engineering is guesswork.
**Expected output:** `evals/dataset.json`, `evals/run_eval.py`, `evals/BASELINE.md`, `.github/workflows/eval.yml`.
**Cross-link**: → [Chapter 15: Testing AI Agents](https://vibecodingebook.com/reader#ch15) | → [Prompt 17.296: Multi-Model Cost Routing](#17296) | → [vibe-coding.academy: Agent Testing Fundamentals](https://vibe-coding.academy)

---

### 17.304 Vibe-Coded App Privacy Audit (Beginner)
**Tool**: Claude Code, Cursor | **Time**: 20–30 min | **Difficulty**: Beginner | **Category**: Security & Privacy

A beginner-friendly checklist audit for developers who built an app primarily with AI tools and want to check for the most common privacy and data exposure issues before shipping to real users.

I built this app primarily using AI coding tools: [describe the app — what it does, who uses it, what data it handles].

Tech stack: [Next.js / React / Supabase / Firebase / etc.] Deployment: [Vercel / Netlify / Railway / etc.] Data handled: [user emails, names, payment info, health data, business data, etc.]

Please run a beginner privacy audit. I'm not a security expert — explain everything clearly.

Audit Checklist

1. Find exposed secrets (CRITICAL — check this first)

Search my codebase for:

• Any string starting with: sk_live_, pk_live_, AKIA, ghp_, xoxb-, Bearer
• Any .env values that appear in files prefixed with NEXT_PUBLIC_ (these are visible in browsers)
• Any database connection strings in client-side files

For each finding: show me the file + line, explain why it's dangerous, and show me exactly how to fix it.

2. Check authentication on API routes

List every file in app/api/ or pages/api/ that does NOT call getServerSession(), auth(), verifyToken(), or similar. For each: explain whether it needs auth and how to add it in 5 lines or less.

3. Check Supabase / Firebase rules

If using Supabase: run this query and show me any dangerous results: SELECT tablename, policyname, qual FROM pg_policies WHERE qual = 'true';

If using Firebase: check firestore.rules or database.rules.json for any rule that uses allow read, write: if true;

For each finding: explain in plain English what data anyone can access, and show the fixed rule.

4. Check for personal data leaks

Search for any API routes or server functions that:

• Return an entire database table (SELECT * without WHERE clause limiting to current user)
• Include password, password_hash, or secret fields in responses
• Log user emails, passwords, or tokens to console.log()

5. Quick HTTPS + headers check

Confirm my app is configured to:

• Redirect HTTP to HTTPS
• Set X-Frame-Options and Content-Security-Policy headers

Show me how to add these to my next.config.ts or vercel.json if they're missing.

Output Format

For each issue found:

1. 🚨 SEVERITY (Critical / High / Medium)
2. What the problem is (one sentence)
3. Why it matters (one sentence — who could exploit it and how)
4. Exact fix (copy-paste code)

If everything looks safe, tell me that clearly too — I want to trust your conclusion.

**When to use this:** Before sharing any app with real users, customers, or colleagues. Even if you built it "just for yourself," the moment you put it on a public URL, this checklist applies. Takes 20 minutes. The Red Access May 2026 report found 2,000+ vibe-coded apps with exactly the issues this prompt catches.
**Expected output:** Annotated list of findings with copy-paste fixes, or a clear "no issues found" for each category.
**Cross-link**: → [Chapter 10: The Dark Side](https://vibecodingebook.com/reader#ch10) | → [endofcoding.com: 2,000 Vibe-Coded Apps Exposing Corporate Data](https://endofcoding.com/articles/vibe-coded-apps-corporate-data-exposure-2026) | → [CyberOS: Automated Scanning](https://cyberos.dev)

---

### 17.305 Agentic Engineering Migration Spec (Expert)
**Tool**: Claude Code | **Time**: 60–90 min | **Difficulty**: Expert | **Category**: Architecture / Migration

Generate a precise, file-level migration specification for converting a vibe-coded codebase to agentic engineering standards: structured agent boundaries, explicit human review points, automated quality gates, and observable behavior.

I have a codebase built primarily with AI coding tools ("vibe coded") that I want to migrate to agentic engineering standards.

Current State

Repository: [path or GitHub URL] Stack: [languages, frameworks, databases] Size: [approximate LOC or number of files] Current pain points: [e.g., "unclear what AI wrote vs human", "no tests", "auth missing on some routes", "RLS not configured", "AI makes changes I can't explain"]

Target: Agentic Engineering Standards

Based on Karpathy's agentic engineering definition (May 2026), my target state is:

• Human role is architect and reviewer, not author
• All agent outputs pass through automated gates before merge
• Agent behavior is observable (logging, tracing, audit trail)
• Security layer is explicit (auth on every route, RLS on every table, no secrets in client bundles)
• Test coverage exists for business logic (not necessarily AI-generated code)
• CLAUDE.md / .cursorrules defines constraints and patterns for AI agents

What I Want

Phase 1: Current State Audit (do this first)

Read the entire codebase and produce a MIGRATION-AUDIT.md with:

Code Quality Assessment

• Files with no test coverage (ranked by business criticality)
• API routes with no authentication middleware
• Database queries without user-scoping (potential data leaks)
• Secrets or hardcoded values that need to move to environment variables
• Areas where intent is unclear (would require re-explaining to an AI agent)

Agent Boundary Assessment

• Which parts of the codebase are suitable for AI agent modification (low risk, well-tested)
• Which parts require human review before any AI change (auth, payments, data access)
• Which parts should be frozen from AI modification (core security invariants)

Phase 2: Migration Specification

Produce MIGRATION-SPEC.md with a prioritized, file-level plan:

For each file or module:

Group into:

• P0 (security): Fix before any new users
• P1 (quality gates): Add before next feature
• P2 (observability): Add this sprint
• P3 (architecture): Refactor when touching the area

Phase 3: CLAUDE.md / .cursorrules Template

Generate an updated CLAUDE.md that codifies the agentic engineering constraints for this specific codebase:

• Which patterns to always use (auth middleware template, RLS policy template)
• Which patterns to never use (SELECT *, direct env access in client code)
• Required commit message format with AI attribution
• Human review requirements by file area
• Test requirements before marking tasks done

Phase 4: First 3 Migrations

Pick the 3 highest-priority items from the spec and implement them now, with before/after diffs and an explanation of what changed and why.

**When to use this:** When you have a working vibe-coded app that needs to become a maintainable product. The migration spec approach avoids big-bang rewrites — it's a prioritized, incremental path from "it works" to "it's maintainable and secure." Works best on codebases under 50K LOC; for larger repos, scope Phase 1 to a specific module.
**Expected output:** `MIGRATION-AUDIT.md`, `MIGRATION-SPEC.md`, updated `CLAUDE.md`, implemented P0 fixes.
**Cross-link**: → [Prompt 17.294: Vibe-to-Agentic Engineering Migration Framework](#17294) | → [Chapter 6: The Agent Revolution](https://vibecodingebook.com/reader#ch06) | → [endofcoding.com: Agentic Engineering: Why Vibe Coding Is Dead](https://endofcoding.com/articles/agentic-engineering-replacing-vibe-coding)

---

---

### 17.306 GitHub Copilot AI Credits Budget Optimizer — Audit Your Usage Before June 1 (Configuration)
**Tool**: Claude Code | **Time**: 20–30 min | **Difficulty**: Beginner | **Category**: Tools / Configuration

Before GitHub's AI Credits billing goes live on June 1, 2026, run a complete audit of your current Copilot consumption, identify agents and workflows consuming credits invisibly, and configure per-model cost routing to stay within your included allowance.

GitHub Copilot switches to AI Credits billing on June 1, 2026. Before the billing cycle starts, help me understand my current usage and optimize my configuration to avoid bill shock.

My Setup

Plan: [Pro $10/mo | Pro+ $39/mo | Business $19/seat | Enterprise $39/seat] Team size: [number of developers] Primary use patterns: [chat, CLI, inline completions, GitHub Actions automations, cloud agents, Spark] Current spend concern: [specific workflows or agents I'm worried about]

Phase 1: Consumption Audit

Help me identify and categorize every Copilot consumption source in my current workflow.

Credit-consuming operations (billable after June 1): Chat sessions, CLI commands, GitHub Actions using Copilot tokens, cloud agent sessions, Copilot Spark, third-party agents.

Non-credit operations (unlimited): inline code completions, next-edit suggestions — confirm these are NOT metered.

Phase 2: GitHub Settings Audit

Walk me through the settings pages to check before June 1:

1. Usage preview: github.com/settings/copilot → Usage tab
2. Billing alerts: set 50%/80%/100% credit threshold alerts
3. Model preferences: configure default model per operation type
4. Org-level policies (Business/Enterprise): per-seat credit limits

Phase 3: Cost-Optimized Configuration

Based on my usage profile, recommend model routing:

• Daily chat / small questions: cheapest capable model
• Code review and PR summaries: balanced cost/quality model
• Long-horizon agent sessions: flag if I should limit or cap these
• GitHub Actions automations: cheapest viable model or convert to non-Copilot

Phase 4: CLAUDE.md Update

Generate a "Copilot Credits Policy" section for CLAUDE.md documenting which models to use for which tasks.

Phase 5: Monthly Budget Projection

Project my monthly credit consumption and flag overage risk vs my plan's included credits.

**When to use this:** Run this the week before June 1, 2026, or any time you receive a Copilot bill that surprises you. Also useful when onboarding new team members.
**Expected output:** Credit consumption audit, cost-optimized model routing config, updated CLAUDE.md Copilot section, monthly budget projection.
**Cross-link**: → [Prompt 17.286: GitHub Copilot June 1 Billing Migration Audit](#17286) | → [Chapter 5: The Tools Landscape](https://vibecodingebook.com/reader#ch05) | → [Chapter 9: The Numbers](https://vibecodingebook.com/reader#ch09)

---

### 17.307 Red Access Corporate Data Exposure Audit — Find and Fix the 5 Failure Patterns (Security)
**Tool**: Claude Code | **Time**: 30–45 min | **Difficulty**: Beginner | **Category**: Security

Based on the Red Access 2026 report finding 2,000+ vibe-coded production apps leaking corporate data, this prompt audits your app against the five failure patterns: Supabase RLS misconfigurations, Firebase open rules, hardcoded API keys in client bundles, exposed CI/CD secrets, and unprotected admin endpoints.

The Red Access 2026 report (May 31, 2026) found 2,137 live production vibe-coded apps actively leaking corporate credentials, source code, or PII. Audit my app against the 5 failure patterns.

My App

Stack: [Next.js/React/Vue + backend/BaaS] Database: [Supabase | Firebase | other] Auth: [Supabase Auth | Clerk | NextAuth | Firebase Auth | custom] Deployment: [Vercel | Railway | Fly | AWS | other]

Pattern 1: Supabase RLS (41% of affected apps)

Run this in Supabase SQL editor: SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;

For each table where rowsecurity = false: identify the data it holds, determine correct access scope (public/user-scoped/role-scoped), and generate the RLS policy for my auth setup. Also check: is service_role key used anywhere in client-side code?

Pattern 2: Firebase Security Rules (28%)

Show me current Firestore/Realtime Database rules. Flag: any allow read, write: if true; any collections readable unauthenticated. Generate corrected rules.

Pattern 3: API Keys in Client Bundle (19%)

Scan for secrets in client-side code: grep -r "NEXT_PUBLIC_|process.env" src/ --include=".tsx,.ts,*.js" | grep -i "key|secret|token|password"

Flag real-looking credentials. Also check git history for any committed .env files.

Pattern 4: CI/CD Secret Exposure (8%)

Check GitHub Actions for debug echo statements printing secrets, artifact uploads with env dumps, and any hardcoded values in env: blocks.

Pattern 5: Unprotected Admin Endpoints (4%)

Find routes with "admin|dashboard|internal|manage|panel" paths. For each: verify auth middleware is applied, role check (not just authentication), and path is not guessable.

Deliverable: SECURITY-AUDIT.md