Cisco Ios Patterns
Review Cisco IOS or IOS-XE config snippets and run a safe change-window checklist before touching production routers or switches.
Overview
Cisco IOS Patterns is an agent skill for the Operate phase that structures safe IOS and IOS-XE config review, read-only show evidence, and change-window verification before production edits.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill cisco-ios-patternsWhat is this skill?
- Five-step safe change workflow: baseline capture, candidate review, lockout check, minimal apply, re-read and intentiona
- Read-only show-command guidance for evidence collection without worsening an incident
- ACL wildcard masks, interface direction, and hierarchy patterns for global, interface, routing, and line modes
- Explicit rule: patterns are not paste-ready production changes—confirm platform, rollback, and out-of-band access first
- 5-step preferred workflow from baseline capture through validated save
- Mode reference covering enable, configure terminal, and interface submodes
Adoption & trust: 1.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a Cisco change or outage snippet but no repeatable way to collect baseline state, check ACLs and interfaces, and verify the change without locking yourself out.
Who is it for?
Indie operators or fractional network folks reviewing IOS snippets, drafting maintenance checklists, or tutoring an agent through read-only troubleshooting commands.
Skip if: Teams that need automated config push, Terraform-first network IaC, or paste-ready production templates without human platform confirmation.
When should I use this skill?
Reviewing IOS or IOS-XE configuration before a planned change, choosing read-only show commands, or verifying that a change landed in running config.
What do I get? / Deliverables
You get a ordered baseline-capture and validation workflow plus pattern-level checks so the smallest safe change can be reviewed and confirmed in running config before save.
- Change-window checklist aligned to baseline capture and post-change verification
- Review notes on ACL placement, wildcard masks, and interface hygiene for the candidate config
Recommended Skills
Journey fit
Network change control and post-change verification belong on the Operate shelf because they assume live infrastructure, not greenfield product build. Infra is the canonical subphase for router/switch config review, ACL placement, and saving running-config after maintenance windows.
How it compares
Use for human-in-the-loop IOS review checklists instead of treating raw LLM config output as production-ready.
Common Questions / FAQ
Who is cisco-ios-patterns for?
Solo builders and small teams who occasionally manage Cisco IOS or IOS-XE routers and switches and want agent-assisted review before change windows or during incidents.
When should I use cisco-ios-patterns?
Use it in Operate (infra) when reviewing candidate IOS config, choosing read-only show commands, checking ACL masks and interface direction, or verifying a change after a maintenance window—not when designing unrelated app features.
Is cisco-ios-patterns safe to install?
It is procedural guidance only; review the Security Audits panel on this page and never let an agent apply config on a live device without your rollback path and out-of-band access confirmed.
SKILL.md
READMESKILL.md - Cisco Ios Patterns
# Cisco IOS Patterns Use this skill when reviewing Cisco IOS or IOS-XE snippets, building a change-window checklist, or explaining how to collect evidence from a router or switch without making the incident worse. ## When to Use - Reviewing IOS or IOS-XE configuration before a planned change. - Choosing read-only `show` commands for troubleshooting. - Checking ACL wildcard masks and interface direction. - Explaining global, interface, routing process, and line configuration modes. - Verifying that a change landed in running config and was saved intentionally. ## Operating Rules Treat IOS examples as patterns, not paste-ready production changes. Confirm the platform, interface names, current config, rollback path, and out-of-band access before making changes on a real device. Prefer this workflow: 1. Capture current state with read-only commands. 2. Review the exact candidate config. 3. Confirm management access cannot be locked out. 4. Apply the smallest change in a maintenance window. 5. Re-read state, compare to the baseline, then save only after validation. ## Mode Reference ```text Router> enable Router# show running-config Router# configure terminal Router(config)# interface GigabitEthernet0/1 Router(config-if)# description UPLINK-TO-CORE Router(config-if)# no shutdown Router(config-if)# exit Router(config)# end Router# show running-config interface GigabitEthernet0/1 ``` `running-config` is active memory. `startup-config` is what survives reload. Do not save a change just because a command was accepted; validate behavior first, then use `copy running-config startup-config` if the change is approved. ## Read-Only Collection ```text show version show inventory show processes cpu sorted show memory statistics show logging show running-config | section line vty show running-config | section interface show running-config | section router bgp show ip interface brief show interfaces show interfaces status show vlan brief show mac address-table show spanning-tree show ip route show ip protocols show ip access-lists show route-map show ip prefix-list ``` Collect the specific section you need instead of dumping full config into a ticket when the config may contain secrets, customer names, or private topology. ## Wildcard Masks IOS ACL and many routing statements use wildcard masks, not subnet masks. ```text Subnet mask Wildcard mask 255.255.255.255 0.0.0.0 255.255.255.252 0.0.0.3 255.255.255.0 0.0.0.255 255.255.0.0 0.0.255.255 ``` Review wildcard masks before deployment. A subnet mask accidentally used as a wildcard can match far more traffic than intended. ```text ip access-list extended WEB-IN 10 permit tcp 192.0.2.0 0.0.0.255 any eq 443 999 deny ip any any log ``` Every ACL has an implicit deny at the end. Add an explicit logged deny when the operational goal includes observing misses, and confirm logging volume is safe. ## ACL Placement Review Before applying an ACL to an interface, answer these questions: - Which traffic direction is being filtered, `in` or `out`? - Is management traffic sourced from a known jump host or management subnet? - Is there an explicit permit for required routing, DNS, NTP, monitoring, or application traffic? - Are hit counters available from a safe test source? - Is there a rollback command and an active console or out-of-band path? Do not test reachability by removing firewall or ACL protections. Read counters, logs, and route state first. ## Interface Hygiene ```text interface GigabitEthernet0/1 description UPLINK-TO-CORE switchport mode trunk switchport trunk allowed vlan 10,20,30 switchport trunk native vlan 999 no shutdown ``` Use clear descriptions, explicit switchport mode, and documented native VLANs. On routed i