lastlight 0.16.0 → 0.16.1

package/skills/issue-answer/SKILL.md

@@ -1,91 +0,0 @@
----
-name: issue-answer
-description: Answer a question directly — a sourced, neutral reply to an information/explanation/comparison request, from a GitHub issue or a Slack thread. Research repo docs and the web, output the answer, label `question` (GitHub only), leave open. Never write an agent brief, mark ready-for-agent, or change code.
-version: 1.1.0
-tags: [github, issues, questions]
----
-
-# Issue Answer
-
-A user asked a **question** — they want information, an explanation, or a
-comparison, not a code change. The router already decided this is a question;
-your job is to **answer it well and stop**. Do not re-triage it into a work item.
-
-The question reaches you from one of two places, and the prompt tells you which:
-- a **GitHub issue** (an `issueNumber` is set), or
-- a **Slack thread** (no `issueNumber`).
-
-## How your answer is delivered
-
-Your **final message is the answer** — the harness posts it for you (as a
-comment on the issue for GitHub-initiated runs, or into the Slack thread for
-Slack-initiated runs). So:
-
-- Make your final message the complete, self-contained answer in clean markdown.
-- **Do NOT post the answer yourself** with `github_add_issue_comment` — the
-  harness delivers it, and posting it too would double-post.
-
-## Hard caps
-
-This skill answers; it never queues work. Per invocation:
-
-- Produce **one** answer (your final message).
-- The only GitHub write you make is the `question` **label**, and only when
-  answering a GitHub issue.
-- **Never** write an agent brief, apply `ready-for-agent` / `ready-for-human`,
-  create branches, push code, or open a PR.
-- **Never** close the issue — leave it open for the human to close once the
-  answer satisfies them.
-
-If, while reading, you conclude the request is actually a bug or feature request
-(not a pure question), do **not** answer it as one. Make your final message a
-short note saying it looks like work rather than a question and asking a
-maintainer to `@last-light build` (or `explore`) it — let triage own work items.
-
-## Procedure
-
-1. **Understand the question.** Read the question from the prompt — the issue
-   title/body (and existing comments, for a GitHub issue) or the Slack message.
-   Identify exactly what the user wants to know.
-2. **Research.**
-   - **The repo** — read what's relevant to the answer: `CONTEXT.md`,
-     `README`, `docs/`, `spec/`, and code only as needed to ground claims about
-     this project. Don't survey the whole codebase; read what the question needs.
-   - **The web** — when the question references anything outside this repo
-     (another tool, framework, library, standard, or a "X vs Y" comparison),
-     use the `web_search` and `web_fetch` tools to consult current,
-     authoritative sources. Prefer official docs and primary sources.
-   - **Budget your research and converge.** You have a bounded number of tool
-     calls before the run ends — research is for grounding the answer, not
-     exhaustive coverage. Front-load the searches you need, then stop looking.
-     **Critical:** the moment you think *"I have enough"* (or *"let me just
-     confirm one more thing"*), do **not** fire another tool call — write the
-     answer **now**, in that same turn. Your reply being cut off mid-research
-     delivers a useless half-sentence to the user, which is worse than an
-     answer that omits a minor detail. If a fact is unverified, state it as
-     unverified in the answer rather than spending your last turn chasing it.
-     For broad/open-ended questions (e.g. "what's missing vs tool X"), gather a
-     representative sample and answer from it — explicitly noting it's a
-     sample, not an exhaustive audit — rather than enumerating everything.
-3. **Label (GitHub issue only).** Ensure `question` exists idempotently with
-   `github_ensure_labels` (`[{name: "question", color: "d876e3"}]` — one call,
-   no 422 to worry about), then apply it with `github_add_labels`. If ensuring
-   or adding the label is denied, skip it — the answer is the deliverable. For a
-   Slack-initiated question there is no issue to label.
-4. **Write the answer as your final message** (the harness delivers it — see
-   above; do not post it yourself):
-   - Direct and structured. Lead with the answer; use short sections or a
-     comparison table when it helps.
-   - **Neutral and grounded.** Claims about this project come from its docs;
-     claims about external things are **cited** with links to the sources you
-     used. Don't invent pricing, capabilities, or roadmap.
-   - **Honest about uncertainty.** If something is fast-moving or you couldn't
-     verify it, say so rather than stating it as fact.
-5. **Stop.** The answer is the conversation; a human closes the issue when satisfied.
-
-## Tool usage
-
-- GitHub operations via `github_*` MCP tools only — never `gh` CLI, `curl`, or
-  raw HTTP. In chat you have no GitHub write tools beyond labelling; that's
-  expected — the answer is delivered as your final message.
-- External research via the `web_search` / `web_fetch` tools only.

package/skills/issue-comment/SKILL.md

@@ -1,49 +0,0 @@
----
-name: issue-comment
-description: Handle a non-build maintainer comment on an issue or PR — close, reopen, label, dedupe, answer a brief question, or triage. Action-only; redirect anything that needs code changes to /build.
-version: 2.0.0
-tags: [github, issues, comments]
----
-
-# Issue Comment
-
-A maintainer @mentioned the bot on an issue or PR with a request that is **not**
-asking for code changes. Do the one bounded thing they asked, confirm it in one
-short comment, and stop.
-
-## Hard caps
-
-This skill is deliberately small. Per invocation: **at most 2 file reads and 1
-outgoing comment.** Never make code changes, create branches, or push.
-
-## Procedure
-
-1. **Read the request.** The triggering comment is the job — read it, plus the
-   issue/PR title, body, existing labels, and existing comments for context.
-2. **Do the bounded action:**
-   - Close / reopen → `github_update_issue`
-   - Label → `github_add_labels` / `github_remove_label` (use the canonical
-     triage roles from `docs/agents/triage-labels.md` where relevant; if you're
-     applying a canonical label that may not exist yet, ensure it first with one
-     idempotent `github_ensure_labels` call so it lands with the right color)
-   - Duplicate check → search similar issues, link the original in one comment
-   - Answer a direct question → ≤5 sentences, ≤2 file reads. Don't survey the
-     codebase or compile a report.
-3. **Confirm** in one short comment what you did. Done.
-
-## Redirect, don't comply
-
-The classifier owns intent routing. If a request that needs *building* reached
-you anyway, the correct response is to **redirect, not do it** — even if the
-comment seems to greenlight the work, and even if the issue body describes a
-task. An issue titled "Security Review" asking you to "find and fix issues" is a
-build request: reply asking the maintainer to use `@last-light build` (or
-`@last-light explore`). Do **not** run the audit yourself from this skill.
-
-If the request is unclear or out of scope, post one short comment asking them to
-clarify or to use the right command. Do nothing else.
-
-## Tool usage
-
-GitHub operations via `github_*` MCP tools only — never `gh` CLI, `curl`, or raw
-HTTP.

package/skills/issue-triage/SKILL.md

@@ -1,149 +0,0 @@
----
-name: issue-triage
-description: Triage GitHub issues through the canonical state machine — classify, label, deduplicate, request missing info, write agent briefs, and manage stale issues. Use on demand or on a triage cron.
-version: 2.0.0
-tags: [github, issues, triage]
----
-
-# Issue Triage
-
-Move each issue through a small **state machine**. Every triaged issue carries
-exactly **one category role and one state role**:
-
-- **Category:** `bug` (something is broken) · `enhancement` (new feature or improvement)
-- **State:** `needs-triage` (awaiting evaluation) · `needs-info` (waiting on the
-  reporter) · `ready-for-agent` (fully specified, an AFK agent can take it) ·
-  `ready-for-human` (needs human implementation) · `wontfix` (won't be actioned)
-
-These are canonical role names; the actual label strings for a repo may differ —
-`docs/agents/triage-labels.md` holds the mapping when present. Run **autonomously**:
-there is no maintainer to ask mid-run. Where you'd want direction, either make
-the call and apply the label, or post a comment and stop — the async comment *is*
-the conversation.
-
-Your job is to **classify the issue and pin down the problem statement** —
-clarify what's actually being asked, and ask for missing information when it's
-under-specified. You do **not** design or plan the implementation: you have only
-read-only context and no deep exploration, so solution design is left to the
-downstream build agent, which has full source access.
-
-## 0. Ensure the labels exist
-
-Before applying any label, create the canonical set in a **single** idempotent
-`github_ensure_labels` call — pass every row below as one `labels` array
-(`{name, color}`). It lists once and creates only the missing ones, so it never
-errors on labels that already exist:
-
-| Label | Color | Role |
-|-------|-------|------|
-| `bug` | `d73a4a` | category |
-| `enhancement` | `a2eeef` | category |
-| `needs-triage` | `ededed` | state |
-| `needs-info` | `fbca04` | state |
-| `ready-for-agent` | `0e8a16` | state |
-| `ready-for-human` | `1d76db` | state |
-| `wontfix` | `ffffff` | state |
-| `duplicate` | `cfd3d7` | dedupe |
-| `question` | `d876e3` | question |
-
-If the call is denied (the token lacks the permission), fall back to using
-only the labels that already exist on the repo and skip the rest. Done when the
-labels you need are present or you've confirmed you can't create them.
-
-## 1. Triage a specific issue
-
-1. **Gather context.** Read the full issue — title, body, comments, existing
-   labels, author, dates. Search existing issues for **duplicates** by concept
-   (not just keyword). If a `.out-of-scope/` directory exists, read it and note
-   any prior rejection this resembles. Done when you know the issue's intent and
-   whether it's novel.
-2. **Classify the category** — `bug` or `enhancement`. But first, check whether
-   the issue is a **question** at all (see below) — questions are neither.
-3. **Decide the state and act** (exactly one applies):
-   - **Question** (asks for information, an explanation, or a comparison — wants
-     an answer, not a code change) → add `question` and **stop**. Do **not**
-     write an agent brief or mark it `ready-for-agent`/`ready-for-human` — a
-     pure question is not work. (The router normally sends these to the answer
-     path before triage runs; this is the safety net for ones that slip
-     through, e.g. reopened issues. If you can answer it briefly and factually
-     from the repo itself, do so in one short comment; otherwise just label it
-     and leave it for the answer path or a human.)
-   - **Duplicate** → comment linking the original, add `duplicate`, close.
-   - **Already implemented** → comment pointing to where it lives, add `wontfix`,
-     close. (Factual — safe to close autonomously.)
-   - **Under-specified** (bug without repro, feature without a use case) → add
-     `needs-info`, post the [needs-info template](#needs-info-template), stop.
-   - **Fully specified and delegatable** → add `ready-for-agent`, post a triage
-     summary — the problem statement, not a solution design
-     ([references/AGENT-BRIEF.md](references/AGENT-BRIEF.md)).
-   - **Needs human implementation** (judgment calls, external access, design
-     decisions, manual testing) → add `ready-for-human` with a triage summary
-     noting why it can't be delegated.
-   - **Looks out of scope** (an enhancement you'd reject) → this is a maintainer
-     decision; do **not** auto-close. Add `needs-triage`, post a comment with
-     your reasoning (cite any matching `.out-of-scope/` file), and leave it for a
-     human.
-4. **Apply exactly one category + one state.** When you change an issue's state,
-   **remove the superseded state label** (e.g. clear `needs-info` when moving to
-   `ready-for-agent`) so the issue never carries two state roles. If the existing
-   labels conflict (two state roles you didn't set this run), flag it in a comment
-   and don't override — a maintainer may have set them deliberately.
-
-## 1a. Reporter answered or added information
-
-You may be re-triaging an open, pre-build issue because the reporter (or a
-maintainer) just commented — answering a `needs-info` request, or adding new
-detail, repro steps, or clarification. (Re-triage only fires before any build has
-started; once an issue is building, it's out of your hands.)
-
-1. **Re-read the whole thread** — the issue body, existing labels, and *all*
-   comments including the newest. Re-assess against the gaps that originally held
-   it back.
-2. **If the new information resolves the gaps** → move the issue forward per §1
-   step 3: remove `needs-info` and add `ready-for-agent` (+ triage summary),
-   `ready-for-human`, or `needs-triage` as appropriate.
-3. **If it's still under-specified** → keep `needs-info`, but **do not repost the
-   full [needs-info template](#needs-info-template)**. Acknowledge what they
-   answered and ask only the still-open questions — never duplicate a question
-   they've already addressed.
-
-## 2. New unlabelled issues (batch / cron)
-
-For each issue with no triage labels yet, run §1. Default new issues that need
-evaluation to `needs-triage`.
-
-## 3. Stale `needs-info`
-
-1. Find issues labelled `needs-info` with no activity for **14+ days**.
-2. **Check for a prior bot reminder** with `github_list_issue_comments` — look
-   for a `last-light[bot]` comment containing "reminder" / "still need" /
-   "closing". **Never post a duplicate reminder.**
-3. No reminder yet → post a gentle reminder asking if they still need help.
-4. Reminder exists and **30+ days** have passed with no reporter response since →
-   close kindly, noting they can reopen.
-5. Reminder exists, **< 30 days** since → do nothing.
-
-## needs-info template
-
-```markdown
-## Triage Notes
-
-**What we've established so far:**
-- point 1
-
-**What we still need from you (@reporter):**
-- specific, actionable question 1
-```
-
-Questions must be specific and actionable — not "please provide more info".
-
-## Tool usage
-
-GitHub operations via `github_*` MCP tools only — listing, labelling, commenting,
-closing, creating labels. Never `gh` CLI, `curl`, or raw HTTP.
-
-## Pitfalls
-
-- Don't close aggressively — when genuinely in doubt, leave it open as `needs-triage`.
-- Don't change priority or state on issues a maintainer already triaged.
-- Check existing labels before adding — don't duplicate.

package/skills/issue-triage/references/AGENT-BRIEF.md

@@ -1,65 +0,0 @@
-# Writing a triage summary
-
-A triage summary is a comment posted when an issue moves to `ready-for-agent`
-(or `ready-for-human`). It captures the **problem statement** — what the issue is
-really asking for and what "done" looks like — so a downstream agent (or human)
-can pick it up. The original body and discussion are context; the summary is the
-distilled problem.
-
-Triage classifies and **scopes the problem**. It does **not** design the
-solution: triage runs with read-only context and no deep exploration, so any
-implementation it guessed would be wrong as often as right. The build agent
-explores the codebase fresh, with full source access, and owns every
-implementation decision. Post the summary with `github_add_issue_comment`.
-
-## Principles
-
-**Durable.** The issue may sit in `ready-for-agent` for weeks while the codebase
-moves. Describe the problem and the desired behaviour in terms that stay true as
-the code changes. **Never** reference file paths or line numbers; they go stale.
-
-**Problem, not solution.** Say *what* should be true when the work is done, not
-*how* to build it. Do **not** name types, function signatures, or config shapes,
-propose an implementation approach, or point at where in the code to change —
-that is the build agent's job.
-- Good: "Todos can have an optional target date, shown in the list and editable."
-- Bad: "Add a `dueDate: Date` field to the `Todo` interface and a date picker in `TodoForm`."
-
-**Complete acceptance criteria.** List concrete, independently testable criteria
-so the agent knows when it's done. These describe the problem's done-state — not
-the implementation.
-- Good: "A todo with a past target date is visually flagged as overdue."
-- Bad: "Triage should work correctly."
-
-**Explicit scope boundaries.** State what is *out of scope* so the agent doesn't
-gold-plate or wander into adjacent features.
-
-## Template
-
-```markdown
-## Triage Summary
-
-**Category:** bug / enhancement
-**Summary:** one line — what needs to happen
-
-**Current behavior:**
-What happens now. For a bug, the broken behaviour. For an enhancement, the
-status quo it builds on.
-
-**Desired behavior:**
-What should happen after the work is done. Be specific about edge cases and
-error conditions — in user-visible / behavioural terms, not code.
-
-**Acceptance criteria:**
-- [ ] Specific, testable criterion 1
-- [ ] Specific, testable criterion 2
-
-**Out of scope:**
-- Thing that should NOT be changed here
-- Adjacent feature that looks related but is separate
-```
-
-## `ready-for-human` variant
-
-Same structure, plus a leading note on **why it can't be delegated** — judgment
-calls, external access, design decisions, or manual testing the agent can't do.

package/skills/pr-comment/SKILL.md

@@ -1,64 +0,0 @@
----
-name: pr-comment
-description: Answer a maintainer's question about an open PR with concrete, code-cited evidence. The PR-side counterpart to issue-comment — for questions tied to the diff, not a full review.
-version: 2.0.0
-tags: [github, pr, comments, qa]
----
-
-# PR Comment
-
-A maintainer @mentioned the bot on a PR with a *question* (not a request to
-write code, and not "review this"). The question is the entire job — answer it
-with evidence, in one comment. Examples: "does this consider X?", "why did we
-change Y?", "is the new function thread-safe?", "regression risk for existing
-callers?".
-
-For general issue questions use `issue-comment`; for a full review use
-`pr-review`.
-
-## Procedure
-
-### 1. Read the PR and the question
-
-- `github_get_pull_request` → title, body, base, head.
-- The triggering question is in `context.commentBody`. Answer *that* question —
-  don't generalise to a review or answer a different one.
-
-### 2. Investigate with the diff in hand
-
-Get the diff and read the code needed to answer well — a real answer about
-thread-safety or regression risk needs the surrounding code, not just the hunk.
-
-- **Cap: 8 file reads** per invocation.
-- "Does it consider X?" → also check whether tests in the diff cover X.
-- "Regression risk?" → find callers of any function whose signature/behaviour
-  changed (`github_search_code`).
-- Don't clone the repo unless a single answer genuinely needs cross-file traces
-  no MCP tool can give — most don't. If it truly needs a full audit, say so and
-  recommend `@last-light` (which routes to `pr-review`) rather than blowing the cap.
-
-### 3. Reply with one comment
-
-`github_add_issue_comment` (PRs accept issue comments here). Keep it tight:
-
-- **Lead with the answer** — yes / no / it depends. Don't bury it.
-- **Cite `path:line`** — clickable in the GitHub UI.
-- 3–8 sentences or a short bulleted list. No headings.
-- If it's unanswerable from the PR alone, say so and name the specific
-  information you'd need.
-
-> Yes — `src/foo.ts:42` checks `X` before calling `bar()`, and
-> `tests/foo.test.ts:118` asserts the rejection path. The only place X isn't
-> validated is the legacy `barLegacy` (`src/foo.ts:67`), which this PR doesn't
-> touch — worth a separate issue if you want it covered.
-
-## Do not
-
-- Post a formal review (`github_create_pull_request_review`) — that's
-  `pr-review`'s job and would collide with its blocking check.
-- Modify code, push, or add labels. One comment, nothing else.
-- Answer a tangent you noticed — note it in at most one trailing sentence.
-
-## Tool usage
-
-GitHub operations via `github_*` MCP tools only — never `gh` CLI, `curl`, or raw HTTP.

package/skills/pr-review/SKILL.md

@@ -1,148 +0,0 @@
----
-name: pr-review
-description: Review a GitHub pull request and post one formal review — advance the existing discussion and give precision-first, high-signal feedback. A pure code review — no building. Use when asked to review a PR or on a cron PR scan.
-version: 7.0.0
-tags: [github, review, code-quality]
----
-
-# PR Review
-
-Review an open PR — high-signal findings only. This is a **pure code review**:
-read the change and reason about it. Do **not** install dependencies, build, or
-run tests — that is CI's job, and it validates whether the change actually works
-far more reliably than you re-running it here. Your job is judgement on the diff,
-not a build gate. A noisy review gets muted, so precision matters more than
-volume.
-
-You do **not** post the review yourself. You write your findings to a JSON file
-(`.lastlight/pr-review/findings.json`) and a deterministic follow-up step posts
-one formal review, anchoring each finding to its diff line as an inline comment
-(§4).
-
-This skill is the PR-specific procedure. It uses the **code-review** skill for
-the precision bar and what-to-check rubric.
-
-## Workspace
-
-The harness pre-clones the PR's head ref and drops you **inside the checkout** —
-your cwd **is** the repo (`ls -la` shows `.git/` directly; `AGENTS.md` is the
-sibling one level up at `../`). Use `git`/`read`/`grep` from here. To refresh:
-`git fetch origin <branch> --depth 50 && git reset --hard FETCH_HEAD`. If the
-checkout is somehow missing, `git clone https://github.com/{{owner}}/{{repo}}.git .`.
-
-**Read code from this local checkout, never the API.** Use `git`/`read`/`grep`
-on disk for the diff and file contents. Do **not** call
-`github_get_pull_request_diff`, `github_list_pull_request_files`, or
-`github_get_file_contents` — the API patch is a large redundant payload that
-re-bloats context every turn. The `github_*` tools are for *API* operations only
-(reading metadata + prior comments in §1–2). You never post the review via a
-tool — you write the findings file and the follow-up step posts it.
-
-## Procedure
-
-### 1. Confirm the target
-
-If `prNumber` (or `issueNumber`) is set in the Context block, **that is your
-target** — go straight to `github_get_pull_request` with it. Do **not** call
-`github_list_pull_requests` to "find" or "confirm" it; you were handed it, and
-listing dumps a large payload for nothing. Only when no PR is given (a repo-wide
-`mode: scan`) do you list open PRs and pick the most recent unreviewed one.
-
-**Stop conditions** (check before reviewing):
-- PR authored by `last-light[bot]` → skip. Never self-review.
-- `merged === true` → stop. This skill reviews open PRs only.
-- A `last-light[bot]` review already exists on the **current head SHA** → stop;
-  don't post a duplicate. (A re-review is fine once new commits land.)
-
-### 2. Read the prior discussion
-
-A review advances the conversation, don't restart it. Fetch and absorb:
-`github_list_pull_request_reviews`, `github_list_issue_comments`,
-`github_list_pull_request_review_comments`. Done when you can say: which findings
-were already raised (don't repeat them), which threads the author resolved
-(treat as done unless the fix is wrong), which are still open (surface those —
-higher signal than a fresh nit), and whether a human already approved.
-
-### 3. Get the diff
-
-From inside `<repo>/`:
-```
-git fetch origin <baseRef> --depth 50      # base isn't in the head-only clone
-git diff --stat origin/<baseRef>...HEAD    # churn
-git diff origin/<baseRef>...HEAD           # the patch
-```
-
-### 4. Assess and write your findings
-
-Apply the **code-review** skill's rubric — read each changed file in context;
-check correctness / edge-cases / security / regression-risk / test-coverage.
-Reason about the code statically; **don't build or run it** — trust CI to catch
-what only running reveals, and spend your effort on what a human reviewer sees.
-Follow that skill's **precision-first** rule: keep **only Critical and Important**
-findings, each anchored to a `path:line` with a one-line concrete impact (what
-breaks, for which input or caller). Drop Suggestions and Nits.
-
-Before writing anything, run the **confidence gate**: re-read each finding
-against the actual code and try to refute it; drop any you can't defend against
-what the code really does. A clean PR should be approved with few or no
-findings — that is a good review, not a lazy one.
-
-**Do not call `github_create_pull_request_review` (or any review-submitting
-tool).** Write your findings to `.lastlight/pr-review/findings.json` instead. A
-deterministic follow-up step reads that file and posts one formal review with
-your findings as inline comments anchored to the diff. The full contract with
-worked examples is in [references/findings-schema.md](references/findings-schema.md);
-the shape is:
-
-```json
-{
-  "skip": false,
-  "summary": "One or two sentences on what the PR does + overall assessment.",
-  "event": "COMMENT",
-  "findings": [
-    {
-      "path": "src/foo.ts",
-      "line": 42,
-      "side": "RIGHT",
-      "severity": "Critical",
-      "title": "Short label for the finding",
-      "body": "Concrete impact — what breaks, for which input or caller.",
-      "suggestion": "exact replacement text for the anchored line(s)"
-    }
-  ]
-}
-```
-
-Write **only these content fields** — `skip?` / `summary` / `event` /
-`findings[]`. The follow-up step already knows the PR number, base ref, head
-SHA and diff from the harness's own context and the checkout, so you do **not**
-record any of that metadata (that reliance was a footgun — omit it).
-
-Rules:
-- **Anchor precisely.** `path` must match the diff path exactly; `line`/`side`
-  must point at a line that appears in the diff (added/context → `side: RIGHT`;
-  removed/context → `side: LEFT`). A finding whose line isn't in the diff is
-  demoted to the summary body, so get the anchor right. Use optional `start_line`
-  (same side) for a multi-line range.
-- `severity` is `Critical` or `Important` only.
-- `suggestion` is optional — include it only when a concrete one-to-few-line fix
-  is obvious. It must be the exact replacement text for the anchored line(s),
-  nothing else; GitHub renders it as an applyable suggestion.
-- `event` is `APPROVE` / `REQUEST_CHANGES` / `COMMENT`, matching what survived
-  the gate. A clean PR is an `APPROVE` with an empty `findings` array and a short
-  `summary`.
-- Create the dir and keep the file out of git first:
-  `mkdir -p .lastlight/pr-review && echo '.lastlight/' >> .git/info/exclude`.
-
-**Stop / skip:** if a stop condition in §1 holds (bot-authored, merged, already
-reviewed at the current head SHA), write `{"skip": true, "summary": "<reason>"}`
-and stop — the follow-up step then posts nothing.
-
-## Verification
-
-Confirm `.lastlight/pr-review/findings.json` is valid JSON and every finding
-carries `path` + `line`. The first-class `post-review` action then posts the
-review — anchoring each finding to its diff line, demoting any off-diff finding
-to the body, and logging how many landed inline vs in the body. If the file is
-missing after a real review (not a `skip`), that step **fails the run** loudly
-rather than posting nothing.

package/skills/pr-review/references/findings-schema.md

@@ -1,89 +0,0 @@
-# PR review findings schema
-
-The `pr-review` skill writes its findings to `.lastlight/pr-review/findings.json`
-(relative to the repo checkout — your cwd). The first-class `post-review` action
-reads this file and posts **one** formal GitHub review:
-
-- Each finding whose `line`/`side` anchors to a line that appears in the PR diff
-  becomes an **inline comment** on that exact line.
-- Any finding whose anchor isn't in the diff is **demoted** into the review body
-  under an "Additional findings" heading (GitHub rejects comments off the diff).
-- If the diff can't be computed (git failure), **all** findings go into the
-  body — the review still posts, so nothing is lost.
-
-You write only the review **content** — `skip?` / `summary` / `event` /
-`findings[]`. The PR number, base ref, head SHA and diff come from the harness's
-own run context and the checkout, so you do **not** record any of that metadata.
-You never call `github_create_pull_request_review` yourself; writing this file is
-how you submit.
-
-## Top-level object
-
-| Field | Type | Required | Meaning |
-|---|---|---|---|
-| `skip` | boolean | no | `true` → you decided not to review (bot-authored / merged / already reviewed at head). The action posts nothing. |
-| `summary` | string | yes | One or two sentences on what the PR does + your overall assessment. Becomes the review body. |
-| `event` | string | yes | `APPROVE` \| `REQUEST_CHANGES` \| `COMMENT`. A clean PR is `APPROVE` with an empty `findings` array. |
-| `findings` | array | yes | The surviving Critical/Important findings (may be empty). |
-
-## Finding object
-
-| Field | Type | Required | Meaning |
-|---|---|---|---|
-| `path` | string | yes | Repo-relative file path, matching the diff path exactly. |
-| `line` | number | yes | Line number on `side` that the comment anchors to. Must appear in the diff. |
-| `side` | string | no | `RIGHT` (added/context line — default) or `LEFT` (removed/context line). |
-| `start_line` | number | no | Start of a multi-line range (same `side` as `line`). |
-| `severity` | string | yes | `Critical` or `Important` only. |
-| `title` | string | yes | Short label for the finding. |
-| `body` | string | yes | Concrete impact — what breaks, for which input or caller. |
-| `suggestion` | string | no | Exact replacement text for the anchored line(s). Rendered as an applyable ```suggestion block. Include only when a concrete one-to-few-line fix is obvious. |
-
-## Example — findings with an inline suggestion
-
-```json
-{
-  "skip": false,
-  "summary": "Adds a `--config` flag to the CLI and threads it into the connect path. Solid overall; one crash on the default path and one missing-await.",
-  "event": "REQUEST_CHANGES",
-  "findings": [
-    {
-      "path": "src/cli.ts",
-      "line": 42,
-      "side": "RIGHT",
-      "severity": "Critical",
-      "title": "Null deref when --config is omitted",
-      "body": "`cfg.host` is undefined when no config file is passed, so every default-path invocation throws before connecting.",
-      "suggestion": "const host = cfg.host ?? DEFAULT_HOST;"
-    },
-    {
-      "path": "src/connect.ts",
-      "line": 88,
-      "side": "RIGHT",
-      "severity": "Important",
-      "title": "Missing await on disconnect()",
-      "body": "`disconnect()` returns a promise that's never awaited, so the socket can leak if the caller exits immediately after."
-    }
-  ]
-}
-```
-
-## Example — clean PR (approve, no findings)
-
-```json
-{
-  "skip": false,
-  "summary": "Small, well-tested refactor of the retry helper. No correctness or regression concerns.",
-  "event": "APPROVE",
-  "findings": []
-}
-```
-
-## Example — skip (already reviewed this SHA)
-
-```json
-{
-  "skip": true,
-  "summary": "A last-light[bot] review already exists on the current head SHA; nothing new to add."
-}
-```