kelly-devops

name

kelly-devops

description

Personal App-in-Skill ops desk for Kelly's multi-product SaaS fleet. Use when the user invokes $kelly-devops or /kelly-devops, or asks about uptime, service health checks, SSL certificate expiry, domain renewal, domain expiry, API key rotation, token rotation reminders, cloud spend anomaly, billing spikes, ops desk, incident review, or reviewing agent-proposed action cards (renew domain, rotate key, investigate spend, restart service, acknowledge incident).

Kelly DevOps

Overview

Use this skill as Kelly's product-fleet operations desk. It watches the health and expiry surface of a multi-product SaaS portfolio — service uptime, SSL certificate expiry, domain registration expiry, API key/token rotation reminders, and cloud spend anomalies — in one file-backed App-in-Skill dashboard, plus a review queue of agent-proposed action cards. The skill runs the checks and prepares actions; Kelly approves; the agent executes approved actions outside the app.

Default interaction mode: App UI. Unless the user explicitly asks for chat-only handling, check onboarding/config, refresh the ops snapshot with the check scripts, start/reuse the local app with app/start.sh, and give the actual local URL. Use chat-only mode only when the user says "纯聊天", "chat only", "不要打开 UI", or similar; then present numbered action cards (Action #1) and take verdicts in chat.

App UI Screenshots

Overview Fleet health desk with service, certificate, domain, and spend summaries plus a recent events feed.	Action queue Agent-proposed renew/rotate/investigate action cards with evidence and approval controls.
Expiry ledger Domains, SSL certificates, key rotations, and plan renewals in one table with color-coded days-left.	Services Monitored endpoints with uptime, latency sparklines, TLS certificate status, and check history.

Boundary

• Checks are read-only network probes of Kelly's own endpoints and domains: HTTP GET for status/latency, a TLS handshake for certificate expiry, and public RDAP lookups for domain expiry. Nothing else is contacted.
• The app reads and writes local files only. It must not probe endpoints, call registrars or cloud APIs, renew anything, rotate anything, or restart anything.
• Renewals, key rotations, service restarts, and spend remediation are approval-required and executed by the agent outside the app, only after the matching action card is approved.
• Never store registrar, cloud, or provider credentials in the repo. Secrets live only in local env files referenced by name from private config (*_env keys).
• Do not commit config.local.json, env files, app/.data/, billing exports, or raw provider responses.

First Run And Onboarding

On invocation, check app/.data/onboarding.json and private config readiness. If onboarding is absent/incomplete, guide setup before running real checks.

Private config priority:

1. KELLY_DEVOPS_CONFIG=/absolute/path/to/config.json
2. skills/kelly-devops/config.local.json
3. ~/.config/kelly-devops/config.json
4. skills/kelly-devops/config.example.json as template only

Env priority:

1. Existing environment variables
2. KELLY_DEVOPS_ENV_FILE=/absolute/path/to/.env
3. Repository root .env
4. skills/kelly-devops/.env.local
5. ~/.config/kelly-devops/.env

Onboarding asks, turn by turn: products in the portfolio, monitored endpoints (name/URL/product), domains (registrar, auto-renew flag), API keys under rotation policy (name, env var, rotate-every-days, last rotation), billing sources (provider plus *_env names for credentials), and thresholds (expiry warning days, degraded latency, spend anomaly %). Ask for non-secret details only; secrets go into local env files, never chat.

When setup is complete and the user confirms, write app/.data/onboarding.json:

{
  "completed": true,
  "completed_at": "ISO timestamp",
  "config_version": "1"
}

Local App

Start the ops desk with:

skills/kelly-devops/app/start.sh

The app uses local HTTP on 127.0.0.1, preferring port 3000 through 4000, or KELLY_DEVOPS_UI_PORT when set. /api/state reports app: "kelly-devops".

Required app views:

• #/overview: ops command desk. Human-attention panel (actions needing decision, items expiring within 14 days, services down), fleet summary cards (services up/total, certs ok/expiring, domains ok/expiring, month-to-date spend vs last month), recent events feed, and check freshness per check type.
• #/services and #/services/<id>: monitored endpoints with name, product, URL, status (up/degraded/down), latency, 7-day uptime, and cert days-left. Detail shows recent check history with an inline SVG latency sparkline, certificate summary (issuer, expiry), response metadata, and warnings.
• #/expiries and #/expiries/<id>: one expiry ledger across types (domain, ssl_cert, api_key_rotation, plan_renewal) with item, product, type badge, expiry date, color-coded days-left (<7 red, <30 amber), auto-renew flag, and linked action. Detail shows renewal guidance.
• #/spend: per-provider cards (MTD, last month, delta %, anomaly flag) and a per-product allocation table. Anomaly cards link to their action card.
• #/actions and #/actions/<id>: the review queue with workflow states needs_review, changes_requested, approved, done, blocked. Each card shows a stable ref (Action #1), type, reason, evidence, concrete plan, editable review note, and decision buttons (approve / request changes / block). Decisions are rejected while agent.lock exists.
• #/settings: sanitized config summary. Monitored services/domains, key rotation entries, billing sources with env readiness booleans, data provider name, onboarding state. Never expose secret values.

Demo mode:

• ?demo=1 opens a deterministic mock ops desk for documentation and screenshots.
• ?demo=overview, ?demo=services, ?demo=expiries, ?demo=spend, and ?demo=actions select named mock scenes.
• lang=en or lang=zh forces UI chrome language for screenshots.
• Demo API responses never read or write live endpoints or files under app/.data/, and demo decisions are never persisted.

UI language: support English and Chinese chrome with Auto default. Keep service names, URLs, domain names, and provider names in their original form.

File Contract

Read references/ops-schema.md before editing the app, scripts, or any generated ops JSON.

Primary local files:

• app/.data/ops_snapshot.json: canonical snapshot (services, expiries, spend, actions, events, metrics).
• app/.data/decisions.json: user verdicts keyed by action id.
• app/.data/agent_tasks.json: queued agent work from request_changes verdicts. Poll this to pick up revisions.
• app/.data/execution_report.json: planned operations from execute_decisions.ts (dry-run).
• app/.data/onboarding.json: onboarding completion marker.
• app/.data/agent.lock: temporary lock while the skill checks or rewrites files; the actions queue honors it.
• config.local.json: private fleet configuration, ignored by git.

Use scripts/validate_ui_schema.ts app/.data/ops_snapshot.json before relying on a snapshot in the UI. The app shows an empty setup state when no snapshot exists.

Check Workflow

1. Detect mode. Default to App UI.
2. Load private config through the store helpers. If only config.example.json exists, enter onboarding.
3. Run checks on a sensible cadence (or when the user asks):
   • node scripts/check_services.ts — HTTP status/latency per endpoint plus TLS certificate expiry via node:tls; merges service health, cert expiries, key-rotation reminders, and events. Run every visit or every few hours.
   • node scripts/sync_domains.ts — domain expiry via RDAP (https://rdap.org/domain/<name>); per-domain failures degrade gracefully. Run daily or on demand.
   • node scripts/ingest_spend.ts <payload.json> — the single write-path for billing data. The agent gathers the payload from cloud billing tools/exports (for example the aws-billing/google-cloud-billing skills), then this script validates, merges, and flags anomalies (MTD above the configured % of last month) and proposes investigate_spend action cards.
4. Every script acquires app/.data/agent.lock before writing and releases it after; scripts refuse to run over a foreign lock.
5. Validate the snapshot, start/reuse the UI, and report the URL plus what needs a decision.
6. Propose action cards for anything that needs a human call (renew_domain, rotate_key, investigate_spend, restart_service, ack_incident) with reason, evidence, and a concrete plan.

Actions Workflow

1. The user reviews action cards in #/actions (or by ref in chat) and gives verdicts: approve, request changes (with a note), or block. Notes save to decisions.json and the snapshot.
2. request_changes enqueues the card in app/.data/agent_tasks.json. Poll it, revise the card (new evidence/plan), set it back to needs_review, and clear the task.
3. For approved cards, run node scripts/execute_decisions.ts to write execution_report.json with concrete planned operations (renew_domain → registrar + domain, rotate_key → env var name, investigate_spend → provider, restart_service → service id, ack_incident → event id). The script is a dry-run stub with no external side effects.
4. Re-read decisions immediately before executing. Execute approved operations outside the app with the user's tools, then mark cards done in the snapshot and append an event.
5. If a target is missing (no registrar, no env var name), block and ask for configuration instead of guessing.

Safety Defaults

• Treat domain renewals, key rotation, service restarts, DNS changes, billing changes, and anything spending money as approval-required.
• Prefer read-only credentials for billing sources when possible.
• Redact tokens and token-like strings in logs, reports, and UI state; expose only env-var readiness booleans.
• Keep stable ids (service_id, expiry_id, action_id, ref) so repeated checks and executions are idempotent.
• If a check result looks inconsistent (e.g. cert days-left disagrees with RDAP), surface a warning and ask; do not invent corrections.