leaky-creds_skill

Overview

This skill helps you debug API calls by collecting and displaying request and response details in a clear, actionable format. It highlights headers, status codes, payloads, and timings while applying safe handling for secrets. Use it to quickly identify misconfigured requests, authentication problems, and unexpected responses.

How this skill works

The skill inspects outgoing HTTP requests and incoming responses to produce a structured debug report: method, URL, status code, headers, body, and latency. Sensitive header values and environment secrets are redacted by default, and the report includes guidance for reproducing the request locally. For authentication errors it suggests safe checks to validate credentials without exposing secrets in logs.

When to use it

• When an API call returns unexpected status codes (4xx or 5xx) and you need full context.
• When troubleshooting authentication or permission issues with external services.
• During development to verify request structure, headers, and payload encoding.
• When investigating intermittent failures and you need timing and retry context.
• When onboarding to a new API and you want a reproducible request example.

Best practices

• Always redact or mask sensitive values (Authorization, API keys, tokens) in shared logs and reports.
• Log only what is necessary: include headers and bodies but replace secret substrings with placeholders.
• Show exact header names and header presence so developers can copy the structure and re-insert secrets locally.
• Provide a sanitized curl or httpie example that developers can run after injecting their secrets locally.
• Rotate keys and avoid committing secrets to code or public archives; store them in environment variables or a secrets manager.

Example use cases

• A 401 Unauthorized response: show request headers (Authorization masked), request path, and suggested local checks to validate the key.
• A 400 Bad Request: display request body and schema hints to locate malformed JSON or missing fields.
• A slow response: include timing breakdown (DNS, connect, TLS, server time) to pinpoint network vs server latency.
• An intermittent 5xx: collect repeated request/response pairs and differences to help identify rate limits or payload triggers.
• Integration testing: produce sanitized request logs for CI artifacts so failures are reproducible without leaking secrets.