Vibe Coding

The Complete Guide to AI-Native Software Development

22 chapters. 200+ prompts. Updated monthly. The only vibe coding resource that evolves as fast as the field.

01. The Moment Everything Changed

On February 2, 2025, Andrej Karpathy — former OpenAI co-founder, former Tesla AI director, and one of the most respected voices in machine learning — posted what would become one of the most consequential tweets in software development history:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works." — Andrej Karpathy, February 2, 2025

Within weeks, the term had gone viral. Within a month, Merriam-Webster added "vibe coding" as a slang and trending term. By December 2025, Collins English Dictionary named it their Word of the Year.

But vibe coding didn't just enter the dictionary. It entered the economy. It entered boardrooms. It entered the workflows of millions of developers. And it sparked one of the fiercest debates the software industry has seen in decades.

The Timeline

02. What Vibe Coding Actually Is

Strip away the hype, and vibe coding is a specific practice with specific characteristics.

Vibe coding is an AI-assisted software development approach where a developer describes what they want in natural language, an AI model generates the code, and the developer evaluates the result through execution rather than code review. The developer does not read, edit, or attempt to understand the generated code. They test whether it works, and if it doesn't, they feed the error back to the AI.

</div>

  **2.** Accept the generated code without reading it

  **3.** Run it

  **4.** Does it work? Ship it. Doesn't work? Move to Loop 2.

  This is the happy path. For simple features, you may never leave this loop.

</div>

  **2.** Accept the fix without reading it

  **3.** Run it again

  **4.** Repeat until resolved or move to Loop 3.

  Most errors resolve within 1-3 iterations of this loop. The AI sees the error, understands the context, and fixes it.

</div>

  **2.** Describe the desired outcome differently, with more context

  **3.** Return to Loop 1

  This is the escape hatch. If the AI gets stuck in a loop of broken fixes, go back to a clean state and try a different approach. This is why checkpoints matter — always have a rollback point.

</div>

03. The Philosophy: Trusting the Machine

Vibe coding isn't just a technique. It's a philosophical stance about the relationship between developers and code.

The End of Code as Sacred Text

For decades, programming culture has treated source code as something to be crafted, reviewed, optimized, and understood. Code reviews are rituals. Clean code is a moral virtue. Understanding every line is a professional obligation.

Vibe coding rejects this entirely. It treats code as a disposable intermediary between human intent and running software. The code doesn't matter. The behavior matters.

This is not as radical as it sounds. Most software professionals already interact with layers of abstraction they don't fully understand:

• Few web developers read TCP packet internals

• Few application developers audit their compiler output

• Few React developers understand the fiber reconciliation algorithm

• Few SQL users trace query execution plans for every query

  Vibe coding simply adds another layer: the AI becomes the compiler for natural language.

  The Four Pillars

  🎯

  Intent Over Implementation

  "What should this do?" replaces "How should I build this?"

  ⚡

  Speed Over Elegance

  Working software now beats perfect code later

  🤖

  Trust the AI

  Accept all, don't read diffs, let the machine handle it

  📈

  Results-Oriented

  Does it work? That's the only metric that matters

  The Abstraction Argument

  Supporters frame vibe coding as the natural progression of programming abstraction:

  1950s

  Machine Code → Assembly

  "You don't need to write binary opcodes anymore!"

  1970s

  Assembly → C

  "You don't need to manage registers anymore!"

  1990s

  C → Python / Java

  "You don't need to manage memory anymore!"

  2010s

  Frameworks / Cloud

  "You don't need to manage servers anymore!"

  2025

  Natural Language → Code

  "You don't need to write code anymore!"

  At each transition, purists warned that developers were losing essential skills. At each transition, the expanded abstraction enabled more people to build more things.

  ⚠️

  **The counter-argument is real, though:** Every previous abstraction still had deterministic behavior. Assembly always compiles the same way. C always allocates memory the same way. AI code generation is probabilistic — the same prompt can produce different code each time, with different bugs. This is a genuinely new kind of abstraction layer.

04. The Spectrum: Five Levels of AI-Assisted Development

Vibe coding is not binary. In practice, developers operate along a spectrum. Understanding where you sit — and where you should sit for a given project — is critical.

  **When to use:** Security-critical code, regulatory requirements, environments where AI tools are prohibited.

</div>

  **Tools:** GitHub Copilot, VS Code AI extensions

  **Code understanding:** 100% — you review everything

  **When to use:** Production code, team projects, anything you need to maintain

</div>

  **Tools:** Cursor Composer, Claude Code, Codex CLI

  **Code understanding:** 70-90% — you review most things

  **When to use:** Professional development, startup codebases, any code that needs to scale

</div>

  **Tools:** Cursor Agent, Claude Code, Bolt.new

  **Code understanding:** 30-60% — architecture yes, implementation details no

  **When to use:** MVPs, internal tools, prototypes headed toward production

</div>

  **Tools:** Bolt.new, Lovable, Replit Agent, v0

  **Code understanding:** 0-10% — you only test behavior

  **When to use:** Personal projects, throwaway prototypes, hackathons, idea validation

</div>

  **Tools:** Devin, Google Jules, OpenAI Codex (cloud mode)

  **Code understanding:** Review-based — you check the output, not the process

  **When to use:** Routine tasks, migrations, test generation, documentation, with human review gate

</div>

</div>

Take the interactive quiz at the end of this ebook to find out.

<button class="quiz-btn quiz-btn-primary" style="margin-top:0.5rem;" onclick="goTo('ch-quiz')">Take the Quiz &#8594;</button>

05. The Tools: A Complete Landscape (2025–2026)

The tooling ecosystem for AI-assisted development has exploded. The market is consolidating fast — with Cursor seeking a ~$50B valuation at $2B+ ARR, Lovable at $6.6B, Cognition at $10.2B, and billion-dollar acquisition battles playing out in real time. Anthropic's acquisition of Bun (the fast JavaScript runtime) signals Claude Code's push into native runtime integration. Here's the current state of play across every major category.

AI-Native IDEs

Autonomous Coding Agents

Browser-Based Builders

The Infrastructure Layer: MCP

</div>

06. The Agent Revolution

The most significant development since Karpathy's tweet isn't better autocomplete. It's the emergence of autonomous coding agents — AI systems that independently plan, implement, test, and deploy software.

From Copilot to Colleague

What Agents Can Do Today

Modern coding agents reliably handle tasks that would take a junior developer 4-8 hours:

The April 2026 Benchmark Picture

Agent performance has accelerated dramatically. The current public leaderboard (April 2026):

Kimi K2.5 by Moonshot AI is the current #1 open-source option: 1 trillion parameter MoE architecture with 32 billion active parameters, competitive with frontier models at a fraction of the inference cost.

New Agent Orchestration Frameworks (April 2026)

Two major frameworks launched in April 2026 that reshape how multi-agent systems are built:

• Google Agent Development Kit (ADK): google/adk-python — 8,200+ stars on launch week. Purpose-built for multi-agent orchestration with native Gemini integration and MCP support. Best for complex agent pipelines with multiple specialized sub-agents.
• Meta llama-stack: Standardized agent runtime for Llama 4 models. Defines interfaces for tool calling, memory, and agent orchestration that work across the open-source ecosystem.
• Claude Managed Agents: Anthropic's managed runtime at $0.08/session-hour plus token costs. Provides sandboxed execution, state management, and permission scoping. Testing shows 10 percentage point improvement in task success rates over standard prompting.

The practical implication: you no longer need to build agent infrastructure from scratch. These frameworks handle the hard parts — state, retries, tool routing, parallelization — so you can focus on the task logic.

What Agents Still Struggle With

Cognition's own 2025 performance review of Devin put it well:

"Devin is senior-level at codebase understanding but junior at execution."

• Ambiguous requirements — agents make assumptions that may not match intent
• Complex architectural decisions — they can implement but struggle with system-level design
• Cross-system integration — tasks requiring deep understanding of multiple interconnected systems
• Security context — knowing when something is dangerous requires deployment context, not just code patterns

The Parallel Execution Advantage

Unlike human developers, agents can run multiple instances simultaneously, work 24/7, and process entire backlogs of tickets overnight.

Karpathy's Software 3.0 Framework (May 2026)

Andrej Karpathy — the researcher who coined "vibe coding" in February 2025 — returned in May 2026 with a more formal framework for what is actually happening in AI-native development. He calls it Software 3.0: a three-era model that explains why vibe coding and agentic engineering feel different even when they use the same tools.

The practical implication of this framework is the distinction Karpathy draws between vibe coding and agentic engineering:

Vibe coding is not a degraded form of agentic engineering — it is the right tool for a different job. As Karpathy put it: "Software 3.0 is already here. The question is not whether to use it, but which layer of the stack you're applying it to and whether your verification layer matches the stakes."

The SpaceX signal reinforces this. Reports in May 2026 that SpaceX evaluated a $60 billion acquisition of Cursor — which would make it the largest AI coding deal in history — suggest that infrastructure-grade companies are treating AI coding tooling as foundational platform technology, not a developer productivity toy. When that happens, the Software 3.0 thesis moves from academic framework to engineering mandate.

Cross-link: → Karpathy's Software 3.0 framework — endofcoding.com. → Chapter 16: What Comes Next for the long-horizon architecture implications. → vibe-coding.academy — Software 3.0 module.

07. Vibe Coding in Practice: Real Workflows

Theory is interesting. Practice is what matters. Here are four concrete workflows for different scenarios.

**Scenario:** You have a product idea and want a working prototype by Monday.

**Tools:** Bolt.new or Cursor + Claude • **Level:** 3-4

1. Write a detailed description (spend 20-30 min — it's the most important step)

  </div>

  <div class="tab-content" id="wf2">
    #### The Startup MVP

    **Scenario:** Building a real product for real users, fast.

    **Tools:** Claude Code + Cursor + v0 &bull; **Level:** 2-3

    1. Start with a product requirements document (even a rough one)
2. Use v0 to prototype key UI screens
3. Use Claude Code to scaffold the full architecture
4. Build feature-by-feature, testing each before moving on
5. Review auth code and data handling; accept UI code freely
6. Deploy to real hosting, set up monitoring
7. Plan a "hardening phase" for security-critical paths

    <div class="callout warning">
      <div class="callout-icon">&#9888;&#65039;</div>
      <div class="callout-content">**The trap:** Skipping step 7. Many YC startups vibe-coded their MVPs successfully but faced "development hell" when trying to scale without hardening.

</div>
    </div>
  </div>

  <div class="tab-content" id="wf3">
    #### The Enterprise Integration

    **Scenario:** Adding a feature to an existing production codebase.

    **Tools:** Claude Code or Devin + CI/CD pipeline &bull; **Level:** 5 with human gate

    1. Create a detailed ticket with acceptance criteria
2. Assign to an AI agent (Devin, Claude Code, or Jules)
3. Agent analyzes codebase, creates a plan, implements the change
4. Agent runs existing test suite and fixes failures
5. Agent opens a pull request
6. Human reviews: security, performance, architecture, edge cases
7. Merge after human approval

    This is Level 5 but with human review as the final gate. It's how most enterprises adopt AI coding in 2026.

  </div>

  <div class="tab-content" id="wf4">
    #### The Solo Creator

    **Scenario:** You're not a developer. You have an idea for an app.

    **Tools:** Lovable, Bolt.new, or Replit Agent &bull; **Level:** 4

    1. Describe your application as if explaining it to a friend
2. Let the builder create the first version
3. Use it yourself — note what's wrong or missing
4. Describe changes in plain language
5. Repeat until satisfied
6. Deploy using the platform's built-in hosting

    <div class="callout danger">
      <div class="callout-icon">&#128308;</div>
      <div class="callout-content">**Critical:** If your app handles user data, sensitive information, or payments, hire a security professional to review it before going live. The Lovable vulnerability study (170/1,645 apps) shows this isn't hypothetical.

</div>
    </div>
  </div>

08. Real-World Case Studies

These are documented, real examples — not hypotheticals.

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

09. The Numbers: Adoption and Impact

The data tells a clear story: AI-assisted development isn't a trend. It's a structural shift.

Adoption

AI Tool Daily Active Use Share — Stack Overflow 2026 (May 19, 2026)

First time Claude Code ranks #1 in daily active use across the developer population (Stack Overflow's 90,000+ respondent survey).

JetBrains Developer Ecosystem Survey 2026 (May 23, 2026)

Independent second read on AI coding tool adoption from JetBrains' annual survey. The Stack Overflow result above tracks daily active use across the broader developer population; the JetBrains numbers below track AI-coding-tool category share and reveal a sharper preference signal among experienced developers.

The senior-dev signal: among developers with 10+ years of professional experience, Claude Code's preference share (46%) is more than 5× Copilot's (9%). The combined Stack Overflow + JetBrains read for May 2026: Claude Code is now the #1 AI coding tool by both daily-active use and senior-developer preference — Copilot still leads on raw category share but has lost roughly a third of its installed base year-over-year.

AI Market Share (May 2026 — Historic Flip)

Historic milestone (April 2026): For the first time, Anthropic's Claude surpassed OpenAI's ChatGPT in US business adoption. Source: Ramp AI Business Adoption Index (tracks actual B2B payments, not surveys).

The Agentic Model Race (April–May 2026)

Seven major model releases in seven weeks reshaped the competitive landscape. The race is no longer about raw benchmark scores — it's about how many agents a model can orchestrate, how long it can sustain autonomous work, and how much that work costs per token.

The signal: In seven weeks, the public record for coding agent benchmarks shifted from Claude Opus 4.6 (80.8%) to Gemini 3.5 Pro (89.1%, Google I/O May 19) — with Mythos's restricted 93.9% remaining the unreleased ceiling. Multi-agent swarm scaling — exemplified by Kimi K2.6's 300-agent architecture and Qwen3.7-Max's 1,158-tool-call autonomous run — is the new frontier. Cost-per-token competition is the second front: Cursor Composer 2.5 ($0.50/$2.50), Gemini 3.5 Flash ($1.50/$9.00), and Qwen3.7-Max ($2.50/$7.50) all hit benchmark parity with prior frontier models at fractions of Opus 4.7's per-token bill. For agentic workloads sustained over hours, the inference economics increasingly favor tool-vendor in-house models or hyperscaler cost leaders over headline frontier LLMs.

Revenue & Growth

Valuations (2026)

Enterprise AI Momentum (May 2026)

The enterprise AI services market is consolidating fast. Anthropic partnered with Blackstone, Hellman & Friedman, and Goldman Sachs to launch a dedicated enterprise AI services company — targeting mid-sized organizations that lack in-house frontier AI deployment capacity. Meanwhile Sierra ($950M) and Cognition ($25B valuation) signal that enterprise AI customer experience and AI software engineering are becoming independent category leaders.

May 2026 enterprise anchors:

• SAP + Anthropic (May 13, 2026): Claude will power SAP's Business AI Platform as primary reasoning and agentic layer — reaching 440M+ SAP users and enabling autonomous enterprise tasks (closing books, rerouting supplier orders) within existing governance frameworks.
• SpaceX + Anthropic (May 6, 2026): 300 megawatts of compute from SpaceX's Colossus 1 facility in Memphis (220,000+ Nvidia processors). Anthropic's largest capacity expansion to date, reducing API rate-limit constraints.

The signal: Total disclosed AI venture capital through Q1 2026 already exceeds all of 2025. The $900B Anthropic valuation marks a potential inflection — from venture-funded AI bets to pre-IPO institutional positioning. Harvard, Goldman Sachs, Blackstone, and Broadcom investing in Anthropic infrastructure within 30 days tells you where the enterprise market is headed. The April 2026 adoption flip is the market validating this thesis with payment data.

Productivity

Developer Sentiment (April 2026)

Cultural Impact

• Collins Dictionary Word of the Year 2026: "Vibe coding" (named again after 2025)
• MIT Technology Review: Named "Generative Coding" a 2026 Breakthrough Technology
• Merriam-Webster: Added as slang/trending term within one month of Karpathy's tweet
• Wikipedia: Full article with extensive sources and analysis
• Wall Street Journal: Reported widespread professional adoption (July 2025)
• Fast Company: Documented the "vibe coding hangover" (September 2025)
• arXiv: "Vibe Coding Kills Open Source" paper sparks open-source funding debate (January 2026)
• VibeX 2026: First academic workshop on vibe coding, scheduled at EASE conference in Glasgow
• Mainstream: Vibe coding is now a recognized methodology taught in bootcamps and referenced in enterprise strategy documents

10. The Dark Side: Security, Debt, and Failure

For every success story, there's a cautionary tale. The risks are real, documented, and in some cases severe.

The Tenzai Security Study

  **Key finding:** AI tools avoid generic security flaws but struggle where what makes code safe vs. dangerous depends on context.

</div>

</div>

</div>

11. The Great Debate

The software community is deeply divided. Understanding the strongest arguments on each side helps you form a nuanced view.

Programming languages have always moved toward higher abstraction. Assembly to C to Python. Each level lets developers focus on intent rather than implementation. Natural language is simply the next layer.

#### "It democratizes creation."

Millions of people have software ideas but lack years of training. Vibe coding lets a nurse build a patient tracking app, a teacher build a classroom tool, a small business owner build inventory management. The expansion of who can create software is historically significant.

#### "The speed advantage is transformative."

A prototype in hours instead of weeks. An MVP in days instead of months. The 25% of YC companies with 95% AI code didn't choose vibe coding for ideology — they chose it because they needed to move fast.

#### "Traditional code isn't as reliable as we pretend."

Human-written code has bugs, security vulnerabilities, and technical debt too. AI-generated code may have different failure modes, but the idea that human code is inherently reliable is a myth.

Software spending is ~60% maintenance. If nobody understands the codebase, maintenance is impossible. You're not saving time — you're borrowing it from the future at a ruinous interest rate.

#### "Security requires understanding, not just testing."

You can test whether a login form works. You can't easily test whether passwords are properly hashed, session tokens are cryptographically secure, or APIs have rate limiting — unless you read the code.

#### "It creates learned helplessness."

Developers who rely entirely on vibe coding lose fundamental skills. When the AI makes a mistake in a novel way, they have no fallback. Fragile teams build fragile systems.

#### "The economics don't work at scale."

Vibe coding is cheap upfront and expensive later. The $1.5 trillion tech debt projection isn't speculation — it's extrapolation from observed code churn, duplication, and architectural degradation.

The most reasonable position — and the one supported by data — is that vibe coding is a powerful tool with a specific and limited appropriate scope.

<div class="callout success">
  <div class="callout-icon">&#9989;</div>
  <div class="callout-content">
    **It excels for:** prototyping, validation, personal tools, learning, hackathons, and small-scale applications with limited security requirements.

  </div>
</div>
<div class="callout danger">
  <div class="callout-icon">&#10060;</div>
  <div class="callout-content">
    **It fails for:** production systems at scale, security-sensitive applications, regulated industries, and software that needs multi-year maintenance.

  </div>
</div>
**The winning model in 2026:** Vibe code the prototype, then bring in disciplined engineering for the production system. The companies dominating right now — the ones raising at $10B valuations, the ones with $1B ARR in six months — are all betting that this model scales. And the data supports them.

The critics are not wrong about the risks. But they are wrong about the trajectory. Every objection to vibe coding was once made about high-level languages, about frameworks, about cloud computing. The abstraction always wins. The question is never *whether* but *how*.

12. When to Vibe (and When Not To)

🟢 Green Light: Vibe Code Away

🟠 Yellow Light: Proceed with Caution

🔴 Red Light: Don't Vibe Code

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 "Explain Then Generate" Pattern
    </button>
    <div class="expand-body">
      For complex features, ask the AI to explain its approach before generating code:

      ```
Before writing any code, explain how you would implement
real-time collaborative editing in this application.
What approach? What trade-offs? Then implement it.

  This gives you architectural understanding even in a vibe coding workflow.

</div>

  - **Claude Opus 4.6 (via Claude Code)** — Complex reasoning, architecture, large codebases, agent teams for parallel work

**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).

14. Building a Sustainable Workflow

Pure vibe coding is fast but fragile. Here's how to build a workflow that's both fast and sustainable.

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

15. The Business of Vibes

Vibe coding isn't just changing how software is built. It's changing the economics of software businesses.

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>

The New Archetypes

The Talent Shift

Companies are increasingly hiring for:

• Specification specialists — translating business requirements into precise AI prompts

• System architects — designing overall structure that AI agents implement

• Security engineers — the human review layer catching what AI misses

• AI-fluent developers — working effectively with and reviewing AI-generated code

  Browse 670+ open AI/LLM positions at LLMHire — the dedicated job board for AI engineers, ML researchers, and prompt engineers.

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.

  Near-Term (Late 2026)

  • Security tooling catches up. Agentic security tools reviewing AI code in real-time. "Move security into the act of creation."

• Standardization emerges. Enterprise governance frameworks for AI-generated code.

• Agent orchestration matures. Specialized agents for frontend, backend, testing, security working in concert under a lead agent.

• Open-source funding models evolve. New models for compensating maintainers whose libraries power AI-generated code.

  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.

  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 twelve months, vibe coding went from a tweet to a dictionary entry to a multi-billion-dollar industry. Cursor alone is valued at $29.3 billion. Lovable at $6.6 billion. A vibe-coded startup sold for $80 million. GitHub Copilot has 4.7 million paid subscribers. Now, in early 2026, it has become the defining methodology of a new era in software development.

  The numbers speak for themselves: Claude Code reached $1B ARR in six months. Cursor surpassed $1B ARR at a $29.3B valuation. Devin surpassed $155M ARR at a $10.2B valuation. GitHub Copilot crossed 4.7 million paid users. These are not experimental products. This is the new infrastructure of software creation.

  The promise is real and accelerating: agent teams working in parallel, multimodal coding interfaces, 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 are evolving too: the open-source ecosystem faces an existential funding question, security remains a real concern with 69 vulnerabilities found across just 15 AI-built apps, and the "vibe coding hangover" of unmaintainable codebases is a documented phenomenon.

  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 collaborate with agents 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)

---

*Chapter 17 additions — May 26, 2026 | Prompts 17.288–17.290 (Cross-Session Agent Memory Setup, Self-Hosted Model Evaluation Framework, AI Security Hardening Audit) | 304+ prompts across 48 categories | Previous: May 24 (prompts 17.285–17.287 — Microsoft Conductor Multi-Agent Orchestration, GitHub Copilot June 1 Billing Migration Audit, Apple iOS 27 AI Feature Integration Blueprint). Prompted by: Anthropic Dreaming launch (cross-session agent memory consolidation), open-weight frontier parity (Kimi K2.6/DeepSeek V4/GLM-5.1), and AI security bug-pocalypse (Google Cloud 5-figure unauthorized API bills, 22-second breach-to-attack window).*

18. Tool Comparison Matrix

A living comparison of every major vibe coding tool. Updated monthly.

AI-Native IDEs

Autonomous Agents

Browser Builders (No-Code)

Open-Source & Cost-Efficient Alternatives

For teams optimizing cost, data privacy, or running on self-hosted infrastructure.

Choosing Your Stack

</div>

19. The Security Playbook

A practical guide to hardening vibe-coded applications before they touch real users.

</div>

</div>

</div>

</div>

</div>

</div>

</div>

Review this codebase for OWASP Top 10 vulnerabilities.
For each issue found: severity (Critical/High/Medium/Low),
file and line number, what's wrong, the fix, and how to test it.
Prioritize by severity.

</div>

Chapter 20: Video Tutorials -- Embedded Remotion-Generated Walkthroughs

Bite-sized, binge-worthy video tutorials that show real vibe coding workflows in action. Each video is 60-120 seconds, focused on one specific technique, and embedded directly in the interactive ebook using Remotion components. Updated monthly with 2-4 new videos.

Why Video Tutorials Inside an Ebook

Reading about vibe coding is one thing. Watching a real app materialize from a single prompt in under ninety seconds is something else entirely.

Traditional ebooks give you text and screenshots. This one gives you motion. Every video in this chapter is a self-contained Remotion composition -- a React component that renders to video. That means each tutorial is versioned, reproducible, and embedded natively in the interactive ebook without relying on external hosting. You can watch them inline, pause on any frame, and in the web version, interact with the code snippets directly.

The videos are grouped into three series, each designed for a different purpose:

1. Prompt to Product -- Viral-format demonstrations of complete apps built from single prompts. Optimized for shareability and shock value.
2. The Prompt That... -- Educational deep-dives with a comedic edge. Each video dissects one prompt and its unexpected consequences.
3. Tool Face-Off -- Head-to-head comparisons between competing tools, scored on speed, quality, and developer experience.

Every video follows the same production pipeline: markdown script, Remotion composition with screen recordings and motion graphics, AI-generated narration, and branded end cards. The result is a library that grows over time and works across platforms -- full-length on YouTube, clipped for TikTok/Reels/Shorts, and embedded here in the ebook.

Video Series 1: "Prompt to Product" (Viral Potential)

Each video in this series shows a complete, functional application being built from a single natural-language prompt. A real-time countdown timer runs in the corner. The screen recording is unedited -- what you see is what actually happened. The final reveal shows the deployed app running in a browser.

Series format:

• Duration: 60-90 seconds
• Structure: Hook (3s) -> Prompt reveal (5s) -> Countdown build (40-70s) -> Reveal + deploy (10s) -> End card (5s)
• Visual signature: Neon countdown timer in the top-right corner, split-screen showing prompt on the left and the AI's output on the right
• Audio: Fast-paced electronic background track, AI text-to-speech narration, keystroke and notification sound effects

Video #1: 60-Second SaaS (Bolt.new)

Title/Hook: "I built a $9/month SaaS in 60 seconds"

Tool: Bolt.new

Concept: Starting from a completely blank Bolt.new session, a single prompt generates a fully functional micro-SaaS -- a link shortener with analytics, user accounts, and a Stripe-ready pricing page. The countdown timer hits zero just as the app deploys.

Tone: Breathless, slightly disbelieving. The narration captures the genuine absurdity of how fast this is.

Script Outline (170 words): Open on a blank browser tab. The narrator says: "I'm going to build a SaaS product that charges $9 a month. I have 60 seconds." The countdown starts. Cut to the Bolt.new interface. The prompt appears on screen as it is typed: a link shortener with user authentication, click analytics dashboard, custom short domains, and a pricing page with free and pro tiers. Bolt.new starts generating. The split screen shows the prompt on the left, the live preview assembling on the right -- components appearing in real time, a login form, a dashboard with charts, a pricing table with toggle between monthly and annual. The timer passes 30 seconds. The app is taking shape. At 50 seconds, the deployment starts. At 58 seconds, a live URL appears. The timer hits zero. Cut to the deployed app in a fresh browser: working signup, working dashboard, working pricing page. End card: "Total cost: $0. Total code written by a human: 0 lines."

Visual Concepts for Remotion:

• CountdownTimer component: neon green digits, pulses red below 10 seconds, shakes at 3-2-1
• SplitScreenBuild composition: left panel shows the prompt text animating in typewriter-style, right panel shows a screen recording of Bolt.new's live preview
• DeploymentFlash animation: when the URL goes live, a burst animation radiates from the URL bar
• MetricCard end-card overlay: three floating cards showing "Time: 60s", "Lines of code: 0", "Cost: $0" with staggered fade-in
• Screen recording captured at 60fps, composited at 30fps for smooth playback

Video #2: Portfolio Speedrun (v0 + Vercel)

Title/Hook: "Your portfolio shouldn't take longer than your morning coffee"

Tools: v0 by Vercel, Vercel deployment

Concept: A developer's portfolio website -- hero section, project grid, about page, contact form, dark mode toggle -- goes from blank prompt to live Vercel deployment while a coffee timer ticks down. The coffee metaphor runs throughout: the video opens with pouring coffee, and each section of the site appears as the coffee cools.

Tone: Relaxed and conversational, contrasting with the speed of what is happening on screen. The humor comes from the mismatch between the casual narration and the absurd pace.

Script Outline (180 words): Open on a close-up of coffee being poured. The narrator says: "The average developer spends 3 weeks on their portfolio. I'm going to finish mine before this coffee is cool enough to drink." Cut to v0. The prompt describes a developer portfolio: dark theme, animated hero with a typewriter effect showing "I build things," a responsive project grid pulling from a JSON file, an about section with a timeline, a contact form, and a dark/light mode toggle. v0 generates the first component. The narrator walks through what is appearing while keeping the tone casual -- "Oh, that's a nice grid layout... didn't ask for that hover effect but I'm keeping it." At 40 seconds, the design is complete. The code is exported to a GitHub repo. Vercel picks up the push and begins deploying. The narrator takes a sip of coffee. The Vercel build completes. The live site loads: responsive, polished, with real content. "Still too hot to drink. I should probably build a second portfolio."

Visual Concepts for Remotion:

• CoffeeTimer component: a coffee cup illustration in the corner with a steam animation, a circular progress ring around it representing time
• ComponentAssembly animation: each section of the portfolio slides into a wireframe layout, then fills in with color and content -- like a blueprint becoming a building
• v0Preview screen capture: the v0 interface generating components in real time
• VercelDeploy animation: a minimal deployment progress bar styled in Vercel's black-and-white aesthetic, with the URL appearing at the end
• Smooth crossfade transitions between the coffee close-up and the screen recording

Video #3: The $0 Startup (Lovable)

Title/Hook: "This app makes money. I didn't write a single line."

Tool: Lovable

Concept: A non-technical founder builds a complete SaaS product using only Lovable -- from idea to deployed, revenue-generating application. The video emphasizes that the person building this has no programming background. The "reveal" is not just the app, but a real Stripe dashboard showing the first payment.

Tone: Inspirational but grounded. Not "anyone can do this" hype -- more "here's exactly what the process looks like when you've never coded before."

Script Outline (190 words): Open on a text overlay: "I'm not a developer. I'm a marketing manager." The narrator continues: "Last month, I had an idea for a tool that helps freelancers track their invoices. This morning, I built it." Cut to Lovable. The prompt is detailed and specific -- it describes an invoice tracker with client management, recurring invoice templates, PDF export, and a simple dashboard showing outstanding payments. Lovable begins generating. The narration explains the key decisions: why the prompt specifies Supabase for the backend, why it asks for Row Level Security so each user only sees their own data, why it mentions Stripe Connect for future payment processing. At 45 seconds, the app is running in Lovable's preview. The narrator tests the core workflow: create a client, generate an invoice, export to PDF. Everything works. At 70 seconds, the app deploys. Cut to a real Stripe dashboard showing a $12 test payment. "I didn't write code. I didn't hire a developer. I described what I needed. Total investment: a Lovable subscription and one afternoon of prompt writing."

Visual Concepts for Remotion:

• IdentityCard intro animation: a business-card-style overlay showing "Marketing Manager" with a crossed-out "Developer" beneath it
• PromptAnnotation overlay: as the prompt scrolls, key phrases highlight and small tooltip annotations explain why each detail matters (e.g., "Row Level Security" highlights with a note: "This keeps each user's data private")
• WorkflowDemo screen recording: the invoice creation flow captured step-by-step with zoom-ins on important UI elements
• StripeReveal animation: the Stripe dashboard slides in from the bottom with a cash register sound effect and a subtle confetti particle burst
• Color palette shifts from grayscale (the "before") to full color (the "after") as the app comes to life

Video #4: Clone Wars (Cursor)

Title/Hook: "I showed AI a screenshot of Notion. Here's what happened."

Tool: Cursor (Agent mode with Composer)

Concept: A screenshot of Notion's interface is fed to Cursor's AI, along with a prompt asking it to recreate the core functionality. The video follows the agent as it plans the architecture, generates the components, and builds a working Notion-like workspace -- pages, blocks, drag-and-drop, slash commands -- all from a single image and a paragraph of context.

Tone: Playful and slightly mischievous. The "clone wars" framing leans into the controversy of AI-generated clones while keeping it lighthearted.

Script Outline (185 words): Open on a screenshot of Notion's interface. The narrator says: "This is Notion. 400 engineers built this over 10 years. I'm going to see how close AI can get in 2 minutes." The screenshot is dragged into Cursor's Composer. The prompt is brief but precise: recreate a note-taking workspace with a sidebar, nested pages, rich text blocks, slash command menu for adding headers/lists/toggles, and drag-to-reorder blocks. Cursor's agent starts planning. An overlay shows the agent's thought process -- the file tree it is creating, the components it has decided to build, the libraries it is installing. At 30 seconds, the first components render: a sidebar with a page tree. At 60 seconds, the editor is working: typing, formatting, slash commands. At 90 seconds, drag-and-drop is functional. The narrator does a side-by-side comparison with the original screenshot. Some elements are strikingly close. Others are clearly AI-generated. "Is it Notion? No. Could you use it? Absolutely. Did a human write any of this code? Not a single character."

Visual Concepts for Remotion:

• ScreenshotToCode opening animation: the Notion screenshot dissolves pixel-by-pixel into code characters, which then reassemble into the cloned interface
• AgentThinking overlay: a semi-transparent sidebar showing Cursor's agent plan as it generates -- file names, component tree, dependency list, appearing in real time
• SideBySide comparison frame: original Notion on the left, clone on the right, with a slider the viewer can conceptually drag between them
• FileTicker bottom bar: a scrolling ticker showing file names as they are created ("sidebar.tsx... editor.tsx... slash-commands.tsx..."), styled like a stock ticker
• Cursor's interface captured with visible agent actions highlighted

Video #5: The Debug Olympics (Claude Code)

Title/Hook: "Can AI fix a bug faster than Stack Overflow?"

Tool: Claude Code

Concept: A real, nasty bug -- the kind that would send a developer to Stack Overflow for an hour -- is presented to Claude Code. The screen is split: on the left, a simulated "Stack Overflow search" shows the traditional debugging path (finding related questions, reading answers, trying solutions). On the right, Claude Code analyzes the error, traces the root cause through multiple files, and delivers a working fix. A race timer tracks both sides.

Tone: Competitive and high-energy, like a sports broadcast. The narration calls the race like a commentator.

Script Outline (175 words): Open on a terminal showing a cryptic error: a React hydration mismatch caused by a timezone-dependent date format in a server component. The narrator, in a sports-announcer voice: "In the left corner, the defending champion: Stack Overflow and pure human tenacity. In the right corner, the challenger: Claude Code. The bug: a hydration error that has already cost this developer 45 minutes. Let the race begin." The split screen activates. Left side: a browser opens Stack Overflow, searches the error message, scrolls through three different answers, tries a solution that does not work, goes back. Right side: Claude Code receives the error, opens the relevant files, traces the date formatting issue across server and client components, identifies the mismatch, proposes a fix, and applies it. Claude Code finishes in 23 seconds. The left side is still reading the second Stack Overflow answer. "The AI finished before the human found the right question to ask."

Visual Concepts for Remotion:

• RaceTimer dual countdown: two stopwatches side by side, one for each approach, styled like a sports scoreboard with team colors (orange for Stack Overflow, purple for Claude)
• SplitRace composition: left and right panels with independent screen recordings, separated by a glowing dividing line
• DebugTrace animation: on Claude Code's side, colored lines connect the error message to the relevant files, showing the AI's reasoning path like a detective's evidence board
• VictoryFlash animation: when Claude Code finishes, its panel pulses with a winner overlay while the Stack Overflow panel dims
• BugAnatomy end card: a diagram showing the root cause of the bug, making the video educational as well as entertaining

Video Series 2: "The Prompt That..." (Educational + Humor)

This series takes a single prompt and follows it to its logical (and sometimes illogical) conclusion. Each video is educational at its core -- you learn prompt engineering techniques, tool capabilities, and common pitfalls -- but the framing is comedic. The "The Prompt That..." naming convention is designed for curiosity-driven clicks.

Series format:

• Duration: 90-120 seconds
• Structure: Setup (10s) -> The prompt (10s) -> The process (40-60s) -> The twist/result (20-30s) -> Lesson learned (10s) -> End card (5s)
• Visual signature: The prompt text is always displayed on a "sticky note" style card that stays pinned to the screen throughout the video
• Audio: Conversational narration, comedic timing with beat pauses, sound effects for emphasis

Video #6: The Prompt That Built a Game

Title/Hook: "The Prompt That Built a Game"

Tool: Claude Code + Remotion (for the game rendering)

Concept: A single, carefully crafted prompt generates a complete browser game -- not a trivial one, but a polished arcade game with physics, particle effects, a scoring system, leaderboard, and mobile touch controls. The video walks through the prompt's structure, explaining why each sentence matters, then shows the game coming to life.

Tone: Enthusiastic and educational. The narrator genuinely enjoys playing the result.

Script Outline (190 words): Open on the prompt, displayed as a sticky note. The narrator reads it aloud, pausing to annotate key phrases: "Notice I specified 'physics-based' -- without this, the AI defaults to simple collision rectangles." "I said 'particle effects on collision' -- this forces the AI to implement a particle system, which makes the game feel premium." The prompt is sent to Claude Code. The terminal comes alive with file creation. The narrator explains the AI's architectural decisions as they happen: "It chose HTML Canvas over DOM elements -- good call for performance." "It's implementing a game loop with requestAnimationFrame -- exactly right." At 50 seconds, the game runs for the first time. It has bugs: a sprite clips through a wall. The error is pasted back. At 65 seconds, the game runs cleanly. The narrator plays it for 20 seconds, showing the physics, particles, and scoring in action. "One prompt. One paste of an error message. A game that would have taken a junior developer a week. The lesson: specificity in your prompt is not optional. Every adjective earns its keep."

Visual Concepts for Remotion:

• StickyNote component: a yellow sticky note pinned to the top-left corner showing the prompt text, with annotations appearing as red-marker circles and arrows when the narrator highlights key phrases
• TerminalStream animation: Claude Code's terminal output rendered as a scrolling feed with syntax-highlighted file paths and code snippets
• GameEmbed live composition: the actual game running inside a Remotion frame, capturing real gameplay
• AnnotationBubble overlays: speech-bubble callouts pointing to specific lines in the prompt, explaining why they matter
• BeforeAfter bug-fix transition: a glitch effect when the bug appears, clean dissolve when it is fixed

Video #7: The Prompt That Broke Everything

Title/Hook: "The Prompt That Broke Everything"

Tool: Bolt.new

Concept: A seemingly reasonable prompt -- "refactor the entire codebase to use TypeScript strict mode" -- is applied to a working JavaScript project. The video documents the cascade of failures: type errors multiply exponentially, the AI tries to fix them but introduces new ones, the build breaks, and the project enters what the narrator calls "the error spiral." The video then shows the recovery: how to scope refactoring prompts correctly.

Tone: Darkly comedic, building to genuine relief. The narrator treats the error messages like a horror movie.

Script Outline (185 words): Open on a working application. Green checkmarks everywhere. The narrator says: "This app works perfectly. It has 47 files, zero bugs, and 100% of its tests pass. I am about to destroy it with one sentence." The prompt appears: "Refactor this entire codebase to use TypeScript strict mode with no 'any' types." The AI begins. At first, it looks productive -- .js files become .tsx files. Then the errors start. The error count appears as a rising counter in the corner: 12... 47... 134... 312. The narrator's tone shifts from confident to concerned to horrified. "It's adding type assertions everywhere. Those are band-aids. The types are lying." At 60 seconds, the build fails completely. The recovery begins: the narrator shows how to scope the same refactoring into small, file-by-file prompts with test verification between each step. The error count drops. The builds pass. "The lesson: AI can refactor anything. But 'anything' and 'everything at once' are different requests."

Visual Concepts for Remotion:

• ErrorCounter component: a large, prominent counter in the top-right that ticks up with each new TypeScript error, turning from green to yellow to orange to red as the count increases, with screen-shake at milestones (100, 200, 300)
• CascadeVisualization animation: errors displayed as falling dominoes or multiplying cells, visually representing the chain reaction
• HealthBar component: a video-game-style health bar for the project, draining as errors accumulate, flashing red at critical levels
• RecoveryTimeline animation: a horizontal timeline showing the correct approach -- small, scoped prompts with green checkmarks between each step
• Split-screen during recovery: the broken approach on top (red-tinted), the correct approach on the bottom (green-tinted)

Video #8: The Prompt That Got Me Fired (Hypothetically)

Title/Hook: "The Prompt That Got Me Fired (Hypothetically)"

Tool: Claude Code

Concept: A developer accidentally uses a vibe coding workflow on a production codebase -- accepting all changes without review, pushing without tests, deploying on a Friday afternoon. The video is a dramatized worst-case scenario that teaches real lessons about when NOT to vibe code. Every mistake is a real mistake that real developers have made.

Tone: Mock-serious, documentary style. Presented like a true-crime investigation of a deployment gone wrong.

Script Outline (180 words): Open on a dramatic title card: "INCIDENT REPORT: February 14, 2026." The narrator, in a deadpan documentary voice: "The following is a reconstruction of actual events. Names have been changed. The code has not." The prompt is revealed: a developer asked the AI to "update the user billing logic to handle the new pricing tiers" on the production branch. Without reading the diff. Without running tests. On a Friday at 4:47 PM. The AI changed the billing calculation -- and introduced a rounding error that charged every customer $0.01 extra per transaction. The video shows the cascade: the deploy, the first customer complaint, the Slack messages, the rollback attempt that failed because there was no checkpoint. "By Monday morning, 47,000 transactions were affected." The recovery section shows what should have happened: feature branch, test suite, staging deployment, code review. "Vibe coding is a superpower. And like every superpower, using it in the wrong context has consequences."

Visual Concepts for Remotion:

• IncidentReport styling: the entire video uses a corporate incident report aesthetic -- monospace fonts, timestamps, severity indicators, redacted sections
• SlackMessages animation: recreated Slack-style message bubbles appearing with increasing urgency ("@channel anyone else seeing billing discrepancies?", "this is not a drill")
• TimelineOfFailure component: a horizontal timeline with red flags marking each mistake (no branch, no tests, no review, Friday deploy)
• RollbackFail animation: a dramatic "FAILED" overlay with klaxon-style visual pulse when the rollback does not work
• ChecklistReveal end animation: the correct process appearing as a green checklist, each item checking off with a satisfying animation

Video #9: The Prompt That Replaced My Intern

Title/Hook: "The Prompt That Replaced My Intern"

Tool: Cursor + Claude Code

Concept: A tech lead has a list of 23 tedious but necessary tasks that would normally be assigned to a junior developer or intern: rename variables to follow conventions, add JSDoc comments to exported functions, update deprecated API calls, create missing test stubs, fix all ESLint warnings. One prompt handles all of them. The video compares the estimated "intern hours" with the actual AI minutes.

Tone: Sympathetic and slightly guilty. The narrator acknowledges the awkwardness of the topic while being honest about the productivity gains.

Script Outline (175 words): Open on a task list -- 23 items, each with an estimated time: "Rename callbacks to follow naming convention (2 hours)," "Add JSDoc to all exported functions (4 hours)," "Update deprecated moment.js calls to dayjs (3 hours)." Total estimate: 34 hours of intern work. The narrator says: "I used to give this list to our summer intern. It would take them a full work week. This morning I gave it to the AI." A single, structured prompt appears, listing all 23 tasks with clear specifications. Claude Code begins. A progress bar tracks completed tasks. The terminal output shows files being modified, tests passing. At 45 seconds, 23 of 23 tasks are done. The narrator reviews the changes: "The variable renames are consistent. The JSDoc comments are accurate. The moment-to-dayjs migration handles edge cases I didn't think of." Total time: 8 minutes. "The intern now works on architecture decisions and feature design. The AI handles the checklist."

Visual Concepts for Remotion:

• TaskBoard component: a kanban-style board with 23 cards, each sliding from "To Do" to "In Progress" to "Done" as the AI completes them
• TimeComparison split bar: a bar chart comparing "Intern: 34 hours" vs "AI: 8 minutes," with the AI bar barely visible next to the intern bar
• ProgressTracker overlay: "3/23 complete... 11/23... 19/23..." with each milestone triggering a small celebration animation
• DiffPreview popups: brief glimpses of the actual code changes (before/after) for two or three of the most interesting tasks
• Warm color palette (no cold, "replacing humans" vibe) -- the end card explicitly shows the intern now working on more interesting problems

Video #10: The Prompt That Even My Mom Could Use

Title/Hook: "The Prompt That Even My Mom Could Use"

Tool: Lovable

Concept: The narrator's actual non-technical parent uses Lovable to build a small app -- a recipe organizer -- from scratch, using only natural language. The video is screen-recorded over the parent's shoulder (with permission). The charm is in the completely non-technical prompt language: "I want a thing where I can put my recipes and find them later, like a cookbook but on the computer."

Tone: Warm, genuine, and slightly humorous. The non-technical language in the prompts is endearing, not mocking.

Script Outline (185 words): Open on a text overlay: "I gave my mom a Lovable account and one instruction: build whatever you want." Cut to the screen. The prompt is typed in plain, non-technical English: "I want to save my recipes. Each recipe should have a name, the ingredients, the steps, and a photo. I want to search by ingredient so when I have chicken I can find all my chicken recipes. Make it pretty with a warm color like my kitchen." Lovable generates the app. The narrator points out that "make it pretty with a warm color like my kitchen" resulted in a terracotta-and-cream color scheme that actually looks good. The recipe form works. The search works. Photo upload works. The narrator's parent adds a real recipe -- handwritten notes visible on the desk for reference. The app works exactly as described. "She didn't say 'database.' She didn't say 'component.' She didn't say 'responsive.' She said 'like a cookbook but on the computer.' And that was enough."

Visual Concepts for Remotion:

• HandwrittenOverlay styling: the prompt text appears in a handwriting-style font rather than monospace, reinforcing the non-technical nature
• KitchenWarmth color grading: the entire video has a warm, slightly golden color grade -- cozy and approachable
• RecipeCard animation: when the generated app shows a recipe, it animates like flipping a page in a physical cookbook
• SearchDemo screen recording: the ingredient search in action, with a zoom-in on the results filtering in real time
• QuoteCard end overlay: "She said 'like a cookbook but on the computer.' And that was enough." in large, warm-toned typography

Video #11: The Prompt That Fooled the Senior Dev

Title/Hook: "The Prompt That Fooled the Senior Dev"

Tool: Claude Code

Concept: A blind code review experiment. A senior developer is shown two pull requests: one written by a mid-level human developer, one generated entirely by AI from a single prompt. The senior reviews both, provides feedback, and guesses which is which. The reveal shows whether they guessed correctly -- and what the AI code got right that the human code got wrong (and vice versa).

Tone: Fair and balanced. This is not an "AI is better" video -- it is an honest comparison that reveals strengths and weaknesses on both sides.

Script Outline (195 words): Open on two code editors, labeled "Developer A" and "Developer B." The narrator explains: "A senior engineer with 12 years of experience is going to review two implementations of the same feature -- a real-time notification system. One was written by a mid-level developer in 6 hours. The other was generated by Claude Code from a single prompt in 4 minutes. The reviewer doesn't know which is which." Cut to the review. The senior developer's comments appear as overlays: "Developer A has clean separation of concerns... but this error handling is naive." "Developer B's type safety is impressive... but this abstraction feels over-engineered." The senior guesses: "A is the human, B is the AI. The human code feels more intentional. The AI code is technically thorough but lacks personality." The reveal: they got it backwards. Developer A was the AI. Developer B was the human. The narrator unpacks the implications: the AI's code was structurally cleaner, but the human's code had more creative architectural choices. "Neither was strictly better. They were differently excellent."

Visual Concepts for Remotion:

• BlindReview split screen: two code panels with neutral labels ("Developer A" / "Developer B"), no visual hints about origin
• ReviewComment overlays: the senior developer's comments appear as GitHub-PR-style review annotations, sliding in from the right margin
• GuessReveal animation: the labels flip over like cards, revealing "AI" and "Human" with a dramatic pause and sound effect
• ComparisonMatrix end card: a radar chart comparing both implementations across axes (readability, type safety, error handling, architecture, creativity, performance)
• Neutral color scheme throughout -- neither side gets a "winner" color until the analysis section

Video Series 3: "Tool Face-Off" (Comparison)

This series puts competing tools head-to-head on identical tasks. Same prompt, same requirements, same hardware. The evaluation is structured and scored across consistent categories: speed, code quality, developer experience, and output completeness. These are the videos developers watch before choosing their next tool.

Series format:

• Duration: 90-120 seconds
• Structure: Rules (10s) -> Tool A attempt (30-40s) -> Tool B attempt (30-40s) -> Scoring (15s) -> Verdict (10s) -> End card (5s)
• Visual signature: Boxing-match / tournament-bracket aesthetic with tool logos in corners, round numbers, and scorecard overlays
• Audio: Sports-style narration, bell sounds between rounds, dramatic pause before verdict

Video #12: Round 1 -- IDE Showdown (Cursor vs Claude Code vs Codex CLI)

Title/Hook: "Round 1: IDE Showdown -- Cursor vs Claude Code vs Codex CLI"

Tools: Cursor (Agent mode), Claude Code, OpenAI Codex CLI

Concept: All three tools receive the same prompt: build a task management API with authentication, CRUD operations, and automated tests. The video captures all three attempts simultaneously using a triple split-screen. Each tool is scored on time to completion, test pass rate, code quality (measured by a linting score), and developer experience (subjective rating of the interaction).

Tone: Fair, analytical, and energetic. This is a sports broadcast, not a product review. Every tool gets genuine praise for its strengths.

Script Outline (200 words): Open on a tournament bracket graphic. The narrator, in an announcer voice: "Three tools. One prompt. One winner. This is the IDE Showdown." The prompt appears: a task management REST API with JWT authentication, full CRUD, input validation, pagination, and a test suite. The rules: no human intervention after the prompt is submitted, tools are scored on four categories, each worth 25 points. "Round 1: Speed." The triple split-screen activates. Cursor's agent starts planning, showing its step-by-step approach. Claude Code opens multiple files simultaneously, working fast. Codex CLI takes a methodical, file-by-file approach. Time stamps appear as each tool finishes. "Round 2: Tests." Each tool's test suite runs. Pass rates appear on the scoreboard. "Round 3: Code Quality." ESLint scores flash on screen. "Round 4: Developer Experience." The narrator rates the interaction quality: how clear was the agent's communication, how easy was it to follow along, how much manual intervention was needed. The scorecard fills in. The verdict is revealed. "All three built a working API. The differences are in the details."

Visual Concepts for Remotion:

• TournamentBracket intro animation: a bracket graphic with tool logos, styled like a boxing event poster
• TripleSplit composition: three equal panels running simultaneous screen recordings, each with a tool logo badge and running timer in the corner
• Scoreboard component: a four-category scoring grid that fills in during the verdict section, each score animating from 0 to its final value
• RoundBell transition: a boxing bell sound and "ROUND 2" text between each scoring category
• VerdictCard final overlay: total scores, category winner badges, and a nuanced text verdict ("Best for speed: X. Best for quality: Y. Best for beginners: Z.")

Video #13: Round 2 -- Builder Battle (Bolt.new vs Lovable vs Replit Agent)

Title/Hook: "Round 2: Builder Battle -- Bolt.new vs Lovable vs Replit Agent"

Tools: Bolt.new, Lovable, Replit Agent

Concept: The browser-based builders compete on a task suited to their strengths: build a complete landing page with a waitlist form, social proof section, feature comparison, and email capture that stores submissions to a real database. Scoring covers design quality, functionality, mobile responsiveness, and deployment speed.

Tone: Enthusiastic and visual. Since these are design-heavy tools, the video emphasizes how each app looks and feels rather than focusing purely on code.

Script Outline (190 words): Open on the challenge card: "Build a startup landing page with working waitlist signup. You have 3 minutes." Each builder gets the same prompt: a landing page for a fictional AI writing tool called "DraftPilot," with a hero section, three feature cards, a testimonial carousel, a pricing comparison, and a waitlist form that saves emails to Supabase. The triple split-screen shows all three tools working simultaneously. The narrator calls attention to interesting differences in real time: "Bolt.new went straight for the hero section -- it's already looking polished." "Lovable is building the database connection first -- solid fundamentals." "Replit Agent just asked a clarifying question about the color scheme -- that's a nice touch." At 90 seconds, the designs are compared side-by-side: mobile views, desktop views, scroll behavior, form functionality. Each tool's waitlist form is tested with a real email submission. The scoring covers design (how good does it look), function (does the form actually save data), responsiveness (mobile rendering), and speed (time to deployable state). "Each builder has a personality. The question is which personality matches yours."

Visual Concepts for Remotion:

• BuilderCard intro: each tool's logo on a playing-card-style design, dealt onto the screen like a card game
• DesignComparison frame: all three landing pages shown as browser mockups on a desk, with the ability to zoom into each one
• MobilePreview animation: each landing page shrinks into a phone-shaped frame to show mobile rendering, side by side
• FormTest overlay: a live-action hand typing a test email into each form, with a green checkmark when the submission succeeds
• PersonalityCard end graphic: each tool gets a one-line personality description ("Bolt.new: The Speed Demon," "Lovable: The Perfectionist," "Replit Agent: The Conversationalist")

Video #14: Round 3 -- Agent Arena (Devin vs Jules vs Claude Code)

Title/Hook: "Round 3: Agent Arena -- Devin vs Jules vs Claude Code"

Tools: Devin, Google Jules, Claude Code

Concept: The autonomous agents tackle a more complex task: given an existing open-source project with 15 open issues, each agent is assigned 5 issues and must work independently to create pull requests. Scoring covers issue resolution rate, PR quality, test coverage of the fix, and how well the agent communicated its approach.

Tone: Analytical with a sense of drama. These are the most powerful tools in the landscape, and the comparison is genuinely informative for teams making purchasing decisions.

Script Outline (200 words): Open on a GitHub issues page showing 15 open issues. The narrator: "Welcome to the Agent Arena. Three autonomous AI agents. Five GitHub issues each. No human help. Who writes the best pull requests?" The issues range from a CSS bug to a database query optimization to a feature request for dark mode. Each agent receives its 5 issues and a cloned copy of the repo. The video shows a triple timeline: Devin working in its cloud VM, Jules working asynchronously through Google Cloud, Claude Code working in the terminal. Key moments are highlighted: "Devin just opened a PR for the CSS bug -- let's see the diff." "Jules is running the test suite before committing -- smart." "Claude Code found a related bug while fixing issue #7 and filed a new issue for it -- above and beyond." After all agents submit their PRs, a senior developer reviews them. Scoring: issues resolved (did the PR actually fix it), code quality (clean diff, no regressions), test coverage (did the agent add tests), and communication (how clear was the PR description and commit message). "At this level, the differences are subtle. But subtle differences matter at scale."

Visual Concepts for Remotion:

• GitHubBoard composition: a project board with issue cards, each card moving to the agent's column as they are assigned
• AgentTimeline triple track: three horizontal timelines showing each agent's progress -- commits appear as dots, PRs as flags, with timestamps
• PRReview overlay: a GitHub-style PR diff view showing the agent's changes, with the senior developer's review comments fading in
• ScoreRadar chart: a radar/spider chart for each agent across the four scoring dimensions
• ArenaStadium framing: the entire video is styled like an arena event, with spotlights, agent "entrances," and a final podium reveal

Video #15: Round 4 -- Speed vs Quality (Bolt vs Claude Code)

Title/Hook: "Round 4: Speed vs Quality -- Bolt.new vs Claude Code"

Tools: Bolt.new, Claude Code

Concept: This is the philosophical face-off: the fastest browser builder against the most thorough terminal agent. The same prompt -- a complete habit-tracking app with streaks, charts, and reminders -- goes to both tools. Bolt.new finishes in minutes. Claude Code takes longer but produces more robust code. The question is not "which is better" but "which is better for what."

Tone: Thoughtful and balanced. This video acknowledges that "better" depends entirely on context.

Script Outline (195 words): Open on a scale graphic: "Speed" on one side, "Quality" on the other. The narrator: "Every developer makes this trade-off. Today we make it explicit." The prompt: a habit tracker with daily check-ins, streak counting with freeze days, progress charts using a real charting library, push notification reminders, and data export. Bolt.new starts. The app assembles rapidly in the browser -- UI components appear, the habit list renders, the chart populates. Time: 3 minutes and 12 seconds. It looks good. It works. Claude Code starts. The terminal is busier -- it is setting up a proper project structure, adding TypeScript types, writing utility functions with edge case handling, creating a test file. Time: 14 minutes and 47 seconds. It also works. Now the comparison. The narrator stress-tests both: "What happens when the streak crosses a month boundary?" Bolt's version has a bug. Claude Code's handles it correctly. "What about the UI?" Bolt's is more visually polished out of the box. "Both answers are right. The question is what you need right now: a working prototype by lunch, or a production foundation by end of week."

Visual Concepts for Remotion:

• ScaleBalance component: a literal balance scale that tips toward speed (Bolt) or quality (Claude Code) as different criteria are evaluated
• DualTimer composition: two race-style timers, one for each tool, with the differential growing as Claude Code continues working after Bolt finishes
• StressTest overlay: identical test inputs applied to both apps simultaneously, with results appearing as pass/fail indicators
• ContextCard end graphic: two scenario cards -- "Choose Bolt when: hackathon, prototype, demo day" and "Choose Claude Code when: production, long-term project, team codebase" -- appearing side by side
• Warm vs cool color split: Bolt's side in warm oranges (energy, speed), Claude Code's side in cool blues (precision, depth)

Video Production Workflow

Every video in this chapter follows the same five-stage production pipeline. This section documents the pipeline so that new videos can be produced consistently and efficiently.

Stage 1: Script Writing

Every video begins as a markdown file. Scripts follow a strict format:

---
video_id: PTP-001
series: prompt-to-product
title: "I built a $9/month SaaS in 60 seconds"
duration_target: 60-90s
tool: Bolt.new
status: production
last_updated: 2026-02-25
---

## Hook (0:00 - 0:03)
[Opening visual description]
NARRATOR: "Opening line designed to stop the scroll."

## Setup (0:03 - 0:08)
[Screen state description]
NARRATOR: "Context setting. What we are about to do and why it matters."

## Build (0:08 - 0:55)
[Screen recording cues with timestamps]
NARRATOR: "Running commentary on what the AI is doing. Call out
interesting decisions. Keep energy high."

## Reveal (0:55 - 1:05)
[Final product display]
NARRATOR: "The payoff. Show the deployed result. Land the key stat."

## End Card (1:05 - 1:10)
[Branding overlay]
NARRATOR: "Call to action -- next video, ebook link, subscribe."

Script guidelines:

• Target 150-200 words of narration per video (approximately 2 words per second at conversational pace)
• Every sentence must earn its place -- if it does not advance understanding or maintain engagement, cut it
• Write the hook first. If the first 3 seconds do not compel a viewer to keep watching, rewrite them
• Include specific timestamps for visual cues so the Remotion composition can sync precisely
• Mark all screen recording segments with [SCREEN: tool_name, action_description] tags

Stage 2: Visuals (Remotion Compositions)

Each video is a Remotion composition -- a React component that renders frame-by-frame to produce video output. The compositions combine three types of visual content:

Screen Recordings

• Captured at 60fps using OBS Studio with a standardized window layout
• Tool interfaces are recorded at 1920x1080 with consistent browser chrome
• Mouse movements are smoothed in post-processing for cleaner playback
• Sensitive information (API keys, personal data) is redacted before compositing

Motion Graphics

• Countdown timers, score overlays, progress bars, and transitions are all Remotion components
• The component library includes: CountdownTimer, ScoreBoard, SplitScreen, ProgressTracker, TitleCard, EndCard, AnnotationBubble, CodeHighlight
• All motion graphics follow the EndOfCoding design system (see Branding below)
• Animations use spring physics for natural-feeling motion (useSpring from Remotion)

Code Animations

• Code snippets that appear in videos are rendered using a custom CodeBlock Remotion component
• Syntax highlighting uses the same theme across all videos (VS Code Dark+ variant)
• Code appears with a typewriter animation at a configurable speed
• Diff views use green/red highlighting with line-by-line reveal animations

Composition structure:

src/
  compositions/
    prompt-to-product/
      PTP001-SaaS60.tsx        # Main composition
      PTP001-assets/            # Screen recordings, images
    the-prompt-that/
      TPT001-Game.tsx
      TPT001-assets/
    tool-face-off/
      TFO001-IDEShowdown.tsx
      TFO001-assets/
  components/
    CountdownTimer.tsx
    ScoreBoard.tsx
    SplitScreen.tsx
    EndCard.tsx
    StickyNote.tsx
    CodeBlock.tsx
    ProgressTracker.tsx
    RaceTimer.tsx
  styles/
    theme.ts                   # Shared colors, fonts, spacing
    animations.ts              # Shared spring configs

Stage 3: Audio

Narration

• AI text-to-speech narration using ElevenLabs or equivalent high-quality TTS
• Voice profile: confident, conversational, slightly fast-paced (matching the energy of the content)
• Each script is narrated as a single take, then trimmed and aligned to visual cues in Remotion
• Pronunciation corrections are applied for technical terms (e.g., "Supabase" is "soo-puh-base," not "super-base")

Sound Design

• Background music: royalty-free electronic/lo-fi tracks from Epidemic Sound or Artlist, selected per series (energetic for Prompt to Product, chill for The Prompt That, competitive for Tool Face-Off)
• Sound effects library: keystroke clicks, notification chimes, deployment whooshes, error buzzes, success dings, countdown ticks, boxing bells
• Music ducking: background track volume drops 60% during narration, rises during visual-only segments
• Audio levels: narration at -14 LUFS, music at -24 LUFS, sound effects at -18 LUFS

Stage 4: Branding

Every video carries the EndOfCoding brand identity consistently:

Logo

• The EndOfCoding logo appears in the bottom-right corner throughout the video at 40% opacity
• Full logo displayed on the end card at 100% opacity with the tagline

Color Palette

• Primary: #6C5CE7 (electric purple) -- used for highlights, CTAs, and active states
• Secondary: #00D2D3 (cyan) -- used for accents, secondary information
• Background: #0F0F23 (deep navy) -- used for all dark backgrounds
• Surface: #1A1A2E (dark surface) -- used for cards and overlays
• Text: #FFFFFF at 90% opacity for primary text, 60% for secondary
• Success: #00E676 -- used for pass indicators, completion states
• Error: #FF5252 -- used for fail indicators, error states

Typography

• Titles: Inter Bold, 48px (scaled for video resolution)
• Body: Inter Regular, 24px
• Code: JetBrains Mono, 20px
• Captions: Inter Medium, 18px

End Card (last 5 seconds of every video)

• Full EndOfCoding logo centered
• Three cross-link buttons: "Watch Next Video" (left), "Read the Ebook" (center), "Subscribe" (right)
• Social handles displayed below
• Background: animated gradient using the primary/secondary colors

Stage 5: Distribution

Each video exists in multiple formats for different platforms:

Full-Length (YouTube + Ebook Embed)

• Resolution: 1920x1080 (16:9)
• Duration: 60-120 seconds
• Format: MP4 (H.264) for YouTube, WebM for ebook embed
• Hosted on YouTube with ebook embed via YouTube iframe or self-hosted WebM

Short-Form Clips (TikTok / Instagram Reels / YouTube Shorts)

• Resolution: 1080x1920 (9:16)
• Duration: 15-60 seconds
• Extracted from the most compelling segment of the full video
• Additional text overlays for silent autoplay viewing (captions burned in)
• Platform-specific crops handled by a Remotion VerticalCrop composition