feat(agentic): Add Claude skills for local dev and testing

[rgildein]

Add 3 skills for local dev and testing:

1. netop-check: run lint, unit and gnmic tests with summary output
   • capable to reformat code if needed
2. netop-setup: configure VM with all tools, k8s cluster and Nokia device with summary output
   • using colima to create VM, but can use another tools like multipass, ...
   • can be run without creating VM, for direct use on Linux machine
   • can omit creating device in containerlab if user provided connection to existing one
3. netop-test: to run manual test
   • deploy custom CRDs and verify that configuration was properly set via gnmic

These three Claude Code skills provide a guided, repeatable developer workflow for testing the network-operator against real or simulated network devices — without needing to memorise the full toolchain commands.

Example usage:

❯ /netop-setup cisco device accessible on 127.0.0.1:57400 with user admin and password admin
...
⏺ Step 4: Check Cisco device reachability from VM — 127.0.0.1 inside the VM points to the VM itself, not the Mac host. Need the host gateway IP.

⏺ Bash(colima exec -p network-operator -- bash -c "
      HOST_IP=\$(ip route | awk '/default/ {print \$3}')…)
  ⎿  Mac host IP from VM: 192.168.5.2
     192.168.64.1
     bash: line 4: nc: command not found
     device NOT reachable

⏺ Bash(colima exec -p network-operator -- bash -c "
      HOST_IP=\$(ip route | awk '/default/ {print \$3; exit}')…)
  ⎿  Mac host IP from VM: 192.168.5.2
     debconf: delaying package configuration, since apt-utils is not installed
     Selecting previously unselected package netcat-openbsd.
     … +12 lines (ctrl+o to expand)

⏺ All done. Here's the summary:

  - Colima VM network-operator — arm64, 4 CPU, 8 GB, 60 GB, running
  - Kind cluster network-operator — Kubernetes v1.36.1, node Ready
  - cert-manager v1.18.2 — all deployments available
  - Cisco device — reachable from VM at 192.168.5.2:57400 (Mac host IP as seen from VM — use this instead of 127.0.0.1)

  Next step: run /netop-test with GNMI_TARGET=192.168.5.2:57400.

[adamtrizuljak-sap]

Please add Tilt according to https://docs.tilt.dev/install.html

Suggested change

	which gnmic || bash -c "$(curl -sL https://get-gnmic.openconfig.net)"
	which gnmic || bash -c "$(curl -sL https://get-gnmic.openconfig.net)"
	curl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash

[felix-kaestner]

Some/most of these checks are already part of the AGENTS.md in

network-operator/AGENTS.md

Lines 37 to 51 in c5f5b87

	**After editing any `*.go` files:**
	```bash
	make fmt # Format code
	make lint # Lint code style
	make test # Run unit tests (uses envtest: real K8s API + etcd)
	```
	Tests use **Ginkgo + Gomega** (BDD style) for controller and webhook tests — check `suite_test.go` in each package for setup.
	All other packages use the **standard library `testing` package** with table-driven tests where appropriate.
	- Keep test files focused — only necessary cases, no exhaustive permutations
	- Test helpers stay in the same file as their tests
	**All of `make fmt lint test` must pass before work is considered complete.**

Shall we maybe extend the AGENTS.md to also contain reference to the gnmi tests?

[felix-kaestner]

I'm quite hesitant to recommend a VM-based setup for development. Our current development setup is based on Tilt in https://github.com/ironcore-dev/network-operator/blob/main/Tiltfile and I would rather leave it up to the contributor on where/how to run this. Not everyone is on Mac, so people might just run containerlab locally or through their preferred means.

[felix-kaestner]

All of this is done through make tilt-up automatically.

[felix-kaestner]

Again, isn't this the Development Workflow already described in the AGENTS.md?

network-operator/AGENTS.md

Lines 59 to 78 in c5f5b87

	## Development Workflow
	Always run against a dedicated development cluster (e.g. Kind, minikube), never a real dev/prod cluster. Always pass `--context` explicitly to kubectl commands.
	```bash
	# Build the controller image
	make docker-build IMG=controller:latest
	# Make the image available to the cluster (if using kind)
	kind load docker-image controller:latest --name network-operator
	# Deploy the controller
	make deploy IMG=controller:latest KUBECTL="kubectl --context <context>"
	# Apply sample resources
	kubectl --context <context> apply -f config/samples/<resource>
	# Inspect controller logs
	kubectl --context <context> logs -n network-operator-system deployment/network-operator-controller-manager -c manager -f
	```

[felix-kaestner]

Should we rather target the universal .agents patterns (while symlinking for claude code compatability)?