Diagnose intermittent Wi-Fi buffering, lag, packet loss, jitter, weak coverage, interference, roaming or MLO compatibility, and congestion; safely optimize authorized router settings when evidence supports a change. Use for read-only Wi-Fi diagnosis, router inspection, separating wireless trouble from client, application, WAN, or ISP problems, reversible stability tuning, verification, or rollback. Route ambiguous requests to diagnosis and require current evidence, authorization, and rollback values before optimization. Never use on a network the user is not authorized to administer.
d3a53c1Separate read-only diagnosis from authorized optimization. Route the request before acting and load only the reference needed for the selected function.
State the active function before starting. For an optimization request without current evidence, state Function: Diagnosis (prerequisite for requested optimization), then state Function: Optimization only when the prerequisites are satisfied. Otherwise state Function: Diagnosis or Function: Optimization directly.
Use direct control when the agent has local-network access and a browser-control surface. Prefer a trusted router API or management tool when available; otherwise use the visible administration UI. Ask the user to sign in themselves.
Use guided control when direct access or browser control is unavailable. Request only non-secret values and keep proposed actions reversible. Lack of authorization always prevents setting changes in either control mode.
Read and follow references/diagnosis-guide.md completely. Do not load the optimization guide for a diagnosis-only request.
When Python and basic network tools are available, use scripts/network_probe.py for the sanitized baseline. Pass --gateway if automatic detection fails. Prefer its bundled public HTTPS endpoints and never pass credentials or secret URL components. Treat output as evidence, not permission to change anything.
End with the likely problem layer, confidence, supporting and contradicting evidence, and the smallest next test. Explicitly state that no settings were changed.
If equivalent current evidence does not exist, state the prerequisite Diagnosis function and follow references/diagnosis-guide.md first. After reporting that evidence, announce the transition, then read and follow references/optimization-guide.md completely.
Do not optimize Wi-Fi settings when the evidence points to an application, CDN, client, WAN, or ISP problem. Keep only a change that materially improves the target symptom without an unacceptable regression; otherwise restore the recorded value before another test.
End with the exact values changed, values intentionally left unchanged, before/after evidence, tradeoffs, rollback values, and the next diagnostic layer if the symptom returns.
Never include credentials, device identifiers, serial numbers, session URLs, or full IP addresses in either report.
Copy a source-pinned command for your client. You run it yourself.
Destination: .claude/skills/wifi-optimizer · pinned to the source commit
git clone https://github.com/iAmCorey/wifi-optimizer.git
cd wifi-optimizer
git checkout d3a53c1d5059a4aa40efa564e38f6f785a87d676
mkdir -p ".claude/skills/wifi-optimizer"
cp -r . ".claude/skills/wifi-optimizer"Review the source before running. This copies files into your project; it is not a one-click install and does not verify runtime safety.
Scanner static-checks@0.1.0 · commit d3a53c1d5059. Static checks cannot prove runtime safety – review the source and the exact diff before installing. How checks work.
References credentials, tokens or secret files that a skill should not need.
Evidence: [redacted]· fingerprint 5e884898da280471