| name | plan-network-change |
| description | Turn a network change (routing/VLAN/firewall/cutover) into a staged, reversible plan — blast-radius assessment, change window, pre-checks (baseline), the staged steps with verification gates, and a tested rollback — so no change is a big-bang gamble. Reach for this when the user needs to make a risky network change safely or migrate/cut over network infrastructure. Used by `network-operations-engineer` and `network-architect`. |
Skill: plan-network-change
Invoked by: network-operations-engineer (primary) and network-architect (handing a design to implementation).
When to invoke: "we need to change <routing config / VLAN / firewall> safely"; "migrate/cut over "; any change to a running network.
Output: a windowed, reversible change plan. No big-bang cutovers.
Procedure
- Assess the blast radius. What does this touch, who depends on it, what is the worst case if it goes wrong? A core-routing change ≠ adding an access VLAN. Size the change-control rigor to the blast radius.
- Capture a pre-change baseline. The state you must be able to return to and compare against: routing table snapshot, interface/neighbor status, reachability tests, config backup. You can't verify success or roll back cleanly without it.
- Pick a change window appropriate to the blast radius and the business — and notify dependents. Risky changes happen in a maintenance window, not at 2pm on a Tuesday.
- Stage the steps so each is verifiable and the system is in a known state between steps:
- Prefer expand/contract and parallel-run over cutover where possible (add the new path, shift traffic, then remove the old) — the network analog of a safe migration.
- Insert verification gates between steps: "confirm neighbor up / route present / reachability holds" before proceeding.
- Write the rollback and test it mentally step-by-step. For each forward step, the reverse. A rollback you haven't thought through is not a rollback. Include the trigger ("if reachability test fails at gate 2, execute rollback").
- Define success and post-checks — re-run the baseline tests; compare to pre-change. Only then declare done.
- Capture the diff and the why — an undocumented change is an un-diagnosable future outage.
House guardrails
- No change without a tested rollback — this is the non-negotiable.
- Baseline before you touch anything — you can't prove success against a state you never recorded.
- Verification gates between steps beat a single end-of-change check — they localize a failure to the step that caused it.
- Codify the final state in IaC where the environment supports it → route to
terraform-iac so the change is repeatable and reviewable.
- Out-of-band access before a routing/firewall change — don't change the thing you're connected through without a console/OOB path back in.
Output contract
Change: <what + why>
Blast radius: <scope + worst case> -> change-control rigor: <level>
Baseline / pre-checks: <snapshots + tests to capture first>
Window: <when + who is notified>
Steps: <staged, each with a verification gate; expand/contract where possible>
Rollback: <reverse of each step + the trigger condition>
Post-checks: <success definition = baseline re-run + compare>
Record: <diff + rationale captured where>
Then emit the Structured Output Protocol JSON block.
