메뉴
Generate a health report for a GitHub repository — open-issue and PR backlog, unreviewed PRs, stale needs-info, failing CI, and the resulting action items. Use for a status report or on a weekly cron.
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 | repo-health |
| description | Generate a health report for a GitHub repository — open-issue and PR backlog, unreviewed PRs, stale needs-info, failing CI, and the resulting action items. Use for a status report or on a weekly cron. |
| version | 2.0.0 |
| tags | ["github","monitoring","reporting"] |
Produce a point-in-time health snapshot of a repo and the action items it implies. One report per run.
Pull these via github_* MCP tools. Done when each number below is filled.
needs-info — issues labelled needs-info with no activity for 14+ days.Batch requests and don't fetch full history — rate limits bite on large repos.
Each is a checkbox line with the number and the reason:
ready-for-agent issues sitting unactioned (agent backlog).needs-info (14+ days).## Repo Health: {owner}/{repo} — {YYYY-MM-DD}
### Overview
- Open issues: {X} ({breakdown by the repo's priority labels, if any})
- Open PRs: {X} ({Y} awaiting review)
- Merged this week: {X} PRs · Closed this week: {X} issues
### Action items
- [ ] PR #123 — open 12 days, no review
- [ ] Issue #456 — high priority, open 3 days
- [ ] Issue #789 — needs-info, stale 21 days
### Trends
- Issue velocity: +{X} opened, −{Y} closed (net {±Z})
Omit a section that has nothing in it rather than printing "none".
Output the report as the final response. The harness routes it (direct display interactively, or to the configured channel on a cron run).
Spot-check 2–3 of the reported numbers against the GitHub UI before delivering.