Dashboard Data Visualization

Use this skill when a Dashboard widget needs charts, metrics, service health, trends, logs, gauges, timelines, counters, or operational summaries. Pair it with dashboard-widget-builder for implementation and dashboard-widget-designer for broader visual polish.

Visualization Workflow

1. Identify the user's question before choosing a chart: current value, trend, comparison, distribution, threshold, incident, or history.
2. Choose the simplest representation that answers that question inside the widget's available size.
3. Preserve source units, timestamps, and uncertainty. Do not invent precision.
4. Prefer glanceable summaries with drill-down details only when the widget has room.
5. Include empty, loading, error, stale, and partial-data states for live or external data.

Chart Selection

• Single important value: metric tile with unit, trend delta, and freshness.
• Status across resources: compact status list with severity chips and counts.
• Short time trend: sparkline or mini area chart with clear last value.
• Threshold monitoring: gauge, progress bar, or banded meter with explicit threshold labels.
• Event sequence: timeline or log strip with severity and timestamp.
• Comparison across a few items: horizontal bars, not tiny pies.
• Dense logs: latest-events list with filtering or grouping, not a chart.

Avoid charts that look impressive but do not answer the user question.

Operational Semantics

• Use consistent severity order: healthy, info, warning, critical, unknown.
• Make unknown or stale data visually distinct from healthy data.
• Show last updated time for live data.
• Label units directly near numbers.
• Do not hide failed fetches behind optimistic green status.
• Do not show fake sample data unless the user explicitly asked for a mock.

Color and Encoding

• Color must reinforce meaning, not carry it alone.
• Use shape, label, icon, position, or text alongside color for health states.
• Avoid rainbow palettes for operational dashboards.
• Reserve red/orange for real warnings and failures.
• Use neutral tones for background gridlines and non-critical context.

Scale and Integrity

• Do not truncate axes in a way that exaggerates small differences unless the label makes the scale obvious.
• For sparklines without axes, label the current value and the time window.
• Keep moving averages, smoothing, or derived scores explicit.
• If data is missing, show missing rather than drawing a continuous line through it.
• Prefer exact numbers for small counts and rounded values for noisy telemetry.

KKTerm Widget Constraints

• Keep charts compact and legible at Dashboard widget sizes.
• Prefer SVG or canvas drawn from the widget viewport.
• Recompute dimensions on resize.
• Stop animation loops when a chart is static or when the widget no longer needs live rendering.
• Use curated local libraries only when their documented globals are actually needed.

Dashboard Widget Builder

Use this skill when the user asks the AI Assistant to create, modify, fix, or improve a Dashboard widget or view.

Workflow

1. Treat the active Dashboard view as the target unless the user names a different view.
2. Use Dashboard tools instead of describing manual edits when tool access is available.
3. For new user-visible widgets, create a script widget directly with the dashboard widget creation workflow.
4. For broken widgets, load current Dashboard state first, inspect the existing AI Created Widget source, then patch the smallest necessary body fields.
5. Use real data when the user asks for live, current, or external information. Do not ship fake sample data unless the user explicitly asks for a mock.
6. If a widget needs an API key or token, define a secret settings field and request secret entry. Never ask for plaintext secrets in chat.
7. Keep widgets compact, readable, and object-like: meters, clocks, charts, maps, launchers, calculators, consoles, timelines, or focused tools.
8. Use KKTerm widget classes and runtime helpers before inventing a custom UI framework.
9. For canvases and visual libraries, size from the widget viewport and handle resize.

Visual Defaults

• Prefer dense but calm desktop utility over marketing composition.
• Avoid text-only widgets unless the user asked for text output.
• Choose a non-default accent when it clarifies meaning.
• Avoid inner scrollbars in the initial layout.
• Use loading, error, empty, and refresh states when data can fail or change.

KKTerm Boundaries

• All AI Created Widgets are script widgets.
• Runtime CDN scripts are blocked; use curated local libraries when available.
• Secret values are stored outside SQLite.
• Generated widgets must fit inside their assigned Dashboard grid bounds.

File I/O

Use these KK bridge methods for any widget that reads or writes local files:

• Drag-and-drop from Explorer: KK.onFileDrop(target, callback, options?) — attach to a drop-zone element. Callback receives (items, event) where each item is { kind, name, path, bytes?, children? }. Returns a cleanup function. Add a visual hoverClass via options.hoverClass (default 'is-drop-target').
• File picker (read): KK.readLocalFile({ filters? }) — opens a native open dialog; resolves to { name, bytes, path } or null on cancel.
• File picker (save): KK.saveFile(filename, bytes, filters?) — opens a native save dialog and writes bytes; resolves to the saved path or null on cancel.

Do not use raw dragover/drop DOM events for OS file drops — always go through KK.onFileDrop so the widget code follows the established bridge pattern.

Dashboard Widget Designer

Use this skill when the user asks for a better-looking, more usable, or more polished Dashboard AI Created Widget or Dashboard view. Pair it with dashboard-widget-builder when code must be created or patched.

This skill adapts open-design-style practice for KKTerm: choose a clear artifact role, apply a small design system consistently, critique the result before delivery, and keep the artifact runnable inside its sandbox.

Design Workflow

1. Identify the widget's job: monitor, launcher, calculator, timeline, command helper, map, chart, status panel, game, or focused utility.
2. Define a compact visual direction before writing or changing code: calm utility, dense operations, high-contrast alert, soft desktop object, or playful canvas.
3. Preserve the user's requested content and behavior. Redesign presentation before inventing new features.
4. Prefer one strong hierarchy: primary metric or action, secondary details, then tertiary metadata.
5. Treat the Dashboard grid size as a hard constraint. Design for the current widget bounds first, then make it resilient to resize.
6. Critique the widget before finalizing: scan for cramped spacing, unclear status color, unreadable text, competing focal points, missing states, and unnecessary chrome.

KKTerm Visual Language

• Prefer desktop utility over marketing-page composition.
• Use compact cards, meters, status chips, timelines, small controls, and object-like surfaces.
• Keep the host widget frame visible; do not duplicate the app's outer card chrome inside the widget.
• Use the widget accent only when it helps meaning or grouping.
• Keep decorative effects subtle. Avoid heavy glassmorphism, oversized hero sections, excessive gradients, and animated clutter.
• Use system-ish type sizing: clear labels, readable values, short captions, and no tiny critical text.
• Keep icons functional. If an icon does not clarify status, action, or category, omit it.

Layout Rules

• Start with a single-column layout for small widgets and a two-zone layout only when there is enough room.
• Keep controls close to the content they affect.
• Put refresh, configure, or secondary actions in a quiet top or bottom utility row.
• Avoid inner scrollbars in the default state. If overflow is unavoidable, make the scroll area intentional and label what it contains.
• Use fluid sizing from the widget viewport. Avoid fixed desktop-sized canvases or hardcoded full-page dimensions.
• Do not rely on browser page background; the widget is rendered inside KKTerm's Dashboard surface.

State Design

Every data-driven widget should have clear states:

• Loading: short, low-noise progress text or skeleton shape.
• Empty: explain what is missing and what action would populate it.
• Error: show the user-facing failure and a safe retry path.
• Stale: show last updated time when data can become old.
• Success: make the primary result visible without requiring reading every detail.

Redesign Heuristics

When improving an existing widget:

1. Keep the current data model and bridge calls unless the user asked for behavior changes.
2. Remove visual noise before adding new elements.
3. Consolidate duplicate labels and repeated timestamps.
4. Make the most important value readable at a glance.
5. Normalize spacing, border radius, and color use across repeated rows.
6. Preserve non-English text exactly.
7. Patch only the smallest source area needed.

Handoff Checklist

Before creating or updating a widget, verify:

• It fits the assigned Dashboard grid bounds.
• It has a readable hierarchy at small sizes.
• Loading, empty, error, and stale states are present when relevant.
• Color is not the only status cue.
• Animation is bounded and can stop when not needed.
• The code stays script-widget compatible and does not import runtime CDN assets.

Desktop Accessibility UI

Use this skill when creating or reviewing KKTerm UI, especially Dashboard widgets, dialogs, controls, status panels, and dense desktop utility surfaces. Pair it with widget skills when the request includes visual design or widget creation.

Accessibility Workflow

1. Identify who must use the interface and what action or information matters most.
2. Check readability before decoration: text size, contrast, spacing, and label clarity.
3. Ensure keyboard and pointer users can both complete the task.
4. Make status understandable without color alone.
5. Keep motion helpful, optional-looking, and bounded.
6. Review final output for focus traps, tiny controls, ambiguous icons, and missing state text.

Readability

• Use short labels and plain operational language.
• Keep critical values and errors large enough to read at Dashboard widget size.
• Avoid placing important text over busy gradients or images.
• Maintain clear contrast in light and dark themes.
• Prefer stable layout over text that jumps during refresh.

Focus and Interaction

• Interactive controls need visible focus styling.
• Do not create hover-only actions for essential behavior.
• Keep click targets large enough for desktop pointer use.
• Put destructive actions away from routine actions and label them clearly.
• Provide a visible retry or recovery action when data fetches fail.

Status and Feedback

• Pair color with text, shape, icon, or position.
• Distinguish healthy, warning, critical, unknown, loading, and stale states.
• Do not report success while an async operation is still pending.
• Keep transient feedback concise and close to the affected control or data.

Motion and Animation

• Avoid continuous decorative animation in utility widgets.
• Stop requestAnimationFrame loops when animation is complete or not needed.
• Keep attention-grabbing motion for meaningful changes only.
• Avoid flashing and rapid color cycling.

KKTerm Boundaries

• Do not replace app-owned dialogs with browser alert, confirm, or prompt calls.
• Do not add one-off toast systems; user-facing transient status belongs in KKTerm's established status patterns.
• Do not duplicate Dashboard widget chrome inside script widgets.
• Preserve translated or non-English user-visible text exactly when editing existing code.

Review Checklist

Before finalizing UI or widget code, verify:

• Important information is readable without zooming.
• Each interactive element has text, a title, or a clear accessible name.
• Keyboard focus is visible where custom controls are used.
• Color is not the only signal.
• Loading, empty, error, and stale states are understandable.
• Motion is bounded and not required for comprehension.

DNS and DHCP Troubleshooter

Use this skill when a hostname resolves incorrectly, only works on some networks, fails after VPN changes, or the local machine has suspicious IP/gateway/DNS settings.

Workflow

1. Determine whether the symptom is DNS, DHCP, or both: name lookup failure, wrong address, search suffix issue, no lease, wrong gateway, or wrong DNS server.
2. Identify the resolver path: Windows DNS client, WSL resolver, VPN-provided DNS, remote SSH host resolver, or application-specific proxy.
3. Ask for the exact hostname and expected network context, but do not ask for secrets or private zone contents beyond what is needed.
4. Compare authoritative intent vs client result when available: expected record, actual answer, resolver used, TTL/cache behavior, and search suffix expansion.
5. For split DNS, check whether the user is on the right VPN or network and whether the query is being sent to the internal resolver.
6. For DHCP, inspect lease address, subnet mask, gateway, DNS servers, and lease age before suggesting renew/release actions.
7. Avoid telling users to hard-code public DNS servers when private zones, VPNs, domain controllers, or corporate policy may be required.
8. If flushing cache is suggested, explain that it removes cached client answers but does not fix authoritative records or resolver policy.

Command Guidance

• Windows DNS: Resolve-DnsName <host>, nslookup <host>, Get-DnsClientCache, Get-DnsClientServerAddress.
• Windows DHCP/interface: Get-NetIPConfiguration, ipconfig /all, ipconfig /renew only after confirming a local lease problem.
• WSL/POSIX: getent hosts <host>, resolvectl query <host> when available, cat /etc/resolv.conf.
• Remote SSH vantage point: run resolver checks on the remote host only when the question is about that remote network.

KKTerm Boundaries

• DNS behavior can differ between local Windows terminal Sessions, WSL, SSH Sessions, and WebView2 URL Connections.
• A Connection hostname is durable data, but DNS answers are runtime environment state.
• Do not rewrite Connection hosts from names to IPs unless the user explicitly wants that tradeoff.

Firewall and Port Troubleshooter

Use this skill when a host is reachable but a service port fails, times out, refuses connections, or works from one network but not another.

Workflow

1. Identify the protocol and port, including defaults only when the user has not provided one: SSH/SFTP 22, RDP 3389, VNC 5900+, HTTP 80, HTTPS 443.
2. Distinguish timeout, connection refused, reset, TLS/application error, and authentication failure. They point to different layers.
3. Check both sides: client-to-target reachability and whether the target service is actually listening on the expected address and port.
4. Consider path controls: Windows Firewall, host firewall, router/NAT, VPN ACL, cloud security group, corporate proxy, and service allowlists.
5. Prefer targeted allow rules or service binding fixes. Do not recommend disabling a firewall globally except as a short, explicit, user-approved test in a controlled environment.
6. For NAT/port forwarding, verify public/private address, forward target, hairpin NAT expectations, and whether the service is bound to localhost only.
7. For "works locally but not remotely," inspect listen address, firewall profile, and network classification before changing application credentials.
8. Avoid port scans beyond the named target and small named port set unless the user explicitly authorizes broader discovery.

Command Guidance

• Client test on Windows: Test-NetConnection <host> -Port <port>.
• Client test on POSIX/SSH: nc -vz <host> <port> or timeout 5 bash -c '</dev/tcp/<host>/<port>' when netcat is unavailable.
• Windows listener check: Get-NetTCPConnection -LocalPort <port> -State Listen and Get-Process -Id <pid> after mapping the owning process.
• POSIX listener check: ss -ltnp | grep ':<port>'.
• Windows Firewall read-only check: Get-NetFirewallRule -Enabled True filtered by DisplayName, Direction, Profile, or Program.

KKTerm Boundaries

• SFTP uses the SSH Connection transport; do not diagnose it as a separate open port.
• RDP and VNC are different protocols even when both are remote desktop Sessions.
• A failed port check can explain a Session startup failure, but it does not mutate the stored Connection.

Network Connectivity Troubleshooter

Use this skill when the user asks why a host, service, Connection, URL, or remote network path is unreachable or unreliable.

Workflow

1. Identify the vantage point: local Windows shell, WSL, SSH Session, remote host, VPN, or another network segment.
2. Clarify the target as narrowly as possible: host/IP, port/protocol if known, and whether the failure is total, intermittent, slow, or one app only.
3. Separate layers before suggesting fixes: name resolution, local interface, default gateway, route, VPN/proxy, firewall, remote listener, and application protocol.
4. Prefer read-only checks first: interface state, IP address, route table, DNS answer, ping when allowed, TCP connect test, and traceroute/path trace.
5. Compare at least two vantage points when possible, such as local KKTerm terminal vs SSH Session from a nearby host.
6. Treat ICMP results carefully. A failed ping does not prove TCP is blocked, and a successful ping does not prove the service is healthy.
7. For intermittent loss or latency, ask for timing, affected destinations, wired vs wireless/VPN state, and recent network changes before recommending resets.
8. For MTU symptoms, look for large transfers hanging, VPN-only failures, TLS stalls, or SSH/SFTP freezes after login.
9. Avoid broad reset commands until targeted evidence points to local network stack corruption.

Command Guidance

• Windows reachability: Test-NetConnection <host> -Port <port> for TCP, Resolve-DnsName <host> for DNS, and tracert <host> for path checks.
• PowerShell interface/routing: Get-NetIPConfiguration, Get-NetRoute, Get-DnsClientServerAddress.
• POSIX/SSH vantage point: ip addr, ip route, getent hosts <host>, nc -vz <host> <port>, tracepath <host> or traceroute <host> when installed.
• Keep commands read-only unless the user explicitly asks to change adapter, VPN, proxy, or route configuration.

KKTerm Boundaries

• Stored targets are Connections; live failures happen in Sessions.
• Quick Connect failures may come from draft fields that are not saved yet.
• URL Connections use embedded WebView2 and may be affected by OS proxy, TLS, or corporate inspection.
• SSH, SFTP, RDP, VNC, URL, and local terminal checks can all provide different network vantage points.

Remote Desktop Helper

Use this skill when the user asks about RDP, VNC, remote desktop input, screenshots, display sizing, connection failures, or credential prompts.

Workflow

1. Determine whether the target is RDP or VNC and whether it is a stored Connection, Quick Connect draft, or live Session.
2. For live interaction, inspect available Session context before sending keys, text, mouse clicks, or screenshots.
3. Prefer screenshots and read-only state before mutating remote input.
4. For keyboard input, use named keypresses for special keys and text send for plain text.
5. For mouse input, reason in remote surface coordinates and avoid blind clicks when the visible state is unknown.
6. For connection failures, separate network reachability, port/protocol, credentials, server policy, display size, and TLS/security settings.
7. Do not ask users to paste passwords into chat.
8. If an app overlay crosses an RDP surface, remember that RDP uses native HWND-backed rendering and may need special handling.

KKTerm Boundaries

• RDP and VNC are live Sessions; saved settings live on the Connection.
• RDP uses ActiveX on Windows and has special overlay parking behavior.
• WebView2, terminal, SFTP, and VNC should not inherit RDP overlay workarounds.
• Remote desktop tools that mutate input may require approval depending on Assistant tool permission mode.

SFTP Transfer Helper

Use this skill when the user asks about SFTP browsing, uploads, downloads, file conflicts, permissions, paths, or transfer failures.

Workflow

1. Confirm whether the user is working in an SFTP Session, an SSH terminal, or a stored SSH Connection.
2. Treat remote paths carefully. Distinguish root, home-relative, absolute, and sibling paths.
3. Prefer listing and inspecting before upload, overwrite, rename, chmod, or delete.
4. For transfers, clarify direction: local to remote upload, remote to local download, or remote-side rename/move.
5. For conflicts, explain the consequence of fail, overwrite, resume, rename, or skip choices.
6. For permission errors, separate ownership, mode bits, parent directory permissions, and server policy.
7. Avoid suggesting terminal-side file operations when the SFTP browser can perform the operation more safely.
8. Do not ask the user to paste passwords or private keys into chat.

KKTerm Boundaries

• SFTP opens from an SSH Connection.
• SFTP browser state is a live Session, not durable Connection data.
• File deletes are destructive and should be confirmed through app-owned approval flows when tools are available.
• Windows local paths and POSIX remote paths need separate quoting and separator rules.

SSH Troubleshooter

Use this skill when a user asks why an SSH Connection, SSH Session, tmux resume, or SFTP launch is failing.

Workflow

1. Identify whether the user is talking about a stored Connection, a Quick Connect draft, or a live Session.
2. Ask for the smallest missing fact only when the current context does not include it: host, port, auth method, proxy/jump path, or the visible error.
3. Prefer read-only checks first: Connection settings, host reachability, DNS, known host status, auth method, and tmux session name/history settings.
4. Explain likely causes in order of evidence, not in order of convenience.
5. Suggest commands only when they are reviewable and scoped to the target host or local config file.
6. For host key changes, treat the warning as security-sensitive. Do not tell the user to delete trust records until they confirm the host identity out of band.
7. For auth failures, separate password, key file, agent, and keyboard-interactive paths. Do not ask the user to paste secrets into chat.
8. For tmux issues, distinguish attach/resume failure from SSH transport failure.

KKTerm Boundaries

• Stored resources are Connections, not profiles.
• Live terminal state is a Session.
• SFTP opens from an SSH Connection.
• Secrets belong in the OS keychain, not chat or SQLite.
• Native SSH uses KKTerm's NativeSsh transport; local Windows shells use ConPTY through the Pty transport.

Terminal Command Planner

Use this skill when the user asks for terminal commands, shell diagnostics, log checks, service inspection, or command explanations.

Workflow

1. Determine whether the command targets a local terminal Session, an SSH Session, WSL, PowerShell, Command Prompt, or a generic shell.
2. Prefer read-only inspection before mutation.
3. Explain the intent and expected output before suggesting risky or unfamiliar commands.
4. Keep commands scoped to the named host, path, service, process, or file.
5. Avoid broad deletes, destructive disk operations, fork bombs, credential dumping, or irreversible system-wide changes.
6. For mutating commands, offer a safer dry run, preview, backup, or targeted form when practical.
7. Do not claim a command ran unless a tool result or session context proves it.
8. If the current shell is unknown, make the shell assumption explicit.
9. When translating between PowerShell, Command Prompt, WSL, and POSIX shells, call out syntax differences that matter.

KKTerm Boundaries

• Local Windows shells run through ConPTY; browser previews do not validate local terminal focus or input behavior.
• SSH uses NativeSsh and can differ from local shell behavior.
• Secrets must not be pasted into normal chat text.
• User-facing status belongs in the workspace status bar when changing app state.

TLS Certificate Troubleshooter

Use this skill when HTTPS, API, URL Connection, proxy, or secure service access fails with certificate, trust, hostname, or TLS handshake errors.

Workflow

1. Identify the failing client and target: WebView2 URL Connection, terminal command, SSH remote host, dashboard widget network request, or another tool.
2. Capture the exact error class: expired certificate, hostname mismatch, unknown issuer, incomplete chain, revoked certificate, protocol version, cipher, or handshake timeout.
3. Separate TLS certificate trust from SSH host key trust. They are different trust systems and should not share remediation steps.
4. Check the hostname used by the client. Certificate validation follows the requested DNS name, not a convenient alias or raw IP address.
5. For corporate inspection or proxy environments, ask whether the issuing CA is expected and managed before suggesting trust changes.
6. Treat clock skew as a first-class cause when certificates appear not-yet-valid or unexpectedly expired.
7. Avoid telling users to disable certificate validation. If a temporary bypass is discussed, label it unsafe and keep it out of saved app settings.
8. For internal services, prefer fixing the certificate chain, SANs, and server configuration over pinning brittle workarounds.

Command Guidance

• Windows certificate/date context: Get-Date, browser/WebView2 error text, and certificate viewer details when available.
• PowerShell HTTPS check: Invoke-WebRequest https://<host> -Method Head for a simple client-side error, without adding validation bypasses.
• OpenSSL check when installed: openssl s_client -connect <host>:443 -servername <host> -showcerts.
• POSIX remote check: curl -Iv https://<host> to view TLS and certificate errors without downloading a body.
• For non-443 services, use the service port and correct SNI/server name when the tool supports it.

KKTerm Boundaries

• URL Connections use WebView2, which follows Windows trust and proxy behavior.
• Dashboard AI Created Widgets may make network requests only when their permissions allow it and Settings permits widget network tools.
• Secrets and private keys must not be pasted into chat.
• SSH host key warnings belong to SSH troubleshooting, not TLS certificate repair.