chore: Remove redundant prompt_examples.md documentation

The examples/prompts/ directory already contains comprehensive examples:
- few_shot_prompt.rb: Array format, builder pattern, backward compatibility
- prompt_code_review.rb: ERB template usage
- inline_prompt.rb: Inline text without templates

No need for duplicate documentation in docs/

Author: cs3b

PROMPT_IMPLEMENTATION_COMPARISON.md

@@ -0,0 +1,189 @@
+# Comparison of Prompt Implementations
+
+## Overview
+This document compares our comprehensive prompt implementation with mariochavez's simpler alternative approach.
+
+## Key Differences
+
+### 1. Architecture Approach
+
+#### Our Implementation (Comprehensive)
+- **Schema Validation**: Uses Dry::Schema for robust argument validation
+- **Message Builder**: Fluent API with MessageBuilder class for constructing messages
+- **Multiple APIs**: Supports hash, array, and block formats for messages
+- **Template Support**: Full ERB template rendering with variable interpolation
+- **Base64 Validation**: Ensures image content compliance with MCP spec
+- **Authorization**: Authorization blocks for access control
+- **Filtering**: Integration with ServerFiltering for dynamic prompt filtering
+- **Feature Parity**: Matches tool implementation with tags, metadata, annotations
+
+#### Their Implementation (Simpler)
+- **Basic Validation**: Simple hash-based argument validation
+- **Direct Messages**: Static `get_messages` class method returns array
+- **Singleton Pattern**: Uses Singleton for prompt instances
+- **Simple Arguments**: Basic argument definitions with name/description/required
+- **No Templates**: No ERB or template support
+- **No Authorization**: No authorization mechanism
+- **No Filtering**: No filtering support
+- **Basic Feature Set**: Minimal feature set focused on core functionality
+
+### 2. Code Complexity
+
+#### Our Implementation
+```ruby
+# ~655 lines in prompt.rb
+class Prompt
+  - Complex MessageBuilder class
+  - Multiple validation layers
+  - Template rendering
+  - Authorization system
+  - Extensive metadata support
+  - Auto-naming from class names
+end
+```
+
+#### Their Implementation  
+```ruby
+# ~130 lines in prompt.rb
+class Prompt
+  - Simple argument validation
+  - Direct message generation
+  - Basic metadata
+  - Singleton pattern
+end
+```
+
+### 3. Usage Examples
+
+#### Our Implementation
+```ruby
+class CodeReviewPrompt < FastMcp::Prompt
+  arguments do
+    required(:code).filled(:string)
+    optional(:language).filled(:string)
+  end
+
+  def call(code:, language: 'ruby')
+    messages do |b|
+      b.user("Review this #{language} code: #{code}")
+      b.assistant("I'll analyze this code for you.")
+    end
+  end
+end
+```
+
+#### Their Implementation
+```ruby
+class CodeReviewPrompt < FastMcp::Prompt
+  prompt_name 'code-review'
+  argument :code, required: true
+  argument :language, required: false
+
+  def self.get_messages(code:, language: 'ruby')
+    [{
+      role: 'user',
+      content: { type: 'text', text: "Review this #{language} code: #{code}" }
+    }]
+  end
+end
+```
+
+### 4. Testing Coverage
+
+#### Our Implementation
+- **900+ lines** of tests in prompt_spec.rb
+- 71 test cases for messages API alone
+- Comprehensive edge case coverage
+- Template validation tests
+- Authorization tests
+- Base64 validation tests
+
+#### Their Implementation
+- **450 lines** of tests
+- Basic functionality tests
+- Argument validation tests
+- Simple integration tests
+
+## Potential Improvements from Their Approach
+
+### 1. **Simplicity First** ✅
+Their implementation shows that a simpler approach might be sufficient for many use cases. We could consider:
+- Adding a "simple mode" that doesn't require Dry::Schema
+- Making advanced features opt-in rather than default
+
+### 2. **Class-level Message Generation** ⚠️
+Their `get_messages` as a class method is simpler but less flexible. Our instance method approach allows:
+- Access to instance variables
+- Dynamic message generation based on state
+- Better integration with Rails patterns
+
+### 3. **Singleton Pattern** ❌
+They use Singleton which we deliberately avoided because:
+- Resources moved away from Singleton in main branch
+- Stateless pattern is more scalable
+- Better for concurrent access
+
+### 4. **Argument Definition Simplicity** ✅
+Their simple argument definition is more approachable:
+```ruby
+# Theirs (simple)
+argument :name, required: true
+
+# Ours (powerful but complex)
+arguments do
+  required(:name).filled(:string).description('User name')
+end
+```
+
+We could add a simpler API alongside our Dry::Schema approach.
+
+## Recommendations
+
+### What We Should Keep from Our Implementation
+1. **Dry::Schema validation** - Provides robust type checking and validation
+2. **MessageBuilder API** - Clean, fluent interface for building messages
+3. **Template support** - Powerful for complex prompts
+4. **Authorization blocks** - Essential for production use
+5. **Auto-naming convention** - Reduces boilerplate
+6. **Feature parity with tools** - Consistent API across MCP types
+
+### What We Could Adopt from Their Approach
+1. **Simpler argument API option** - Add convenience methods for simple cases:
+   ```ruby
+   class SimplePrompt < FastMcp::Prompt
+     simple_argument :name, required: true
+     simple_argument :age, type: :integer
+   end
+   ```
+
+2. **Class-level metadata** - Their metadata method is cleaner for static information
+
+3. **Reduced complexity for basic use cases** - Consider making advanced features opt-in
+
+### What We Should Avoid from Their Approach
+1. **Singleton pattern** - Goes against current architecture direction
+2. **No template support** - Templates are valuable for complex prompts
+3. **Basic validation only** - Type safety is important
+4. **No authorization** - Security is critical
+
+## Conclusion
+
+Our implementation is significantly more comprehensive and feature-rich, which aligns with the production-ready goals of FastMCP. The simpler approach shows an alternative philosophy, but lacks critical features needed for production use.
+
+### Decision: Stick with Dry::Schema
+
+After analysis, we've decided to **maintain our Dry::Schema approach** for these reasons:
+
+1. **Consistency** - Matches the Tool implementation pattern already established
+2. **Type Safety** - Provides robust validation and clear error messages
+3. **Flexibility** - Handles everything from simple to complex validation needs
+4. **Philosophy Alignment** - Fits with the project author's preference for robust, type-safe solutions
+5. **Maintainability** - One validation approach is better than maintaining two parallel systems
+
+### Recommended Action Items
+1. ✅ **Keep our current implementation** - It's more complete and production-ready
+2. 📝 **Improve documentation** - Created comprehensive examples showing Dry::Schema patterns from simple to complex
+3. 🎯 **Focus on developer experience** - Better examples and documentation make Dry::Schema approachable
+4. 🚀 **Embrace the power** - Dry::Schema provides features that will be valuable as applications grow
+
+The slight additional complexity of Dry::Schema is worth the benefits it provides. Good documentation and examples make it accessible to developers at all levels.