# Networking Ops Edho Ferdian > >- - **Type:** Skill - **Install:** `agentstack add skill-edhoferdian-eef-networking-ops-edho-ferdian` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [edhoferdian](https://agentstack.voostack.com/s/edhoferdian) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** https://github.com/edhoferdian/EEF/tree/main/.agents/skills/networking-ops-edho-ferdian ## Install ```sh agentstack add skill-edhoferdian-eef-networking-ops-edho-ferdian ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Networking Ops — Edho Ferdian Mode ## Provenance This skill consolidates what used to be several separate, narrower capabilities — config review, network design (homelab and enterprise/multi-site), read-only troubleshooting, and device operations/automation — into one skill (the same consolidation pattern used by `language-code-review-edho-ferdian` for the language-reviewer family), building real substance where real substance existed in the source material rather than leaving thin pass-through routing between pieces. The device-operations and homelab-build-out material folds in coverage for Cisco IOS command patterns, Netmiko-based SSH automation, config validation, interface/BGP diagnostics, homelab network setup and readiness, VLAN segmentation, WireGuard remote access, and Pi-hole/local DNS. Most of that material carried over in full. Two areas were folded only partially: the VLAN-segmentation and Pi-hole/local-DNS material each originally included a vendor-UI / product-specific walkthrough section (UniFi controller screens, Pi-hole's web admin clickpath) that was dropped — this skill can't verify a specific product's current UI and shouldn't fake having tested it. The underlying concepts (segmentation boundaries, DNS-sinkhole architecture, upstream/conditional-forwarding design) were kept and generalized. ## Honest scope statement — read this first **Coverage is real but has a specific shape, not a universal one.** Device-command syntax, change-window discipline, automation scripting, and diagnostic command output in this skill are Cisco IOS/IOS-XE flavoured — that's what the source material (`cisco-ios-patterns`, `netmiko-ssh-automation`, the BGP/interface diagnostics sources) actually covers in concrete syntax. Other vendors (Juniper Junos, Arista EOS, MikroTik RouterOS) get the underlying concepts — what a change window is for, why preflight validation matters, how to read interface/BGP state in general — but not their native command syntax. Translate the concept, don't assume the Cisco command works verbatim elsewhere. **Covered conceptually, with an explicit accuracy caveat:** where VLAN segmentation, DNS/DHCP integration (including Pi-hole), and firewall rule/policy configuration conceptually live in UniFi, pfSense/OPNsense, and MikroTik (WinBox/WebFig) — see `references/vendor-gui-concepts.md`. That file deliberately does not claim exact, current click-paths or menu labels (those go stale with firmware/software updates and cannot be verified without the hardware in hand); it documents the stable conceptual location and naming of each setting instead, with a prominent caveat on every section to verify against the actual installed version before executing. ## Mode detection Pick the mode from what the user is actually asking for. State which mode you're in before loading the reference file, the same way `language-code-review-edho-ferdian` states which stack lens it loaded. | Signal | Mode | Load | | --- | --- | --- | | User pastes an existing config, or a proposed change snippet, and wants it reviewed/audited/checked before a push | **Config review** | `references/config-review.md` | | User wants to design a new network, re-segment an existing one, plan VLANs/redundancy/topology, homelab or enterprise/multi-site | **Design** | `references/design-principles.md` | | User describes a live symptom — can't connect, DNS fails, slow, BGP flapping, VLAN unreachable — and wants a root cause | **Troubleshooting** | `references/troubleshooting-methodology.md` | | User wants to run, script, or push a device command/change — SSH into a device, automate a change across multiple devices, needs a maintenance-window plan for a live push | **Device operations / automation** | `references/device-command-and-change-window.md` + `references/automation-and-preflight.md` | | User is building or expanding a homelab or small network — remote access setup, local DNS, readiness check before buying/racking gear | **Homelab / small-network build** | `references/homelab-planning.md` + `references/remote-access-and-local-dns.md` | If the request spans more than one mode (e.g. "diagnose why this failed, then fix the config"), run them in sequence: troubleshooting first to find the root cause, then config-review on the proposed fix before it ships. Never skip config-review on a fix just because troubleshooting already found the cause — a fix is a config change and gets reviewed like one. Likewise, "automate this change across 40 switches via SSH" is not an edge case — it's the device operations/automation mode above: load `device-command-and-change-window.md` for the change-window discipline and `automation-and-preflight.md` for the scripting and validation approach. If a request still doesn't clearly match any of the five modes, say so plainly rather than forcing a best-effort fit into the closest one. ## Shared safety rules (all five modes) These are consistent across all modes of this skill and apply regardless of which reference file is active: - **Never recommend removing an ACL, firewall rule, or auth control as a troubleshooting or testing shortcut.** This isn't mode-specific — it's a hard rule. - **Never present a config change as a diagnostic step.** If a command changes device state, label it a proposed fix requiring a maintenance window, backup, and rollback plan — not something to run "just to see." This is a hard blocker in `config-review.md`'s severity ladder for destructive commands with no rollback context. - **Read-only by default.** Config review, design, and troubleshooting are planning/review/diagnosis and never apply configuration directly. Device operations/automation is the only mode that can touch live device state, and only behind the explicit-flag rule below. - **Don't recommend exposing a management interface to the internet**, in any mode — design, review, or troubleshooting. - **Automation defaults to read-only**; a config-changing code path requires an explicit operator flag, and persisting to startup config is always a separate, later, approved step. ## Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract) Communication to the user in Bahasa Indonesia; device configs, commands, and scripts in English — fixed, never ask. Full contract: `skill-authoring-edho-ferdian` §7. ## Reference files | File | Mode | | --- | --- | | `references/config-review.md` | Config review — the most self-contained source, ported with the most depth (full severity ladder, output format, verdict rule) | | `references/design-principles.md` | Design — homelab and enterprise/multi-site registers, segmentation/VLAN principles, redundancy basics | | `references/troubleshooting-methodology.md` | Troubleshooting — OSI layer-by-layer methodology (L1/2 → L3 → DNS → policy), generalizes even without device-specific command syntax | | `references/device-command-and-change-window.md` | Device operations — Cisco IOS/IOS-XE command discipline, maintenance-window planning, backup/rollback requirements before any state-changing command | | `references/interface-and-bgp-diagnostics.md` | Troubleshooting / device operations — reading interface counters and BGP neighbor/route state to ground a diagnosis in real device output | | `references/automation-and-preflight.md` | Device operations — Netmiko-driven SSH automation patterns and the preflight validation checks that must pass before any scripted change runs | | `references/homelab-planning.md` | Homelab build — small-network planning and hardware/readiness assessment before buying or racking gear | | `references/remote-access-and-local-dns.md` | Homelab build — WireGuard-style remote access design and local DNS (sinkhole/conditional-forwarding) architecture, vendor-UI-agnostic | | `references/vendor-gui-concepts.md` | Homelab build — where VLAN, DNS/DHCP, and firewall configuration conceptually live in UniFi, pfSense/OPNsense, and MikroTik, with a prominent staleness caveat on every section | ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** [edhoferdian/EEF](https://github.com/edhoferdian/EEF) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-edhoferdian-eef-networking-ops-edho-ferdian - Seller: https://agentstack.voostack.com/s/edhoferdian - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.