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
3. Keep lines short for mobile readability (under 50 chars per line where possible).
4. Status emoji convention:
   - ✅ = good / healthy / expected
   - ⚠️ = warning / unusual / investigate
   - ❌ = critical / failed / dangerous
   - ℹ️ = informational
5. Blank line between each section.
6. 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

2. **Top Risks** (max 3 items)
   - Each: severity emoji + one-sentence why + one action
   - Skip section entirely if no risks found

3. **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`"

4. **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`
- `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):**
```javascript
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, latencyM