cc-api-proxy-safety

Validates gateway and proxy response classification to prevent keyword-based false positives.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Proxy, gateway, WAF, and CDN middleware often misclassify normal long response bodies as upstream errors because they contain technical terms like Cloudflare, 502, bad gateway, or error. This Skill defines a safe decision hierarchy so response classification relies on HTTP status, headers, and business payload structure instead of naive keyword matching.

Core Features & Use Cases

  • Prioritized Decision Hierarchy: Classify responses by transport/HTTP status first, then headers and content type, then business JSON envelope, and only lastly body heuristics.
  • Strong vs Weak Signal Split: Treat brand words (cloudflare, nginx, openresty) and short phrases (bad gateway, error) as weak evidence usable only on short bodies (<= 512 bytes) or alongside error statuses.
  • Go Decision Template: Provides a reference isUpstreamFailure implementation plus a regression test matrix covering long bodies, short error pages, valid JSON with weak keywords, and streaming chunks.
  • Use Case: When reviewing a reverse proxy that flags any body containing "bad gateway" as an upstream failure, apply this Skill to rewrite the check so technical articles and model outputs are no longer misclassified.

Quick Start

Use the cc-api-proxy-safety skill to review my gateway response-matching logic and check whether it misjudges normal response bodies containing CDN or error keywords.

Frequently Asked Questions about cc-api-proxy-safety

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

FAQPage Schema
How do I detect upstream errors in a reverse proxy without false positives?

Check HTTP status codes and response headers first, then parse the business JSON envelope for structured error fields. Only use body keywords as weak evidence when the body is short (<= 512 bytes) and lacks a valid business payload structure.

Why does my gateway flag normal responses containing Cloudflare or 502 as errors?

This happens when classification relies on strings.Contains over the full body for terms like cloudflare, bad gateway, or error. Long technical articles, logs, or model outputs naturally contain these words, so keyword-only matching produces false positives.

What counts as strong versus weak evidence of an upstream failure?

Strong evidence combines a 502/503/504/429 status with an error page or structured error envelope. Weak evidence includes brand words like nginx or openresty and short phrases like bad gateway, which only count alongside error statuses or on very short bodies.

How should streaming responses be classified for gateway errors?

Wait for a complete event, a full JSON chunk, or an explicit error event before deciding. A partial streaming chunk that happens to contain a keyword must not trigger an immediate upstream-failure verdict.

What regression tests should proxy error detection include?

Cover long bodies containing Cloudflare or 502 terms without misjudgment, short 502-only bodies judged as errors, status 200 with valid JSON containing weak keywords not flagged, 502 HTML error pages flagged, and partial streaming chunks not judged prematurely.