api-proxy-safety

Implements layered keyword matching for gateway and WAF middleware to prevent false-positive error detection.

1.0k|109|Updated Jan 4, 2026
One-click install
npx skills add https://github.com/doccker/cc-use-exp --skill api-proxy-safety
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-proxy-safety
Source: https://github.com/doccker/cc-use-exp/tree/main/.claude/skills/api-proxy-safety
Command: npx skills add https://github.com/doccker/cc-use-exp --skill api-proxy-safety

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Gateway, proxy, WAF, and CDN middleware often use naive substring matching to detect pseudo-success error responses, which misfires when normal response bodies legitimately contain technical terms like "Cloudflare", "502", or "bad gateway", causing false site failovers and incorrect node-unavailable markings.

Core Features & Use Cases

  • Strong/Weak Pattern Splitting: Classifies keywords into strong patterns (full error sentences, HTML error page markers) that match at any length, and weak patterns (short phrases like "cloudflare", "bad gateway") that only match content under 512 bytes.
  • Layered Decision Hierarchy: Prioritizes HTTP status codes, Content-Type, and JSON error schema fields over body keyword matching, treating keywords only as heuristic evidence.
  • Scenario-Specific Strategies: Provides distinct matching rules for long chat responses, short error messages, and streaming response chunks.
  • Use Case: When implementing a Go reverse proxy that detects pseudo-success responses from upstream LLM APIs, apply this skill to avoid flagging a 4000-word blog post about Cloudflare as a gateway error.

Quick Start

Ask the AI to review your proxy middleware's keyword matching logic using the api-proxy-safety rules to eliminate false positives on long response bodies.

Frequently Asked Questions about api-proxy-safety

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I avoid false positives when matching error keywords in API proxy responses?

Split keywords into strong patterns (complete error sentences, HTML error page markers) that match at any length, and weak patterns (short terms like "cloudflare") that only match content under 512 bytes. Always check HTTP status and response schema before body keywords.

How to detect pseudo-success responses in a Go reverse proxy?

Check HTTP status codes first, then Content-Type and JSON error fields like error.code or success:false. Use body keyword matching only as heuristic evidence, applying length-based thresholds so long normal content with technical terms is not flagged.

Why does substring matching cause false errors in WAF middleware?

Substring matching treats any occurrence of a keyword as an error, but normal user content can legitimately contain terms like "Cloudflare", "502", or "bad gateway". A long article about these topics would incorrectly trigger failover or node-unavailable marking.

Should keyword matching differ for streaming versus complete responses?

Yes. Streaming chunks should be buffered until a complete block arrives or split by content format before matching. Short error messages can use full matching without length limits, while long chat bodies need the strong/weak pattern split.

What are the limitations of body keyword matching for error detection?

Body keywords are only heuristic evidence and cannot be the sole decision factor. They must be combined with HTTP status codes, Content-Type checks, and structured error schema validation to avoid misjudging legitimate content.