lastlight 0.1.8 → 0.2.0

package/skills/pr-review/SKILL.md

@@ -1,74 +1,90 @@
 ---
 name: pr-review
-description: Review a GitHub pull request with structured feedback following project guidelines
-version: 2.0.0
+description: Review a GitHub pull request and post one formal review — advance the existing discussion, verify by building, and give tiered feedback. Use when asked to review a PR or on a cron PR scan.
+version: 3.0.0
 tags: [github, review, code-quality]
 ---
 
-# PR Review Skill
+# PR Review
 
-## When to Use
-When asked to review a pull request, or when triggered by a webhook/cron to check for unreviewed PRs.
+Review an open PR and post **one formal review**. Build and test the change for
+real — static reasoning alone is not a review of correctness.
 
-## Procedure
+This skill is the PR-specific procedure. It uses two shared skills: the
+**building** skill for installing and running the test/lint/typecheck gate, and
+the **code-review** skill for the finding tiers and what-to-check rubric.
+
+## Workspace
 
-### 0. Check if already reviewed
+The harness pre-clones the PR's head ref into a `<repo>/` **subdirectory** of
+your cwd (the cwd holds `AGENTS.md`; the repo is one level deeper). `ls -la` —
+if you see `<repo>/.git/`, `cd <repo>` and use git directly. To refresh:
+`git fetch origin <branch> --depth 50 && git reset --hard FETCH_HEAD`. If the
+pre-clone is missing, `git clone https://github.com/{{owner}}/{{repo}}.git {{repo}}`.
 
-Before reviewing, **always check if the bot has already reviewed this PR**:
-1. Use `list_pull_request_files` to get the PR head SHA
-2. Use `get_pull_request` to check existing reviews
-3. Look for reviews from `last-light[bot]` — if one exists on the current head SHA, **skip this PR**. Do NOT post a duplicate review.
-4. If the PR has new commits since the last bot review, a re-review is appropriate.
+**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
+(metadata, comments, posting the review).
 
-### 1. Fetch PR metadata
+## Procedure
 
-Using MCP tools:
-- Get the PR title, description, author, labels, and linked issues
-- Get the list of changed files and the diff
-- Skip PRs authored by `last-light[bot]` (self-review)
+### 1. Confirm the target
 
-### 2. Analyze the changes
+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.
 
-- Read each changed file in context (not just the diff)
-- Check against the review guidelines in your agent context
-- Note the PR size (files changed, lines added/removed)
+**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.)
 
-**For complex PRs** (>300 lines changed OR >5 files changed):
-- Clone the repo locally and read changed files in FULL context
-- Trace data flow through modified functions
-- Check callers of modified functions for regression risk
-- Check if tests cover actual risk areas, not just happy paths
+### 2. Read the prior discussion
 
-### 3. Categorize findings
+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.
 
-- **Critical**: Security issues, data loss, breaking changes — block merge
-- **Important**: Missing tests, perf issues, type errors — should fix
-- **Suggestions**: Clarity, naming, DRY opportunities — nice to have
-- **Nits**: Style, formatting — optional
+### 3. Get the diff
 
-### 4. Write the review comment
+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
+```
 
-- 1-2 sentence summary of what the PR does
-- Findings grouped by tier, with file:line references
-- Inline code suggestions where helpful
-- For complex PRs: impact analysis (affected code paths, regression risks)
-- Overall assessment: approve, request changes, or comment
-- Thank the contributor
+### 4. Verify by building
 
-### 5. Submit the review
+Follow the **building** skill: install dependencies (install-first), then run the
+project's build and tests, and cite the real output in your findings. Any PR that
+touches code must be built and tested. The one exception is a pure style/docs PR,
+where building to nitpick formatting is wasted effort — skip it and say so.
 
-Use `create_pull_request_review` MCP tool. Do NOT post as a regular comment.
+### 5. Assess and submit
 
-## Tool Usage
+Apply the **code-review** skill's rubric — read each changed file in context,
+check correctness/edge-cases/security/regression-risk/test-coverage, and
+categorise findings into the tiers. Then write the review:
 
-**Always use MCP tools** for all GitHub operations. Never use `gh` CLI, `curl`, or raw HTTP requests.
+- One or two sentences on what the PR does.
+- Findings grouped by tier, each with a `path:line` reference and an inline code
+  suggestion where it helps.
+- For a complex PR, an impact note (affected paths, regression risks).
+- An overall assessment, and thanks to the contributor.
 
-## Pitfalls
-- **Never review the same PR twice** at the same commit — always check first
-- Don't nitpick generated files (lock files, compiled assets)
-- Don't repeat what linters/CI already catch
-- Don't block PRs over style preferences alone
-- Skip PRs authored by the bot itself
+Submit with `github_create_pull_request_review` (a **formal** review, not a plain
+issue comment), event `APPROVE` / `REQUEST_CHANGES` / `COMMENT` to match.
 
 ## Verification
-- Confirm the review was posted by checking the PR reviews list
+
+Confirm the review posted by checking the PR's reviews list.

package/skills/qa-test/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: qa-test
+description: Run an automated QA flow against a CLI or a locally-served app and report step-level pass/fail with evidence. Use when asked to QA-test a feature, exercise a flow end-to-end, or smoke-test what a PR changed.
+version: 1.0.0
+tags: [github, qa, testing, evidence]
+---
+
+# QA Test
+
+Drive a target through a sequence of steps and report **step-level pass/fail**
+with evidence for each step. The deliverable is a QA report, not a single
+verdict — partial coverage with documented failures is the expected output.
+
+This skill uses the **building** skill for installing dependencies and running
+the repo's build/run commands in the sandbox.
+
+> **Scope (text-evidence path).** In the default text phase the sandbox agent
+> has bash, file read, and the github tools — no browser, no screenshots. QA a
+> **CLI** directly, or a **web service** by starting its dev-server in the
+> background and exercising it with `curl` (status codes, response bodies,
+> headers). Capture stdout/stderr, exit codes, and log excerpts as per-step
+> evidence. Driving a real browser UI and attaching screenshots is the separate
+> `browser-qa` skill, staged only in the gated browser phase running on the
+> docker QA image (Playwright + Chromium). If that skill isn't in your
+> catalogue, mark a step that genuinely needs rendered-UI interaction
+> **BLOCKED** with the reason rather than faking a result — the browser phase
+> will pick it up when available.
+
+## Parse the target
+
+The Context block gives you what to test and (usually) a PR/issue. The target
+may be:
+
+- A **CLI command** (`my-cli --flag`, a subcommand) → run it directly.
+- A **local web service** (an app the repo serves on a port) → start it, hit it
+  with `curl`.
+- A **PR reference + focus area** → read the diff and infer the flow that
+  exercises what changed.
+- A **free-text flow** ("create a project, then list it") → infer concrete steps.
+
+When a PR/issue is given, read its description + diff (from the local checkout —
+see the **building** skill) to decide what's worth testing.
+
+## Define the steps
+
+If the request specifies steps, use them. Otherwise design a reasonable flow:
+
+- **CLI**: invoke with valid input → assert output/exit code → invoke an edge
+  case (bad flag, missing arg) → assert it's handled → done.
+- **Web service**: start the server → wait until it's ready → hit the primary
+  endpoint(s) → assert status + body → hit an error case → assert handling →
+  stop the server.
+
+State the steps and their success criteria before running. If the flow or the
+success criteria are genuinely ambiguous and you can't infer them from the diff,
+say what's unclear in the report rather than inventing a pass.
+
+## Run each step
+
+Follow the **building** skill to install and build first. Then run each step in
+order, capturing evidence (command + stdout/stderr + exit code) at every step.
+
+- **Record each step's result as you go** — PASS, FAIL, or BLOCKED.
+- **On failure, continue to the next step** for maximum coverage — *unless* the
+  failure blocks everything downstream (e.g. the server never starts, or a login
+  step fails). If it's a hard blocker, record it, mark the rest BLOCKED, and stop.
+- Treat a wrong result as a real finding, not your mistake. Don't edit the code
+  under test to make a step pass.
+
+## Report
+
+Produce your report as your **final message** in this shape — the workflow posts
+it for you (don't `github_add_issue_comment` yourself; that would double-post).
+**Keep it concise**: a one-line environment summary, the results table (terse
+Evidence cells), the failures, and a short coverage note — not a step-by-step
+narration.
+
+```
+## QA Test: <target>
+
+**Environment:** <branch / commit, package manager, how the app was run>
+
+### Results
+| Step | Status | Evidence |
+|------|--------|----------|
+| <step description> | PASS / FAIL / BLOCKED | <command + key output / exit code> |
+
+### Issues found
+- <each FAIL with the expected vs observed behaviour and the evidence>
+
+### Coverage
+<what was tested, and what was not tested and why (e.g. a UI-only step that the
+text-evidence sandbox can't drive).>
+```
+
+Every defined step must have a row and a result. Never report a flow as
+"passed" with steps you didn't actually run — list them as untested instead.

package/skills/repo-health/SKILL.md

@@ -1,64 +1,67 @@
 ---
 name: repo-health
-description: Generate a health report for a GitHub repository — open issues, PR backlog, CI status
-version: 1.0.0
-metadata:
-  hermes:
-    tags: [github, monitoring, reporting]
-    category: maintenance
-    requires_toolsets: [terminal]
+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]
 ---
 
-# Repository Health Check Skill
+# Repo Health
 
-## When to Use
-When asked for a repo status report, or on a weekly cron schedule.
+Produce a point-in-time health snapshot of a repo and the action items it
+implies. One report per run.
 
 ## Procedure
 
-1. **Gather metrics** for the target repository:
-   - Open issue count, broken down by label/priority
-   - Open PR count, and how long each has been open
-   - PRs awaiting review (no reviews yet)
-   - Issues labeled `needs-info` with no response
-   - Recently closed issues and merged PRs (last 7 days)
+### 1. Gather metrics
 
-2. **Identify action items**:
-   - PRs open > 7 days with no review
-   - Issues labeled `p0-critical` or `p1-high` still open
-   - Stale `needs-info` issues (14+ days)
-   - PRs with failing CI
+Pull these via `github_*` MCP tools. Done when each number below is filled.
 
-3. **Generate a summary report** in markdown:
-   ```
-   ## Repo Health: owner/repo — YYYY-MM-DD
+- **Open issues** — total, and a breakdown by the repo's own priority/severity
+  labels *if it uses any* (don't assume a fixed scheme).
+- **Open PRs** — total, and how long each has been open. Exclude drafts from any
+  "awaiting review" count.
+- **Unreviewed PRs** — open, non-draft, no reviews yet.
+- **Stale `needs-info`** — issues labelled `needs-info` with no activity for 14+ days.
+- **Recent throughput** — issues closed and PRs merged in the last 7 days.
 
-   ### Overview
-   - Open issues: X (Y critical, Z high)
-   - Open PRs: X (Y awaiting review)
-   - Merged this week: X PRs
-   - Closed this week: X issues
+Batch requests and don't fetch full history — rate limits bite on large repos.
 
-   ### Action Items
-   - [ ] PR #123 — open 12 days, no review
-   - [ ] Issue #456 — p0-critical, open 3 days
-   - [ ] Issue #789 — needs-info, stale 21 days
+### 2. Derive action items
 
-   ### Trends
-   - Issue velocity: +X opened, -Y closed (net: ±Z)
-   ```
+Each is a checkbox line with the number and the reason:
 
-4. **Deliver the report**:
-   - In interactive mode: display directly
-   - In gateway mode: send to the configured channel
+- PRs open > 7 days with no review.
+- High-priority issues still open (by whatever priority labels the repo uses).
+- `ready-for-agent` issues sitting unactioned (agent backlog).
+- Stale `needs-info` (14+ days).
+- PRs with failing CI.
 
-## Tool Usage
+### 3. Render the report
 
-**Always use MCP tools** (`mcp_github_*`) for all GitHub operations — listing issues, PRs, commits, labels. Never use `gh` CLI, `curl`, or raw HTTP requests. The MCP server handles authentication.
+```markdown
+## Repo Health: {owner}/{repo} — {YYYY-MM-DD}
 
-## Pitfalls
-- Don't include draft PRs in the "awaiting review" count
-- API rate limits: batch requests, don't fetch full history unnecessarily
+### 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".
+
+### 4. Deliver
+
+Output the report as the final response. The harness routes it (direct display
+interactively, or to the configured channel on a cron run).
 
 ## Verification
-- Spot-check 2-3 numbers against the GitHub web UI
+
+Spot-check 2–3 of the reported numbers against the GitHub UI before delivering.

package/skills/security-feedback/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: security-feedback
+description: Process a maintainer's comment on a security scan-summary issue — break selected findings out into individual actionable issues, or record accepted risks / false positives in SECURITY.md.
+version: 2.0.0
+tags: [github, security, feedback]
+---
+
+# Security Feedback
+
+A maintainer commented on a `security`-labelled issue — almost always a per-run
+**security scan summary** (one issue per scan, a task-list of findings). Based on
+the comment, either:
+
+- **Break selected findings into individual issues** (each can later feed `build`). Primary flow.
+- **Record a suppression** in `SECURITY.md` (accepted risk / false positive).
+- Reply for discussion, or ignore noise.
+
+The parent issue's grammar is the contract defined in
+`skills/security-review/references/issue-format.md`. This skill is staged into its
+own workspace and **cannot read that file**, so it carries its own copy of the
+row/severity regex below — **if you change the grammar, update both in lockstep.**
+
+## Context
+
+- `context.repo` — `owner/name`
+- `context.issueNumber` — the security summary issue (parent)
+- `context.commentBody` — the triggering comment
+- `context.sender` — the commenter's GitHub login
+
+The parent body is not passed — fetch it at step 1.
+
+## 1. Fetch and parse the parent issue
+
+`github_get_issue({ owner, repo, issue_number: issueNumber })`.
+
+**Version check.** The body MUST start with `<!-- lastlight-security-scan-version: 1 -->`.
+If the marker is missing or the version isn't `1`, reply: "Unknown scan-summary
+format — this skill is at version 1 but the parent reports a different version.
+Ask the maintainer to re-run `@last-light security-review`." Do not parse further.
+
+**Parse each finding row** with this canonical regex (all three states):
+
+```
+/^- \[([ x])\] <!-- item:(\d+) fp:([0-9a-f]{8,}) --> (?:~~)?\*\*(.+?)\*\* — `([^`]+):(\d+)` \(([a-z][a-z0-9-]*) · `([^`]+)`\)(?:~~ → #(\d+))?$/m
+```
+
+Captures: `checkbox` (` `/`x`), `item`, `fp`, `title`, `file`, `line`, `tool`,
+`rule`, and `subIssueNumber` (only when already broken out). Derive per row:
+
+| Derived | Definition |
+|---------|------------|
+| `alreadyBrokenOut` | `subIssueNumber != null` — turned into a sub-issue on a prior run |
+| `userTicked` | `checkbox === "x" && !alreadyBrokenOut` — the maintainer ticked the box, selecting it |
+
+`userTicked` is the primary selection signal; `alreadyBrokenOut` rows are never
+re-selected regardless of checkbox state.
+
+**Severity** comes from the nearest preceding section header (tolerating a
+trailing truncation suffix like `(showing first 7 of 25)`):
+
+```
+/^### (🔴|🟠|🟡|🟢) (Critical|High|Medium|Low) \((\d+)\)(?:\s.*)?$/m
+```
+
+Map Critical/High/Medium/Low → `p0-critical`/`p1-high`/`p2-medium`/`p3-low`.
+
+**Parse the `<details>` block** after each row (starts `<details><summary>Details</summary>`,
+ends `</details>`): the fenced block → `snippet` + `language`; paragraphs between
+the fence and `**Suggested fix:**` → `explanation`; text after `**Suggested fix:**`
+→ `suggestedFix`.
+
+Store each finding as `{ item, fp, title, file, line, tool, rule, severity,
+language, snippet, explanation, suggestedFix, userTicked, alreadyBrokenOut, subIssueNumber? }`.
+
+## 2. Classify the comment intent
+
+Pick the single best-fit bucket:
+
+- **create-issues** — break selected findings out. Signals: bare `@last-light
+  create issues` (defaults to ticked), "create issues for…", "make issues for…",
+  "break out…", "file sub-issues for…", "create an issue for items 1, 3".
+- **accept-risk** — accept a finding's risk. Signals: "accept-risk:", "we know
+  about this", "won't fix", "accepted".
+- **false-positive** — not real. Signals: "false-positive:", "not a vulnerability",
+  "not applicable".
+- **reopen** — re-evaluate a suppressed finding. Signals: "reopen", "re-evaluate".
+- **discuss** — a question or conversation about the findings.
+- **ignore** — noise (thanks, unrelated remark).
+
+`accept-risk` / `false-positive` / `reopen` MUST name a specific finding via
+`item N` / `item: N` — fall through to `discuss` if unresolved.
+
+## 3. Act
+
+### create-issues
+
+1. **Resolve the selection** (first match wins):
+   - **`ticked` / `checked` / `selected`** → every `userTicked` finding. Preferred UX.
+   - **Default (no qualifier)** → treat as `ticked`. If no rows are ticked, reply:
+     ```
+     No rows are ticked. Tick the checkboxes on the findings you want broken out, then comment again — or use one of:
+     - `@last-light create issues for the criticals`
+     - `@last-light create issues for items 1, 3, 5`
+     - `@last-light create issues for all`
+     ```
+   - `all` / `every` → every parsed finding regardless of tick state.
+   - `criticals` / `the criticals` / `p0-critical` → every `p0-critical` (same for
+     highs/mediums/lows). A count in the comment ("5 criticals") is ignored.
+   - `items N, M` / `item N` → specific 1-based item numbers from `<!-- item:N -->`.
+
+   In every form, silently drop `alreadyBrokenOut` findings and mention them in the
+   summary. If the selection is empty, reply:
+   ```
+   No findings matched `{selection text}`. This scan has: {nC} critical, {nH} high, {nM} medium, {nL} low. Ticked: {nTicked}. Already broken out: {nDone}.
+   ```
+   and create nothing. If the form is unrecognised (ambiguous), ask for clarification — don't guess.
+
+2. **For each selected finding**, `github_create_issue` using the sub-issue body
+   template in [references/templates.md](references/templates.md). Record each new
+   `subIssueNumber` against its `item`.
+
+3. **Rewrite the parent body.** For every finding just broken out, transition its
+   row to **broken-out**:
+   ```
+   - [x] <!-- item:N fp:FP --> ~~**TITLE** — `FILE:LINE` (TOOL · `RULE`)~~ → #SUBISSUE
+   ```
+   (checkbox `[x]`, title+location wrapped in `~~…~~`, ` → #SUBISSUE` appended).
+   Match by `item:N`. Do **not** touch rows that weren't selected, even if ticked.
+   Preserve all other content byte-for-byte. `github_update_issue`.
+
+4. **Post a summary comment** on the parent:
+   ```
+   Created {N} sub-issue(s) at @{sender}'s request:
+
+   - #{subN1} — {title 1} (item {item1})
+   …
+
+   {if any skipped}: Skipped {M} item(s) already broken out: items {list}.
+
+   Comment `@last-light build` on any sub-issue to start a fix.
+   ```
+
+### accept-risk / false-positive
+
+1. Resolve the target by `item N`; fall through to `discuss` if absent/unknown.
+2. Extract the reason (text after the first `:`, trimmed; "no reason given" if absent).
+3. `github_clone_repo`. Read `SECURITY.md`; create from the scaffold in
+   [references/templates.md](references/templates.md) if missing.
+4. Append a row to the matching table (accepted risks OR false positives) per the
+   template.
+5. Commit on branch `security/feedback-{parentIssueNumber}-{shortFingerprint}`,
+   push, and open a PR titled `security: record {accept-risk|false-positive} for {shortFingerprint}`.
+6. Comment on the parent: `Opened PR #{prNumber} to record this in SECURITY.md.
+   Once merged, this finding will be suppressed in future scans.`
+7. Do **not** tick the task-list checkbox — that marker is reserved for "broken out to sub-issue".
+
+### reopen
+
+Reply: "To re-evaluate this finding, run `@last-light security-review` — the next
+scan re-picks it up if `SECURITY.md` has been updated." Do not modify `SECURITY.md`.
+
+### discuss
+
+Reply conversationally using the finding's `<details>` block (risk, tool, suggested
+fix). Don't modify `SECURITY.md` or create sub-issues.
+
+### ignore
+
+Take no action.
+
+## Tool usage
+
+GitHub operations via `github_*` MCP tools only — never `gh` CLI, `curl`, or raw HTTP.

package/skills/security-feedback/references/templates.md

@@ -0,0 +1,77 @@
+# security-feedback templates
+
+## Sub-issue body (create-issues)
+
+`github_create_issue` with `title` = the finding's `title` (exactly as parsed, no
+prefix/suffix), `labels` = `["security", severity]` (e.g. `["security",
+"p0-critical"]`), and this body:
+
+````markdown
+<!-- fp:{fingerprint} -->
+<!-- parent-security-scan: #{parentIssueNumber} -->
+
+Broken out from security scan #{parentIssueNumber} on {today's date} at @{sender}'s request.
+
+**File**: `{file}:{line}`
+**Tool**: {tool} · `{rule}`
+**Severity**: {severity}
+
+```{language}
+{snippet}
+```
+
+{explanation}
+
+## Suggested fix
+
+{suggestedFix}
+
+---
+
+_To build a fix for this finding, comment `@last-light build` on this issue._
+````
+
+## SECURITY.md scaffold (accept-risk / false-positive)
+
+Create this if `SECURITY.md` is missing, then append the row:
+
+```markdown
+# SECURITY.md
+
+This file configures the Last Light security scanner for this repository.
+
+## Tool configuration
+
+| Tool | Severity floor |
+|------|---------------|
+| npm-audit | medium |
+| semgrep | medium |
+| gitleaks | high |
+| claude | medium |
+
+## Accepted risks
+
+Findings in this table are known risks the maintainers have explicitly accepted.
+The scanner will not re-file issues for these findings.
+
+| Fingerprint | Title | Reason | Date | Issue |
+|-------------|-------|--------|------|-------|
+
+## False positives
+
+Findings in this table have been classified as not real security issues.
+The scanner will not re-file issues for these findings.
+
+| Fingerprint | Title | Reason | Date | Issue |
+|-------------|-------|--------|------|-------|
+```
+
+Appended row (to whichever table matches the intent):
+
+| Column | Value |
+|--------|-------|
+| Fingerprint | First 16 hex chars of the finding's `fp` |
+| Title | Finding's `title` |
+| Reason | Extracted reason (text after the first `:`; "no reason given" if absent) |
+| Date | Today's date (YYYY-MM-DD, UTC) |
+| Issue | `#{parentIssueNumber}` |