Agent skill · mindrally
network-troubleshooting
Systematic, safety-first diagnosis of developer network failures such as connection refused, DNS resolution errors, TLS certificate problems, proxy failures, and package registry timeouts. Use when a command fails with a network-shaped error (curl, npm, pip, git, docker), when a service is unreachable, or when the user asks to debug connectivity, DNS, TLS, or proxy issues.
What it needs
About 5k tokens when loaded.
What this skill does
Network Troubleshooting This skill provides a concise, safety-first decision guide for diagnosing developer network failures. Diagnostics must stay read-only and target-scoped — this is not an automated remediation toolkit. Safety Boundaries These boundaries apply to every step of the workflow below and must never be relaxed, even if asked: Prefer read-only diagnostics and trusted project-provided diagnostic scripts. Use the failing host, URL, registry, or service as the default probe target — do not probe unrelated hosts. Ask before probing unrelated external services. Never print proxy URLs, credentials, tokens, auth headers, package index URLs, registry hostnames from config, or raw config values in shared output. Internal hosts and URLs may be collected for target-scoped local diagnostics, but replace them with placeholders before sharing logs or reports unless the user explicitly approves including them. Never dump local configuration from npm, pnpm, yarn, pip, Git, Docker, shell, OS proxy, VPN, or certificate stores. Never disable, bypass, or skip TLS or certificate verification (no -k/--insecure, no NODETLSREJECTUNAUTHORIZED=0, no verify=False), even temporarily "just to test." Never change OS networking, DNS, proxy, package manager, Git, Docker, shell, VPN, or trust-store settings without explicit user approval for the exact action being taken. Workflow 1. Collect — Capture the exact error text, the failing command, the target host/URL/port, OS/shell, proxy/VPN context, and whether the failure affects one target or many. 2. Classify — Match the symptom against the error classification table below to form a hypothesis. 3. Diagnose — Run only read-only checks scoped to the failing target, starting with the smallest relevant check. 4. Explain — Interpret each diagnostic result in plain language before suggesting any fix. 5. Advise — Present remediation options as choices; wait for explicit user approval before changing any state. 6. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills mindrally/network-troubleshooting