[NEW] breakdown-connectivity

Preliminary checks

• I have read the Code of Conduct.
• I have read docs/authoring.md.
• I reviewed docs/plugins.md and did not find a duplicate connectivity-diagnostics component.
• This proposal is for legitimate, constructive use cases only.
• I have domain expertise through maintaining Breakdown and its agent integration.

Component type

New plugin (external git-subdir candidate, or a local marketplace plugin if preferred)

Proposed name

breakdown-connectivity

Domain and expertise

Evidence-first macOS network and application-connectivity diagnostics. The component would help agents distinguish local Wi-Fi/Ethernet, DNS, Internet-path, and app/service failures using current and historical evidence from Breakdown.

Unique value

The marketplace has incident-response and infrastructure components, but no component dedicated to endpoint connectivity evidence. This fills the gap between a user reporting “the API/MCP/video call is failing” and an agent deciding whether to retry, change local configuration, escalate to an ISP, or investigate the service.

Primary use cases

1. Diagnose packet loss, DNS failures, intermittent Wi-Fi, API timeouts, and MCP connection failures.
2. Correlate current symptoms with retained network events and timestamps.
3. Produce a concise fault-domain assessment without overclaiming blame.

Portability

The instructional workflow is portable across Claude Code, Codex, Cursor, OpenCode, Antigravity, and Copilot. When Breakdown’s local MCP tools are available, the skill uses them; otherwise it provides explicit setup/status steps and stops rather than fabricating evidence. Breakdown itself currently requires macOS 13+.

Example interactions

• “My MCP server keeps disconnecting. Is this local Wi-Fi, DNS, or the service?” → collect a compact health snapshot, inspect relevant retained events, and localize the likely failing segment.
• “The API timed out around 14:32.” → correlate the requested time window with loss, route, DNS, and app/service evidence before suggesting remediation.
• “Zoom was choppy although speed tests looked fine.” → inspect short loss/jitter events and explain the evidence and uncertainty.

Ownership and external-service disclosure

I represent PeaceCraft, which publishes Breakdown and maintains https://github.com/PeaceCraft-LLC/breakdown-agent-connectivity. Breakdown is a signed local macOS app with a local MCP bridge; the diagnostic data path is local, and standard use is free. The proposed skill would disclose this relationship and all privileged surfaces (.mcp.json, setup helper, and local bridge). It would not contain payment, entitlement, affiliate, or metered-API machinery.

Because CONTRIBUTING requires an issue before a new component and sets a higher bar for vendor/external plugins, I am opening this proposal before a PR. Please advise whether maintainers prefer (a) a reviewed external git-subdir catalog entry or (b) a local portable skill/plugin contribution.