@olegkoval/agent-skills 1.26.0 → 1.28.0

package/packages/software-development/lekker-review/adapters/claude/skills/lekker-review/references/github-post.md

@@ -0,0 +1,205 @@
+# github-post.md -- lekker-review --post flag procedure
+
+Execute this procedure AFTER the review file has been saved to `~/code-reviews/`
+and ONLY when the user passed `--post`.
+
+---
+
+## Step 1 -- Build the payload
+
+Construct a JSON payload at `/tmp/lekker-post-$$.json` with the structure:
+
+```json
+{
+  "body": "<summary section>",
+  "comments": [
+    {
+      "path": "<relative file path>",
+      "line": <line number>,
+      "side": "RIGHT",
+      "body": "<finding title + why + fix in GitHub markdown>"
+    }
+  ]
+}
+```
+
+Rules:
+
+- **Do NOT include an `event` field.** Omitting it creates a PENDING review,
+  visible only to the requesting user until they submit it. NEVER submit the
+  review programmatically.
+- Include one comment entry for every Critical and Important finding whose
+  `file:line` falls within the diff hunks of this PR (see Step 2 for how to
+  determine commentability).
+- **Keep every comment body to 2-4 sentences and under ~700 characters**
+  (excluding any suggestion block). Inline comments are read one at a time in a
+  narrow column; a long one does not get read, so length actively costs you the
+  fix. The detail belongs only in the saved review file (`~/code-reviews/*.md`).
+  Do NOT reproduce the file's full Critical/Important write-up inline.
+
+- **Open with the ask, in the imperative.** The first clause must be the action
+  the author takes ("Return early here", "Extract one shared winner-picker",
+  "Raise to 250", "Add a double with `session`"). Evidence comes after, and only
+  the evidence that makes the ask credible. Never open with a bolded severity
+  label, a restated finding title, or a preamble — the author already knows they
+  are reading a review comment.
+
+  ```
+  ✗ **Important — two implementations of "largest fulfillment order" with
+    different tie-break keys.** This ranks by value → units → id; `x.ts:104`
+    ranks by shipped qty → id. Diverging input: one shared line referenced by
+    FO-A (qty 1, one $100 item) and FO-B (qty 3, three $10 items) — fallback
+    picks FO-A, exact picks FO-B. Because `existingCreatedLines` idempotency is
+    keyed per `fulfillmentOrderGid` with no cross-FO check, a transient
+    exact-API failure on FO-A (fallback wins, line written) followed by a
+    successful retry on FO-B (exact wins, line written) posts the shared charge
+    twice. Please extract one `pickSharedChargeWinner(candidates, size, id)`…
+
+  ✓ Please extract one shared winner-picker used by both files, keyed on FO
+    value. This ranks value → units → id; `x.ts:104` ranks shipped-qty → id, so
+    FO-A (qty 1, one $100 item) vs FO-B (qty 3, three $10 items) gives A here
+    and B there. Idempotency is keyed per `fulfillmentOrderGid` with no cross-FO
+    check, so a fallback run that writes A's line followed by an exact-path
+    retry on B writes the same charge twice.
+  ```
+
+- **Cut every clause that does not change what the author does.** In particular:
+  no severity prefix (the review body already states the counts), no
+  "Why it's wrong:" / "Fix:" headers (that is the saved-file format, not the
+  inline format), no verifier reasoning, no restating what the PR does, no
+  second worked example once the first lands, and no sentence whose content is
+  already visible on the commented line.
+- **Use a GitHub suggestion block for the fix whenever it's a direct code change**
+  anchored to the commented line(s) — a reviewer can apply it with one click:
+  ```suggestion
+  <replacement line(s), exact drop-in for the line(s) the comment is anchored to>
+  ```
+  Only use a suggestion block when it exactly replaces the commented line(s) —
+  never for fixes spanning multiple files or requiring a new function/extraction
+  elsewhere. For those, describe the fix in one sentence instead and point to
+  the saved review for detail; do not paste a plain fenced code block as a
+  substitute for a real suggestion.
+- **Every inline comment must be ACTIONABLE** — it must ask for a concrete change
+  (fix X, add a test for Y, regenerate Z). Do NOT post informational-only or
+  FYI comments ("behaviour change, intentional", "note that…", "just flagging").
+  If there's nothing to do, there's no comment — put context like that in the
+  review body or the saved review file, never as an inline PR comment.
+- The review-level `body` field must contain, in this order: the finding counts
+  ("0 Critical / 5 Important / 6 Observations / 1 Idiomatic"), one or two
+  sentences of risk framing, then **a numbered list of the asks — one line each,
+  imperative, matching the inline comments in order**. That list is what the
+  author reads first and works from; it must be scannable in ten seconds. Then
+  any Production Signals, then a short flat list of Observations marked "no
+  action required", then the saved review file path.
+
+  Keep the body itself under ~2,500 characters. If it is longer, the asks are
+  buried — cut prose, never cut the numbered asks.
+- Do NOT prefix the body with a banner like "## Lekker review". Do NOT praise the
+  PR or describe what it does well — no "solid", "handled well", "clean", "nice".
+  State the risk and the asks only.
+- We use **Linear**, not Jira. Never write "Jira" in any comment or body; refer
+  to Linear ticket IDs (e.g. DUBO-201) directly.
+
+---
+
+## Step 2 -- Determine commentability
+
+A line is commentable only if it appears in the diff hunks for the file. To
+check, scan `DIFF_FILE` for the relevant hunk headers and added lines:
+
+```bash
+grep -n "^@@\|^+" "$DIFF_FILE" | grep -A20 "^.*+.*<relative-file-path>" | head -60
+```
+
+If the finding's `line` number does not correspond to a `+` line in the diff
+for that file, the finding is NOT commentable -- fold it into the review body
+under an "Additional findings" section instead.
+
+Observation and Idiomatic findings go into the body only; never as inline
+comments.
+
+---
+
+## Step 3 -- POST the review
+
+```bash
+gh api "repos/<REPO_SLUG>/pulls/<PR_NUMBER>/reviews" \
+  --method POST \
+  --input /tmp/lekker-post-$$.json
+```
+
+---
+
+## Step 4 -- Handle 422 errors
+
+If the API returns HTTP 422 (line not in diff):
+
+1. Remove the offending comment object from the payload (identify it from the
+   error response body, which names the path and line).
+2. Add its content to the review-level `body` under "Additional findings".
+3. Retry the POST once with the updated payload.
+
+If the same failure shape occurs a second time: stop, report the error message
+to the user, and fall back to "paste manually" -- do not loop further.
+
+---
+
+## Step 5 -- Verify (fresh post-condition)
+
+After a successful POST, immediately fetch the current review list:
+
+```bash
+gh api "repos/<REPO_SLUG>/pulls/<PR_NUMBER>/reviews"
+```
+
+Confirm:
+- A review with `state: "PENDING"` by the current authenticated user exists.
+- The `body` field contains the expected summary text.
+- The comment count matches what was submitted.
+
+Print the following to the terminal:
+
+```
+Posted PENDING review on <PR_URL>
+  - <N> inline comments
+  - Review ID: <id>
+
+ACTION REQUIRED: Open GitHub in your browser to review and submit the
+pending review. Pending reviews are only visible to you until submitted.
+```
+
+Clean up the temporary payload file:
+
+```bash
+rm -f /tmp/lekker-post-$$.json
+```
+
+---
+
+## Step 6 -- Revising an already-posted PENDING review
+
+If the user asks to shorten, reword, or re-scope the comments after posting:
+
+- The review-level `body` alone can be edited in place:
+  `gh api repos/<REPO_SLUG>/pulls/<PR_NUMBER>/reviews/<REVIEW_ID> --method PUT --input <json with {"body": ...}>`
+  Inline comments survive this untouched.
+- **Inline comment bodies cannot be reliably edited on a pending review** --
+  `PATCH /pulls/comments/{id}` targets submitted comments. To change them,
+  DELETE the pending review and POST a fresh one:
+  `gh api repos/<REPO_SLUG>/pulls/<PR_NUMBER>/reviews/<REVIEW_ID> --method DELETE`
+  This is safe only because a pending review is visible to nobody else. Capture
+  the existing bodies first (`--jq '.body'` and `/reviews/<id>/comments`) so
+  nothing is lost if the re-POST fails.
+- Verify by re-fetching the pending review and its comment count. Note that
+  `line`, `original_line`, and `side` come back `null` for comments on a pending
+  review -- that is expected, not a lost anchor. A successful POST (no 422) is
+  the receipt that the anchors were accepted.
+
+---
+
+## Notes
+
+- Never add an `event` field to the payload (not even `"COMMENT"`) -- that
+  would publish the review immediately to all participants.
+- The current authenticated user is whoever `gh auth status` reports.
+- If `gh api` is not authenticated, stop and tell the user to run `gh auth login`.

package/packages/software-development/lekker-review/adapters/claude/skills/lekker-review/references/house-rules.md

@@ -0,0 +1,76 @@
+# House rules (customize for your org)
+
+This file is a template. lekker-review reads it as `PROJECT_RULES` and feeds
+it to every review agent. Replace the example rules below with your own
+team's non-negotiable conventions — the kind of thing that should always be a
+**Critical** finding regardless of review depth, not a matter of taste.
+
+A hard rule in this file should be:
+- **Unambiguous** — a reviewer agent can check it mechanically against a diff.
+- **Non-negotiable** — violating it is always wrong, not "usually" wrong.
+- **Cheap to verify** — the review agent shouldn't need deep domain judgment.
+
+If you have no hard rules yet, leave this file mostly empty (just the Stack
+context section below) and let the 5 specialist agents rely on their own
+judgment plus the repo's own CLAUDE.md / linter config.
+
+---
+
+## Example hard rules (replace with your own)
+
+### EXAMPLE-1 — Type safety (TypeScript projects)
+- No type casts (`as X`, `<X>expr`) outside test files.
+- No `any` outside test files; even in tests, a blatantly untyped `any[]` on a
+  known-shaped list should still be flagged.
+
+### EXAMPLE-2 — No generated files hand-edited
+- Files under a `generated/` directory (codegen output, ORM types, GraphQL
+  types) must never be hand-edited in a diff — they should be regenerated
+  from source and the regen step re-run.
+
+### EXAMPLE-3 — Pagination must be complete
+- Any paginated API call (GraphQL `nodes` connections, REST cursor pagination)
+  must fetch every page, not just the first, unless a comment explains why a
+  partial fetch is intentional.
+
+### EXAMPLE-4 — PR title must reference its ticket
+- PR title must start with the ticket ID in brackets (e.g. `[PROJ-123]`),
+  covering every ticket referenced in the PR's commit history.
+- Treat a missing/incomplete prefix as **blocking**: surface a prominent
+  `⛔ CANNOT MERGE` warning and the recommended title. This is a process rule,
+  not a code-quality signal, so it should not affect a confidence score.
+
+---
+
+## Repo placement check (multi-repo projects only)
+
+If your org splits related concerns across sibling repos (e.g. a "backend
+sync" repo and a separate "storefront/app" repo), add your own repo taxonomy
+table here so the review agent can flag code landing in the wrong repo:
+
+```
+| Repo pattern      | Purpose                                |
+|--------------------|-----------------------------------------|
+| `<pattern-a>`      | <what belongs here>                     |
+| `<pattern-b>`      | <what belongs here>                     |
+```
+
+Note any exceptions (a repo that looks like pattern A but is actually a full
+app, a legacy folder that shouldn't be used for new code, etc.) — placement
+checks are only useful when they account for the real exceptions in your repo
+layout, not the naming convention alone.
+
+---
+
+## Stack context (fill in for your project)
+
+Give the review agents a one-paragraph map of your stack so they don't have
+to rediscover it from the diff every time:
+
+- **Backend:** <languages, frameworks, ORM, database>
+- **Frontend:** <framework, UI library, build tool>
+- **External APIs:** <third-party integrations worth knowing about, especially
+  ones with quirks: rate limits, OAuth flows, unusual pagination>
+- **Infra:** <how the app runs locally and in CI>
+- **Type/codegen pipeline:** <any source → generated-type steps that need to
+  stay in sync — flag stale generated output as a finding>

package/packages/software-development/lekker-review/adapters/claude/skills/lekker-review/references/output-format.md

@@ -0,0 +1,232 @@
+# Output format (Step 4)
+
+## Step 4 — Format Output
+
+Output is **one unified markdown document** — detailed enough to stand on its
+own, clean enough to paste directly into GitHub. No ANSI split, no stripped
+copy-paste block. Every finding includes location, the bad code, the reason,
+and the fix — all in standard GitHub markdown.
+
+Output the review as a markdown response (not via printf). No ANSI escapes.
+
+---
+
+### Output format
+
+```
+## Review — [PR #<PR_NUMBER> — <title>](<PR_URL>)
+
+**Author:** <author> · **Branch:** `<headRefName>` → `<baseRefName>`
+**Size:** +<additions>/-<deletions> across <changedFiles> files
+**Head:** `<headRefOid short sha>`
+**Linear:** [<ticket-id>](<linear-url>) — <ticket title>
+**Findings:** <X Critical / Y Important / Z Observations / W Idiomatic>
+**Proofs:** <M proven / N attempted> *(include only when N > 0)*
+**CI:** <✅ All passing | ⚠️ N failing: check-name | ⏳ Pending | N/A>
+**Depth:** <⚡ scan | 🔍 medium | 🔬 deep>
+
+---
+
+*(If PR_TITLE_ISSUE = true, insert this block here — before the Summary. Omit entirely if PR_TITLE_ISSUE = false.)*
+
+> ⛔ **CANNOT MERGE — PR title missing Linear ticket prefix**
+>
+> The PR title must start with the Linear ticket(s) in square brackets.
+> Recommended title prefix: **`<RECOMMENDED_PREFIX>`**
+>
+> How to fix: edit the PR title on GitHub to start with `<RECOMMENDED_PREFIX> <rest of current title>`.
+
+---
+
+## 🔁 Since last review
+
+*(Re-review mode only — include when PREV_SHA was found. Omit entirely on first review.)*
+
+Reviewed delta: `<PREV_SHA short>..<head short>`
+
+- ✅ Fixed: <prior finding title> (`file:line`)
+- ⚠️ Still open: <prior finding title> (`file:line`) — <one line on current state>
+
+---
+
+### Summary
+
+A substantive 2–3 paragraph narrative — NOT a one-line recap. A reader who
+hasn't seen the ticket or the diff should finish the Summary understanding
+*why this work exists* and *what it buys the business/team*, before any finding.
+Cover, in roughly this order:
+
+- **The problem / goal — why this PR exists.** What was broken, missing, or
+  needed? Pull this from the Linear ticket (the AC_LIST and ticket summary),
+  not just the diff. State the user-facing or business outcome the change is
+  reaching for ("RSL can create P21 contacts automatically from Shopify instead
+  of hand-keying them", "unblocks the PUT/update flow that depends on the
+  metafield being populated").
+- **What it does — the mechanism, in plain terms.** The shape of the solution:
+  the key entry points, the data flow, the gating/safety mechanisms, and how the
+  pieces fit. Name the design choices and *why each one was made* — kill switch
+  (so it can ship dark and be flipped per-environment), idempotency gate (so
+  re-deliveries don't duplicate), validation (so bad payloads fail fast and
+  non-retryably), stacking/deferral (so concurrency lands in a reviewable second
+  PR). The reader should learn the rationale, not just the inventory.
+- **Risk level + recommendation.** Land on the overall risk and what you advise:
+  ship as-is, ship after the Important fixes, or hold. If the headline risk is a
+  single finding, name it here in one sentence and point forward to it.
+
+Lead with the goal and the mechanism; keep the risk framing honest. This section
+sets the altitude for everything below — a risky PR should read as risky. Do NOT
+editorialize about what the PR does *well*: no praise, no "the win", no
+"cleanly/nicely implemented", no complimenting the design. State what it does and
+what the risks are — nothing about how good it is.
+
+---
+
+**Verdict: <✅ LGTM — ship it | ⚠️ LGTM with changes | 🚫 Needs work>**
+
+---
+
+## 🔥 Production Signals
+
+*(Include only when SENTRY_SIGNALS has entries. Omit section entirely if empty.)*
+
+- [<issue title>](<sentry-url>) — <N> events / <M> users (7d) · first seen <date>
+  Files: <relevant files from stack trace>
+  Note: <does this PR fix, worsen, or not affect this error?>
+
+---
+
+## 🚨 Critical — must fix before merge
+
+### #1 — <short label>
+
+**File:** `<path/to/file.ts>:<line>` · **Risk:** <one sentence — what breaks and when>
+
+**Current code:**
+\```ts
+<the actual bad lines from the diff, verbatim>
+\```
+
+**Why it's wrong:** <explanation — what the code does vs what it should do.
+Include the concrete failure: "lookup always returns undefined because the key
+is triple-wrapped", "crashes with TypeError on Node 20 because Map.groupBy
+does not exist", etc. If the author might not believe it, include a short
+proof inline.>
+
+**Fix:**
+\```ts
+<corrected version — exact drop-in replacement or minimal diff>
+\```
+
+**Proof — ran in the worktree:** *(include only when the finding carries a `proof` with `proven: true`)*
+\```
+<redOutput, verbatim>
+\```
+*Test asserts the correct behavior and fails because of this bug. It flips green when fixed.*
+
+---
+
+### #N — <label>
+...
+
+*(None.)* ← only if section is empty
+
+---
+
+## ⚠️ Important — should fix
+
+(same per-finding format, continuing the numbering sequence)
+
+*(None.)* ← only if section is empty
+
+---
+
+## 📝 Observations
+
+- <note — tradeoff, risk to watch, or design question worth raising>
+
+*(Omit section entirely if empty.)*
+
+## 🧪 Test Quality
+
+**Coverage verdict:** <✅ Well tested | ⚠️ Partially tested | ❌ Under-tested | N/A — no logic changes>
+
+<One paragraph: overall assessment — what is tested, what is missing, and
+whether the test suite would catch a regressing change to this code.>
+
+**Gaps:**
+- `test-file:line` — <gap or weakness>
+- `test-file:line` — <implementation-coupled test: IO mocked to reach logic,
+  call-shape spy, component mocked for its props, query hook mocked, or an
+  implementation-detail assertion>
+  → **Fix:** <no-mock refactor — usually "extract a pure function over plain
+  data and test that" or "inject a simple fake and assert the output">
+
+*(Omit if no mocking issues. Do not flag legitimate mocks — error paths,
+pinned non-determinism, un-runnable dependencies.)*
+
+**Mutation-slip risk:** <paragraph — which mutation classes would go undetected,
+if any. "No obvious gaps found." if clean.>
+
+*(Omit section entirely if no test changes and no business logic changes.)*
+
+---
+
+## 💡 Idiomatic & Consistency
+
+- **<deviation>** (`<file>:<line>`) — <the idiomatic alternative in one line>.
+  Precedent: `<file>:<line>` where the established pattern already lives.
+
+*(Non-blocking suggestions — do NOT affect the verdict. Omit section entirely
+if empty.)*
+
+---
+
+## 💰 Review Cost
+
+```
+Depth:            <⚡ scan | 🔍 medium | 🔬 deep>
+Diff size:        ~<N> lines (~<N> tokens)
+Agents run:       <N total> — <breakdown, e.g. "5 reviewers (sonnet) + 6 verifiers (sonnet) + 2 provers (sonnet) + 1 critic (sonnet)">
+Verify skipped:   <N> hard-rule finding(s) exempt from adversarial verification (omit the line when 0)
+Context sources:  <the subset of issue-tracker / chat / docs / framework-docs / monitoring / CI / prior-review-memory actually used>
+
+Output tokens:    <N>   ← ACTUAL workflow spend, from the workflow's outputTokens return value
+Turn total:       <N>   ← whole-turn shared pool (turnTokensTotal), main loop included
+Input tokens:     ~<N>  ← estimated: diff tokens × agent passes + context files + prompt files
+
+Cost: ~$<X.XX>  (output actual, input estimated; blended across model tiers below)
+```
+
+Per-MTok pricing (input/output) — verified 2026-07-07 from the claude-api reference; re-check there if models changed:
+- claude-fable-5: $10 / $50
+- claude-opus-4-8: $5 / $25
+- claude-sonnet-4-6 / claude-sonnet-5: $3 / $15
+- claude-haiku-4-5: $1 / $5
+
+Reviewer agents, verifiers, provers, and the critic all run on sonnet; triage and housekeeping on haiku. Only the main loop (context gathering + this synthesis) runs on the session model — use the session model's actual ID for that tier.
+
+---
+
+### Finding format rules
+
+- **File + Risk** on one line — the reader knows instantly what breaks and why
+  it matters before reading the proof.
+- **Current code** block: verbatim lines from the diff, enough context to find
+  the spot (3–10 lines). Never paraphrase — paste the actual code.
+- **Why it's wrong**: lead with the failure mode ("this always returns false
+  because…"), then the mechanism. Keep to 3–6 sentences. If a comparison or
+  counter-example makes it clearer, include it.
+- **Fix** block: show the corrected version as a drop-in replacement. When the
+  fix is architectural (extract helper, add index), describe it concisely then
+  show a minimal skeleton if useful. If the fix touches consumers outside the
+  changed file, call that out explicitly — never show a partial fix that looks
+  self-contained but silently breaks callers.
+- Blank line between findings. No double blank lines.
+- No trailing whitespace, no HTML tags, no ANSI escapes.
+- **Proof counter-evidence rule**: when `proof.attempted` is true but `proven`
+  is false because the code behaved correctly for the tested input, the
+  synthesis MUST treat that as counter-evidence — either downgrade the finding
+  or state in the finding body why the proof attempt doesn't exonerate it
+  (e.g. the tested input wasn't the one that actually breaks). A finding whose
+  proof came back green cannot silently stay Critical. When `attempted` is
+  false, say nothing — untestable is not evidence either way.

package/packages/software-development/lekker-review/adapters/claude/skills/lekker-review/scripts/changed-files.sh

@@ -0,0 +1,77 @@
+#!/bin/bash
+# changed-files.sh -- lekker-review helper
+# Determines the base ref for the branch checked out in WORKTREE_PATH and
+# prints, one path per line on stdout, the files this branch has changed
+# relative to that base. Prints the base ref actually used to stderr,
+# prefixed "base-ref: ", so callers can capture it separately from the file
+# list.
+#
+# Usage: changed-files.sh WORKTREE_PATH [--include-uncommitted]
+#   --include-uncommitted: also union in the worktree's uncommitted (working
+#   tree + staged) changes -- what a fix agent just wrote, even if it wasn't
+#   part of the original PR diff.
+#
+# Never fails: if no base ref can be resolved (or merge-base fails), prints
+# NOTHING to stdout, "base-ref: unknown" to stderr, and exits 0. Callers
+# should treat empty stdout as "could not scope -- fall back to repo-wide".
+
+set -uo pipefail
+
+WORKTREE_PATH="${1:?WORKTREE_PATH required}"
+INCLUDE_UNCOMMITTED=false
+[[ "${2:-}" == "--include-uncommitted" ]] && INCLUDE_UNCOMMITTED=true
+
+# ---------------------------------------------------------------------------
+# 1. Resolve a base ref: origin's default branch first, then a fixed
+#    fallback order.
+# ---------------------------------------------------------------------------
+BASE_REF=""
+
+SYM_REF="$(git -C "$WORKTREE_PATH" symbolic-ref refs/remotes/origin/HEAD 2>/dev/null || true)"
+if [[ -n "$SYM_REF" ]]; then
+    candidate="origin/${SYM_REF#refs/remotes/origin/}"
+    if git -C "$WORKTREE_PATH" rev-parse --verify --quiet "$candidate" >/dev/null 2>&1; then
+        BASE_REF="$candidate"
+    fi
+fi
+
+if [[ -z "$BASE_REF" ]]; then
+    for candidate in origin/staging origin/main origin/master; do
+        if git -C "$WORKTREE_PATH" rev-parse --verify --quiet "$candidate" >/dev/null 2>&1; then
+            BASE_REF="$candidate"
+            break
+        fi
+    done
+fi
+
+if [[ -z "$BASE_REF" ]]; then
+    printf 'base-ref: unknown\n' >&2
+    exit 0
+fi
+
+# ---------------------------------------------------------------------------
+# 2. Merge-base + diff.
+# ---------------------------------------------------------------------------
+MERGE_BASE="$(git -C "$WORKTREE_PATH" merge-base HEAD "$BASE_REF" 2>/dev/null || true)"
+if [[ -z "$MERGE_BASE" ]]; then
+    printf 'base-ref: unknown\n' >&2
+    exit 0
+fi
+
+printf 'base-ref: %s\n' "$BASE_REF" >&2
+
+CHANGED_TMP="/tmp/lekker-changed-files-tmp-$$.txt"
+git -C "$WORKTREE_PATH" diff --name-only "$MERGE_BASE" HEAD > "$CHANGED_TMP" 2>/dev/null || true
+
+if [[ "$INCLUDE_UNCOMMITTED" == "true" ]]; then
+    git -C "$WORKTREE_PATH" diff --name-only HEAD >> "$CHANGED_TMP" 2>/dev/null || true
+    git -C "$WORKTREE_PATH" diff --name-only --cached >> "$CHANGED_TMP" 2>/dev/null || true
+    # Untracked-but-not-ignored files too: a fix agent that creates a new file
+    # (extracted helper, new test) and does not stage it is invisible to both
+    # diffs above, so its type/lint errors would escape attribution entirely.
+    git -C "$WORKTREE_PATH" ls-files --others --exclude-standard >> "$CHANGED_TMP" 2>/dev/null || true
+    sort -u "$CHANGED_TMP" -o "$CHANGED_TMP" 2>/dev/null || true
+fi
+
+cat "$CHANGED_TMP"
+rm -f "$CHANGED_TMP"