GitHub Issue: Proposal to Split 'network-recon' Skill Due to Context Bloat and Shallow Protocol Coverage

## Problem

`network-recon` is 903 lines and growing. It covers host discovery, port scanning, service enumeration for 22 ports, OS fingerprinting, vulnerability scanning, multi-host workflows, output parsing, and routing decisions — all in one skill.

This causes two issues:
1. **Context pressure**: Loading the full skill consumes significant context window before the actual task begins.
2. **Shallow coverage**: Each port gets 12-27 lines of 'quick win' enumeration. Protocols like SMB, SNMP, and databases have far more depth than a quick-win block can cover (authenticated enumeration, version-specific exploits, chained attacks, detailed troubleshooting).

## Proposal

Split service enumeration into dedicated skills for the protocols that warrant depth. Keep network-recon as the **scanning and routing** skill — it discovers what's open and routes to the right service skill.

### Candidate services for their own skills

| Service | Ports | Why |
|---------|-------|-----|
| **SMB** | 139, 445 | Null sessions, share enum, relay targets, signing checks, EternalBlue, PrintNightmare, SMBGhost, smbclient/netexec/enum4linux-ng deep usage, GPP passwords, SCF file attacks |
| **SNMP** | 161/162 UDP | Community string discovery, v1/v2c/v3 enumeration, OID trees for users/processes/software/interfaces, Net-SNMP Extend RCE, SNMP write abuse |
| **Redis** | 6379 | Unauth access, webshell write, SSH key injection, SLAVEOF replication, module loading, Lua sandbox escapes, Redis Sentinel/Cluster |