菜单
Debug a running Last Light instance (usually production) via the `lastlight` CLI instead of SSH. Use when investigating a failed/stuck workflow, a bad agent run, a phase error, or "why didn't the bot do X" — anything that previously meant SSHing in to read SQLite or session logs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Keep Last Light's docs in sync with the code. Use before committing changes to apps/server/workflows/, skills/, config/default.yaml, src/connectors, src/state, src/engine/router.ts, src/config/, packages/cli/src, packages/shared/src (providers/overlay helpers), or agent-context/ — or whenever the docs-check pre-commit hook fires. Maps each changed file to the doc surfaces it affects (the in-repo apps/server/spec/*.md AND the apps/www site) and updates them.
Install the `lastlight` CLI and connect it as a CLIENT to an existing Last Light server — log in, save the token, and verify the connection. Use when the user wants to "connect / point my lastlight CLI at a server", "log in to Last Light", "set up the lastlight client", or run lastlight commands against a remote instance. For standing up the server itself use lastlight-server; for editing a deployment's config use lastlight-overlay.
Debug a running Last Light instance over its admin API with the `lastlight` CLI — no SSH. Use when the user wants to "look at / debug a failed or stuck workflow", "why didn't the bot do X", "check a bad agent run / phase error on <instance>", "tail a session", "search the logs", "read the server/docker logs", "list/trigger a cron", "resolve an approval", or "check stats/cost" against a deployed server. Needs a CLI already connected (see lastlight-client to log in). For standing up the server use lastlight-server; for editing config/workflows use lastlight-overlay.
Orientation & router for the Last Light skills. Use ONLY when the user has NOT named a concrete Last Light task — i.e. they're unsure which skill/flow they need, ask "what can Last Light do / where do I start", say "help me with Last Light" with no specific goal, or want a guided tour across server / client / overlay / debug / evals. Do NOT use when the ask already names a task — "set up/deploy a server" → lastlight-server, "connect/log in my CLI" → lastlight-client, "customize a workflow/prompt/persona/config" → lastlight-overlay, "debug a failed/stuck workflow or run on an instance" → lastlight-debug, "run evals / compare models / author a case / build a PR-review dataset" → lastlight-evals, "iteratively improve an eval toward a target score" → lastlight-evals-loop: invoke that skill directly. This skill only routes and, when the goal is ambiguous, asks. Also invocable as /lastlight-guide.
Install and configure a Last Light SERVER — the GitHub maintenance agent plus its docker-compose stack — on a host. Use when the user wants to "set up / install / deploy / stand up a Last Light server or instance", configure its GitHub App, models, managed repos, or domain, or get the agent running for the first time. Drives the `lastlight` CLI; for connecting an existing CLI to a server use lastlight-client instead, and for editing a running deployment's config use lastlight-overlay.
Drive a Last Light EVAL toward a target score with a disciplined, anti-gaming improvement loop — run → mine failures → propose candidate fix(es) → re-measure → keep the best or revert → repeat. Use when the user wants to "improve / raise the pr-review F1", "make the reviewer better against the eval", "close the loop on evals", "iterate on prompts/skills to pass more cases", or "tune the workflow to hit a score target". The loop diagnoses on a TRAIN split and validates on a BLIND held-out split so fixes must generalize, not overfit; it prefers generic overlay prompt/skill edits, and stops for human sign-off before editing any gold answer. For a one-off run/compare use lastlight-evals; to hand-fork a workflow/prompt use lastlight-overlay. Needs an already-scaffolded evals workspace (lastlight-evals) with a pr-review dataset.
| name | debug-production |
| description | Debug a running Last Light instance (usually production) via the `lastlight` CLI instead of SSH. Use when investigating a failed/stuck workflow, a bad agent run, a phase error, or "why didn't the bot do X" — anything that previously meant SSHing in to read SQLite or session logs. |
| version | 1.0.0 |
| tags | ["ops","debugging","cli"] |
Read a running instance's state over its admin API with the lastlight CLI —
no SSH, no poking SQLite or jsonl files on the box. Every command takes
--json for machine-parseable output; prefer it when you need to extract
fields.
The CLI talks to whatever instance you logged into (saved in
~/.lastlight/config.json). Confirm you're pointed at the right one and the
token is valid:
lastlight status # instance URL, server health, token validity
If the token is missing/expired, authenticate (the prod instance URL lives in local agent memory — see the "Last Light production server" note):
lastlight login https://<instance> # browser handoff (password/Slack/GitHub)
lastlight login https://<instance> --password # headless fallback
For one-off targeting without saving, pass --url / --token on any command,
or set LASTLIGHT_URL / LASTLIGHT_TOKEN (env wins over the saved config).
lastlight workflow list --status failed # recent failures
lastlight workflow list --status active # running + paused now
lastlight workflow list --workflow pr-review --limit 50
Copy the run ID from the table.
lastlight workflow log <run-id> # run header + per-phase table (✓/✗, duration, session id, error)
lastlight workflow log <run-id> --follow # then tail the current phase live
The phase table shows which phase failed, its error snippet, and the SESSION
id you need for the transcript.
lastlight session list # recent sandbox sessions (TYPE, MODEL, LIVE)
lastlight session log <session-id> # full transcript
lastlight session log <session-id> --follow # live tail (SSE) of an in-flight phase
lastlight logs search "ECONNREFUSED" # errors ledger (default)
lastlight logs search "rate limit" --scope all # errors + transcript content
lastlight logs search "could not clone" --scope messages --limit 20
--scope errors (default) matches the executions ledger (error/skill/repo);
messages greps recent session transcripts; all does both.
When the workflow + session views aren't enough — a crash before any session
was written, a sidecar misbehaving, harness boot errors — read the actual
container logs (docker logs) over the API:
lastlight server list # the lastlight-* containers + status
lastlight server logs # the agent harness (default), last 200 lines
lastlight server logs --tail 500 --since 10m
lastlight server logs --follow # live tail (Ctrl-C to stop)
lastlight server logs coredns-strict # a specific sidecar by service or container name
lastlight approvals list # paused gates waiting on a human
lastlight approvals approve <id> --reason "looks good"
lastlight approvals reject <id> --reason "wrong approach"
lastlight stats # totals + per-skill success/fail
lastlight stats --daily 14 # last 14 days of cost/tokens
--json to any command to pipe into jq (e.g.
lastlight workflow list --status failed --json | jq -r '.workflowRuns[].id').workflow list --status failed → workflow log <id> → grab the
failed phase's session → session log <session-id> → if it's a recurring
symptom, logs search "<error text>" to see how often it happens.approvals approve/reject and the trigger
commands (build/triage/review/…) — debugging never mutates the box.