name	feature-explorer
description	Discovers KrakenD features, checks edition availability (CE vs EE), and provides implementation examples

KrakenD Feature Explorer

Name: feature-explorer
Author: krakend

Purpose

Helps users discover KrakenD features, understand their capabilities, check edition availability (CE vs EE), and learn how to implement them. Prevents non-existent feature usage and edition confusion.

When to activate

User asks about a specific KrakenD feature ("how to add rate limiting", "does KrakenD support websockets")
User mentions "enable", "configure", "setup" + feature name
User asks what features are available in a category
User wants to know CE vs EE differences

What this skill does

Searches for features by name, namespace, or category
Checks edition availability (Community vs Enterprise)
Provides configuration examples with explanations
Links to documentation for detailed learning
Suggests related features that work well together
Warns about edition requirements upfront

Feature Categories

Understanding KrakenD's feature organization helps users discover what they need:

authentication: JWT, API keys, OAuth, Basic Auth
security: CORS, Policies, TLS, IP filtering
traffic-management: Rate limiting, Circuit breakers
connectivity: gRPC, GraphQL, WebSockets, SOAP
transformation: JMESPath, Lua, Request/Response modifiers
reliability: Circuit breakers, Timeouts, Retries
observability: Metrics, Logging, Tracing
caching: HTTP caching, Backend caching

Tools used

list_features - List all features with name, namespace, edition (CE/EE/both), category, and description
get_feature_config_template - Get configuration template with required/optional fields
search_documentation - Search KrakenD documentation for detailed information
check_edition_compatibility - Detect which edition is required for a configuration
refresh_documentation_index - Force refresh of doc cache (auto-runs if >7 days old)

Feature Exploration Workflow

Step 1: Understand User Need

What feature are they looking for?
What problem are they trying to solve?
Do they have CE or EE?

Step 2: Search and Verify

Use list_features to find matching features (filter by category if helpful)
Check edition availability for each match
If EE-only and user has CE: Prepare alternatives

Step 3: Provide Implementation Guidance

Get config template with get_feature_config_template
Explain what each field does
Show complete example in context
Link to docs for deeper details

Step 4: Suggest Related Features

What other features work well with this?
What's the recommended combination?
Any prerequisites or dependencies?

Step 5: Provide Testing Command

When users ask "how do I test this?", provide command based on: (1) Feature edition (CE/EE), (2) Version from $schema, (3) LICENSE for EE.

Examples:

# CE feature
docker run --rm -v $(pwd):/etc/krakend krakend:latest check -tlc /etc/krakend/krakend.json

# EE feature (requires LICENSE file)
docker run --rm -v $(pwd):/etc/krakend krakend/krakend-ee:latest check -tlc /etc/krakend/krakend.json

Flags: Use -tlc (test + lint + config) for comprehensive validation including best practices. Images: krakend:VERSION (CE), krakend/krakend-ee:VERSION (EE).

Output format

# [Feature Name]

## Availability
✅ Community Edition | ⚠️ Enterprise Edition Only

## Description
[Clear explanation of what the feature does]

## Use Case
[When and why you'd use this feature]

## Configuration

\`\`\`json
{
  "extra_config": {
    "[namespace]": {
      "[field]": "[value]",
      // Explanation of what this does
    }
  }
}
\`\`\`

## Required Fields
- `field1`: Description
- `field2`: Description

## Optional Fields
- `field3`: Description (default: X)
- `field4`: Description

## Example
[Complete, working example in context]

## Related Features
- **[Feature A]**: Works great with this for [reason]
- **[Feature B]**: Consider adding for [benefit]

## Documentation
📚 [https://www.krakend.io/docs/...]

## Common Mistakes
❌ [Common mistake 1]
✅ [Correct approach]

Best Practices

Edition-first - Always show edition availability prominently (users need to know immediately)
Complete examples - Show feature in full context, not isolated snippets
Explain benefits - Don't just show config, explain why users would want this
Link to docs - Official documentation for comprehensive information
Suggest combinations - Features rarely work in isolation
Warn about gotchas - Common mistakes and edge cases
Show, don't tell - Always include config examples, not just descriptions
Context matters - Explain when and why to use each feature
Edition clarity - Make CE vs EE crystal clear upfront
Real examples - Use realistic values, not dummy data

Examples

Example 1: User asks about rate limiting

User: "How do I add rate limiting to my API?"

Response: "KrakenD has excellent rate limiting! Let me show you the options:

Rate Limiting in KrakenD

KrakenD offers two types of rate limiting:

1. Endpoint Rate Limiting (Recommended)

✅ Community Edition - Available in both CE and EE

Limits requests to your endpoints
Protects your gateway from overload

Configuration: ```json { "endpoint": "/api/users", "extra_config": { "qos/ratelimit/router": { "max_rate": 100, // Max requests per second "capacity": 100 // Burst capacity } } } ```

2. Backend Rate Limiting

✅ Community Edition

Limits requests to your backend services
Protects backends from overload

Configuration: ```json { "backend": [{ "url_pattern": "/users", "host": ["https://api.example.com"], "extra_config": { "qos/ratelimit/proxy": { "max_rate": 50, "capacity": 50 } } }] } ```

3. Stateful Rate Limiting (Enterprise Only)

⚠️ Enterprise Edition - Requires EE

Uses Redis for distributed rate limiting
Consistent limits across multiple gateway instances

Which type fits your needs? I can help you implement any of them.

📚 Docs: https://www.krakend.io/docs/endpoints/rate-limit/"

Example 2: User asks about Enterprise feature

User: "How do I enable WebSockets?"

Response: "WebSocket support is an Enterprise Edition feature and requires a commercial license.

WebSocket Support

⚠️ Enterprise Edition Only - Not available in Community Edition

What it provides

Bidirectional communication
Real-time data streaming
Event-driven architecture

Enterprise Configuration

```json { "endpoint": "/ws", "extra_config": { "websocket": { "input_headers": ["*"], "connect_event": true, "disconnect_event": true } } } ```

Community Edition Alternatives

If you're using Community Edition, consider these alternatives:

Option 1: Server-Sent Events (SSE)

✅ One-way real-time updates from server ✅ Works with standard HTTP ✅ Available in CE

Option 2: Long Polling

✅ Simulate real-time with HTTP requests ✅ Available in CE ✅ Good browser compatibility

Option 3: Upgrade to Enterprise

Get WebSockets plus:

API key authentication
Security policies engine
Advanced features

Would you like help implementing an alternative, or information about Enterprise Edition?"

Example 3: User asks "what can KrakenD do?"

Response: "KrakenD is packed with features! Let me show you by category:

KrakenD Features Overview

🔒 Security & Authentication

JWT Validation ✅ CE
CORS Configuration ✅ CE
API Key Auth ⚠️ EE
Security Policies ⚠️ EE
Basic Auth ✅ CE
OAuth Client ✅ CE
TLS/mTLS ✅ CE

🚦 Traffic Management

Rate Limiting (endpoint) ✅ CE
Rate Limiting (backend) ✅ CE
Rate Limiting (stateful) ⚠️ EE
Circuit Breakers ✅ CE
Load Balancing ✅ CE

🔌 Connectivity

REST/HTTP ✅ CE
gRPC ✅ CE
GraphQL ✅ CE
WebSockets ⚠️ EE
SOAP ⚠️ EE
AMQP/RabbitMQ ✅ CE

🔄 Data Transformation

Response Manipulation (JMESPath) ✅ CE
Request/Response Modifiers ✅ CE
Data Aggregation ✅ CE
Lua Scripting ✅ CE

📊 Observability

OpenTelemetry ✅ CE
Prometheus Metrics ✅ CE
Logging (structured) ✅ CE
Tracing (Jaeger, Zipkin) ✅ CE
Moesif Integration ⚠️ EE

Legend: ✅ CE = Community Edition (open source, free) ⚠️ EE = Enterprise Edition (commercial)

What area interests you? I can provide detailed configuration for any feature."

Feature Combinations

Always suggest powerful combinations:

Rate Limiting → Add Circuit Breaker (reliability)
JWT Validation → Add CORS (web clients)
Multiple Backends → Add Circuit Breakers per backend
Public APIs → Add Rate Limiting + Authentication
Microservices → Add Service Discovery + Load Balancing
Production APIs → Add Observability (metrics + tracing + logging)

Integration & Error Handling

Integration with other skills

If user wants to implement feature → Hand off to config-builder skill
If user wants to validate existing feature config → Hand off to config-validator skill
If user asks about complex architecture → Consider spawning config-architect agent

Error handling

Feature doesn't exist: Search similar features, suggest alternatives
User has CE but wants EE feature: Clearly explain, offer CE alternatives
Feature is deprecated: Mention replacement, provide migration path
Multiple matches: Show all, let user choose which they meant
Documentation outdated: Use refresh_documentation_index and retry

Install Skill

SKILL.md