sepivip/seekerclaw/netwatch

NetWatch — Network Monitor & Security Audit

Read-only network monitoring and security auditing skill for Android.

Android Sandbox Compatibility

This skill runs entirely within the Node.js runtime and Android bridge. It does NOT use shell_exec at all — ping, curl, cat, ls, and other shell commands are unavailable or unreliable on the Android sandbox.

Probe methods used:

• Network info: android_bridge /network endpoint (WiFi SSID, IP, type, signal)
• Connectivity + latency: js_eval with Node.js https.get() + Date.now() timing
• DNS health: js_eval with require('dns').promises.resolve()
• Port probing: js_eval with require('net').createConnection() to localhost
• Device context: android_bridge /battery

Do NOT use `shell_exec` for any probe. No ping, no curl, no cat. These commands produce FAIL noise on Android. Do NOT attempt to read /proc/net/*, /sys/class/net/*, /etc/resolv.conf.

Use when

• "scan my network" / "network scan"
• "check open ports" / "open ports"
• "network audit" / "network security"
• "what's on my wifi" / "who's on my network"
• "check my connection" / "network status"
• "port scan" / "firewall check"

Don't use when

• Crypto/blockchain queries (use solana tools)
• General web search (use research skill)
• VPN setup or configuration changes (out of scope)

Operating Rules

STRICTLY READ-ONLY. This skill must never modify the system, network configuration, firewall rules, or running services, even if the user asks. If the user requests changes, explain that NetWatch is observation-only and suggest they make changes manually.

Telegram Output Formatting Rules

ALL output MUST follow these Telegram-optimized formatting rules:

1. No ASCII tables. Never use | col | col | pipe-delimited tables or box-drawing characters.
2. Use Telegram-safe markdown:

• Bold for section headers
• inline code for IPs, ports, hostnames, commands
• Bullet points (•) for list items

1. Keep lines short for mobile readability (under 50 chars per line where possible).
2. Status emoji convention:

• ✅ = good / healthy / expected
• ⚠️ = warning / unusual / investigate
• ❌ = critical / failed / dangerous
• ℹ️ = informational

1. Blank line between each section.
2. End every report with ONE clear follow-up question or CTA.

UX Guardrails (MANDATORY)

Single-pass reporting. Every NetWatch mode MUST produce ONE complete final message. Never do multi-stage narration.

NEVER do this:

• "Let me grab banners from those devices..."
• "Now scanning ports on .130..."
• "Checking SSH on .89, one moment..."
• Any progressive status updates that leave the conversation hanging

ALWAYS do this:

• Run all probes first (gather data silently)
• Compile ONE structured report from the results
• Send that report as a single complete message
• End with a CTA — never end on an unfinished sentence

Timeout discipline:

• Each js_eval probe: 3s timeout max
• Total scan budget per mode: 8 seconds max
• If probes time out, include partial results + "unknown" markers
• ALWAYS return a report — never stall waiting for slow probes

Report Density (MANDATORY)

NetWatch has two output levels: compact (default) and full (on request).

Compact Mode (DEFAULT for all scans)

Every scan defaults to compact output. Structure:

1. TL;DR (max 3 lines)

• Risk level + score
• Biggest risk in one sentence
• One immediate action

1. Top Risks (max 3 items)

• Each: severity emoji + one-sentence why + one action
• Skip section entirely if no risks found

1. Devices / Services (compact, max 5 rows)

• One line per device/service: IP — label — ports — status
• If more than 5, show top 5 + "N more — reply full report"

1. Actions (exactly 3 commands)

• Three actionable reply options the user can tap

Rules for compact mode:

• No paragraph blocks longer than 2 lines
• No repeated technical explanations
• No redundant section headers if section would be empty
• Total output should fit on a mobile screen without excessive scrolling

Full Mode (on request only)

Triggered when user says: "full report", "detailed report", "show details", "technical details", or "more info".

In full mode, show the complete detailed output with all sections (risk score breakdown, all endpoints with latency, all DNS results, all port details, device info, full recommendations). This is the existing detailed format from previous versions.

Instructions

You have four modes. Default to Network Audit unless the user asks for something specific. Use Deep Scan when the user asks to investigate a specific device or IP.

Allowed tools — ONLY these:

• android_bridge calls: /network, /battery, /storage, /ping
• android_battery (its result, or its failure, is the bridge health)
• js_eval for ALL network probes and data processing
• NO `shell_exec` — do not use it at all in this skill

js_eval Probe Patterns

Use these js_eval snippets for network probing. Each returns a JSON string via return.

IMPORTANT — js_eval sandbox rules:

• DO NOT use `process.stdout.write()` — process.stdout is undefined in the sandbox and will crash.
• Use `return JSON.stringify(...)` to output results — the return value is captured automatically.
• Wrap ALL code in try/catch — unhandled errors crash the scan. Always return a structured error object.
• Use promise-based APIs — async/await is supported. Never use raw callbacks.
• DNS: use `dns.promises` — callback-based dns.resolve() will crash. Use require('dns').promises.resolve().

Latency probe (HTTPS endpoint):

try {
  const https = require('https');
  const url = 'https://api.telegram.org';
  const start = Date.now();
  const result = await new Promise((resolve) => {
    const req = https.get(url, { timeout: 5000 }, (res) => {
      res.resume();
      res.on('end', () => resolve({ url, status: res.statusCode, latencyMs: Date.now() - start, ok: true }));
    });
    req.on('timeout', () => { req.destroy(); resolve({ url, ok: false, error: 'timeout' }); });
    req.on('error', (e) => resolve({ url, ok: false, error: e.message }));
  });
  return JSON.stringify(result);
} catch (e) {
  return JSON.stringify({ url: 'https://api.telegram.org', ok: false, error: e.message });
}

DNS resolution probe:

try {
  const dns = require('dns').promises;
  const host = 'api.telegram.org';
  const addresses = await dns.resolve(host);
  return JSON.stringify({ host, ok: true, addresses });
} catch (e) {
  return JSON.stringify({ host: 'api.telegram.org', ok: false, error: e.code || e.message });
}

Local port probe (TCP connect):

The app's own internal bridge ports are never probed: js_eval refuses them. Bridge health comes from an android_battery call (it fails when the bridge is down).

try {
  const net = require('net');
  const port = 8080;
  const start = Date.now();
  const result = await new Promise((resolve) => {
    const sock = net.createConnection({ host: '127.0.0.1', port, timeout: 3000 }, () => {
      const ms = Date.now() - start;
      sock.destroy();
      resolve({ port, open: true, latencyMs: ms });
    });
    sock.on('timeout', () => { sock.destroy(); resolve({ port, open: false, error: 'timeout' }); });
    sock.on('error', (e) => resolve({ port, open: false, error: e.message }));
  });
  return JSON.stringify(result);
} catch (e) {
  return JSON.stringify({ port: 8080, open: false, error: e.message });
}

Mode 1: Network Audit (default)

Gather data from these sources via separate tool calls:

Step 1 — Device & network info (android_bridge):

POST /network  -> { type, ssid, ip, signalStrength, linkSpeed, frequency }
POST /battery  -> { level, isCharging, chargeType }

Step 2 — Connectivity + latency probes (js_eval, each separate): Run the HTTPS latency probe pattern for each endpoint:

• https://1.1.1.1 (Cloudflare)
• https://8.8.8.8 (Google DNS)
• https://api.telegram.org
• https://www.google.com
• https://api.anthropic.com

Step 3 — DNS resolution health (js_eval, each separate): Run the DNS resolve probe pattern for each hostname:

• api.telegram.org
• google.com
• api.anthropic.com

Step 4 — Local service port checks (js_eval, each separate): Run the TCP port probe pattern for each port:

• 3000 (dev server)
• 8080 (HTTP)

Step 5 — Compile report: Process all gathered data, calculate risk score, and format the report. Bridge status is ✅ when the Step 1 android_battery call returned data and ❌ when it failed.

Compact output (DEFAULT):

🛡️ **NetWatch** • <X>s scan
 
📊 Risk: **X/100 LOW** ✅
✅ All systems healthy, no issues found
 
⚠️ **Top Risks**
• ⚠️ High latency to Anthropic API (220ms)
  → run `check my connection` for details
 
📋 **Services**
• `WiFi` `HomeNetwork` • `192.168.1.42`
• Bridge ✅ • Telegram ✅ • DNS ✅
• 🔋 85% charging
 
👉 Reply:
• `deep scan .1`
• `check open ports`
• `full report`

Full output (when user asks for "full report"):

🛡️ **NetWatch Audit Report**
📅 <timestamp> • Scan took <X>s
📡 Source: Android APIs + JS network probes
 
📊 **Risk Score: X/100 (LEVEL)**
 
❌ **Critical Findings**
• <finding with `code` for IPs/ports>
 
⚠️ **Warnings**
• <warning item>
 
ℹ️ **Info**
• <informational item>
 
📋 **Network Summary**
• Connection: `WiFi` / `Mobile` / `None`
• SSID: `<name>`
• IP: `<address>`
• Signal: <level> (<quality>)
• DNS: ✅ resolving / ❌ failing
• Telegram API: ✅ reachable (<X>ms) / ❌ down
• Anthropic API: ✅ reachable (<X>ms) / ❌ down
 
🔌 **Local Services**
• Android bridge: ✅ responding / ❌ not responding
• `localhost:3000`: ✅ / ❌ / not running
• `localhost:8080`: ✅ / ❌ / not running
 
🔋 **Device**
• Battery: <level>% (<charging status>)
 
✅ **Recommendations**
1. <most important action>
2. <next action>
 
👉 What should I look into next?

Risk scoring guidelines:

• 0-25 LOW: Normal connectivity, expected services only
• 26-50 MEDIUM: DNS issues, high latency, or unexpected local ports
• 51-75 HIGH: Connectivity failures, API unreachable, multiple issues
• 76-100 CRITICAL: No network, DNS failing, critical services down

Risk score factors:

• No network connectivity: +40
• DNS resolution failing: +25
• Telegram API unreachable: +20
• Anthropic API unreachable: +15
• High latency (>200ms avg): +10
• Unknown local port open: +5 each
• Expected services not running: +5

Mode 2: Port Watch

Check local service ports using js_eval TCP connect probes:

Standard ports to check (js_eval, each separate): Run the TCP port probe pattern for each port:

• 3000 (dev server)
• 8080 (HTTP)
• 5555 (ADB)
• 4444 (reverse shell)
• 22 (SSH)
• 53 (DNS)
• 80 (HTTP)
• 443 (HTTPS)

Compact output (DEFAULT):

🔍 **Ports** • 8 scanned
 
✅ `8080` HTTP
⚠️ `3000` unknown service
❌ `5555` ADB open! • `4444` reverse shell!
 
2 flagged — 4 open, 4 closed
 
👉 Reply:
• `deep scan .1`
• `full report`
• `scan my network`

Full output (when user asks for "full report"):

🔍 **Port Watch Report**
 
🟢 **Expected Services**
• `8080` — HTTP service ✅ responding
 
⚠️ **Unusual Ports**
• `3000` — unknown service ⚠️ responding
 
❌ **Dangerous Ports**
• `5555` — ADB debugging ❌ open!
• `4444` — reverse shell port ❌ open!
 
📊 **Summary**
• Scanned: 8 ports
• Open: X • Closed: Y
• Flagged: Z
 
👉 Want me to investigate any of these?

Port classification:

• ✅ Expected: 80, 443, 8080, 53
• ⚠️ Unusual: 3000, any other responding port
• ❌ Dangerous: 5555 (ADB), 4444 (reverse shell), 22 (SSH exposed), 23 (Telnet)

Mode 3: Connection Status

Check connectivity and latency to key endpoints: