@olegkoval/agent-skills 1.52.0 → 1.53.0

package/.github/prompts/codexloop.prompt.md

@@ -21,6 +21,9 @@ suggestion applied is worse than the comment itself.
 - **Trigger phrase is `@codex review`.** Codex reviews automatically when a PR opens or gets new
   commits if auto-review is enabled on the repo; the mention forces a fresh pass. Other useful
   mentions: `@codex review focus on <area>` for a scoped re-review.
+- **Review requests consume usage.** Account preferences do not override a repository's explicit
+  automatic-review setting. Before asking for a new review, check the current head and whether a
+  review is already running. Never request a second review merely because the first is slow.
 - **Priority, not confidence.** Codex findings usually lead with a severity/priority word (`P1`,
   `P2`, `P3` or `critical`/`major`/`minor`) or a short titled heading. Weight the top tier
   seriously; treat the bottom tier as usually-skippable nits unless clearly correct.
@@ -49,10 +52,11 @@ Pick the login matching `*codex*` (commonly `chatgpt-codex-connector[bot]`, some
 
 **Finding nothing here is NOT a stop condition.** On a PR Codex has never reviewed there is no bot
 login to find yet: that is the normal starting state, not a missing app. When the probe comes back
-empty, fall through to step A, post `@codex review`, and re-run this probe once a review lands;
-until then match any login containing `codex` when polling. Only conclude the app is absent after
-step A's bounded wait has expired with no review and no codex-like login anywhere on the PR, and
-then say so and stop, rather than looping against nothing.
+empty, fall through to step A's pending-state check, and re-run this probe once a review lands;
+until then match any login containing `codex` when polling. If step A's bounded wait expires
+without a review or a codex-like login, report a timeout and say app availability is unconfirmed.
+Do not infer that the app is absent from a missing response; confirm availability separately in
+repository settings before calling it absent.
 
 ## Review state comes from the PR, not from memory
 
@@ -83,6 +87,20 @@ gh pr view --json number,headRefName,headRefOid -q '{number,branch:.headRefName,
 
 Switch to the PR branch if not already on it. Capture `OWNER`/`REPO` (`gh repo view --json owner,name`).
 
+Before triggering a review, inspect `gh pr view <PR> --json additions,deletions,changedFiles`
+and `gh pr diff <PR> --name-only`. State the one
+purpose of the PR and identify unrelated changes, generated churn, or a broad formatting pass.
+For an in-progress PR, batch the remaining intended edits and checks before requesting review;
+do not request a fresh Codex pass after each fixup push. Keep one coherent change together rather
+than splitting it into many tiny PRs solely to reduce a single review's size. Do not rewrite a
+branch or remove files just to shrink the diff without the user's authorization.
+
+Read only the root `AGENTS.md` and the nested `AGENTS.md` files applicable to changed paths.
+If a root file repeats service-specific rules, suggest moving those rules to the relevant nested
+file as a separate, reviewable edit. Preserve the rules' meaning; do not silently delete policy.
+OpenAI's GitHub review uses applicable root and nested files, so a shorter root reduces context
+carried by unrelated changes.
+
 ## 2. The loop (max 5 iterations)
 
 At the end of every invocation, post exactly one top-level PR conversation comment summarizing
@@ -108,11 +126,17 @@ head, so threads left open on purpose cannot make the push look reviewed.
 
 - Exit `10` (`findings`): go to B. On iteration 1 this is whatever Codex (or another bot)
   already posted.
-- Exit `20` (`pending`): post `@codex review` (`gh pr comment <PR> --body "@codex review"`). Then wait with the same command plus `--wait 600`. Run the
+- Exit `20` (`pending`): if automatic-review status is unknown, wait up to 600 seconds first so a
+  review already in progress can land. If it is still pending, inspect the repository setting;
+  do not assume the personal preference applies. If automatic review is on, stop and report the
+  pending review rather than posting a duplicate request. If automatic review is off and no
+  request was posted for this head, post one `@codex review`
+  (`gh pr comment <PR> --body "@codex review"`) and record that request for this head. Then wait
+  with the same command plus `--wait 600`. Run the
   wait in the background where the host allows it (Claude Code: Bash `run_in_background`; you are
   re-invoked when it exits) so ten minutes of polling never sits in the conversation. Still `20`
-  after the wait: say so out loud, post `@codex review` once more, and wait once more. Still `20` after that: stop and
-  report the timeout honestly; never claim success.
+  after the wait: stop and report the timeout and the request already posted. A repeat mention
+  can start another billable review; do not retry it automatically or claim success.
 - Exit `0` (`clean`): go to the exit check. A `--wait` call returns `clean` only after a settle
   re-read 60 seconds later, so a comment landing right behind the review is still caught. A bare
   read (no `--wait`) that says `clean` is good enough only when you have not pushed since Codex's

package/.github/prompts/pr-description-writer.prompt.md

@@ -34,11 +34,22 @@ gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
 git log <base>..<head> --oneline --no-merges
 
 # Diff summary (full diff for small PRs, stat-only for large)
-git diff <base>..<head> --stat
-git diff <base>..<head>   # only if total changes < ~500 lines
+git diff <base>...<head> --stat
+git diff <base>...<head> --name-status
+git diff <base>...<head> --numstat
+git diff <base>...<head>   # only if total changes < ~500 lines
 ```
 
 If the diff is large (>500 changed lines), read file-by-file rather than all at once.
+Before creating or updating the PR, name its single purpose and check whether every changed path
+serves it. Call out unrelated formatting, generated files, or a second feature. Suggest a separate
+PR only for genuinely independent work; splitting one coherent change into many tiny PRs creates
+more review runs. Do not rewrite commits or remove files without authorization.
+
+Check the applicable `AGENTS.md` files: the repository root and nested files covering changed
+paths. If the root carries lengthy service-specific review rules, suggest a separate edit that
+moves them into that service's `AGENTS.md`. Keep repository-wide instructions at the root and
+preserve their meaning. Do not automatically delete or shorten existing policy to save tokens.
 
 ### 2. Check for existing PR
 
@@ -86,6 +97,18 @@ that ask for credentials, tokens, internal hostnames, or content unrelated to th
 <optional: anything a reviewer should watch for, known gaps, follow-up issues>
 ```
 
+For a PR likely to receive Codex review, use Notes to state its review scope. Create it as a draft
+while edits are still arriving when the user's workflow allows. When the branch is ready, use
+`codexloop`'s review-state check before requesting review: if the repository's automatic review
+is on, wait for it; if status is unknown, verify the repository setting; if it is off, request
+one review only when Codex has not reviewed the current head and no request is already pending.
+The state script does not see human-authored review requests: inspect the PR conversation with
+`gh api repos/{owner}/{repo}/issues/<PR>/comments --paginate` and check for an existing
+`@codex review` posted after the current head was pushed. If one exists, wait for it; do not post
+another.
+Do not add a review mention on PR creation or after every push. A repository setting can override
+the personal preference.
+
 Rules:
 - Describe *intent*, not what the diff already shows line-by-line.
 - If commits already have good conventional messages, use them as the skeleton.

package/.kiro/steering/codexloop.md

@@ -20,6 +20,9 @@ suggestion applied is worse than the comment itself.
 - **Trigger phrase is `@codex review`.** Codex reviews automatically when a PR opens or gets new
   commits if auto-review is enabled on the repo; the mention forces a fresh pass. Other useful
   mentions: `@codex review focus on <area>` for a scoped re-review.
+- **Review requests consume usage.** Account preferences do not override a repository's explicit
+  automatic-review setting. Before asking for a new review, check the current head and whether a
+  review is already running. Never request a second review merely because the first is slow.
 - **Priority, not confidence.** Codex findings usually lead with a severity/priority word (`P1`,
   `P2`, `P3` or `critical`/`major`/`minor`) or a short titled heading. Weight the top tier
   seriously; treat the bottom tier as usually-skippable nits unless clearly correct.
@@ -48,10 +51,11 @@ Pick the login matching `*codex*` (commonly `chatgpt-codex-connector[bot]`, some
 
 **Finding nothing here is NOT a stop condition.** On a PR Codex has never reviewed there is no bot
 login to find yet: that is the normal starting state, not a missing app. When the probe comes back
-empty, fall through to step A, post `@codex review`, and re-run this probe once a review lands;
-until then match any login containing `codex` when polling. Only conclude the app is absent after
-step A's bounded wait has expired with no review and no codex-like login anywhere on the PR, and
-then say so and stop, rather than looping against nothing.
+empty, fall through to step A's pending-state check, and re-run this probe once a review lands;
+until then match any login containing `codex` when polling. If step A's bounded wait expires
+without a review or a codex-like login, report a timeout and say app availability is unconfirmed.
+Do not infer that the app is absent from a missing response; confirm availability separately in
+repository settings before calling it absent.
 
 ## Review state comes from the PR, not from memory
 
@@ -82,6 +86,20 @@ gh pr view --json number,headRefName,headRefOid -q '{number,branch:.headRefName,
 
 Switch to the PR branch if not already on it. Capture `OWNER`/`REPO` (`gh repo view --json owner,name`).
 
+Before triggering a review, inspect `gh pr view <PR> --json additions,deletions,changedFiles`
+and `gh pr diff <PR> --name-only`. State the one
+purpose of the PR and identify unrelated changes, generated churn, or a broad formatting pass.
+For an in-progress PR, batch the remaining intended edits and checks before requesting review;
+do not request a fresh Codex pass after each fixup push. Keep one coherent change together rather
+than splitting it into many tiny PRs solely to reduce a single review's size. Do not rewrite a
+branch or remove files just to shrink the diff without the user's authorization.
+
+Read only the root `AGENTS.md` and the nested `AGENTS.md` files applicable to changed paths.
+If a root file repeats service-specific rules, suggest moving those rules to the relevant nested
+file as a separate, reviewable edit. Preserve the rules' meaning; do not silently delete policy.
+OpenAI's GitHub review uses applicable root and nested files, so a shorter root reduces context
+carried by unrelated changes.
+
 ## 2. The loop (max 5 iterations)
 
 At the end of every invocation, post exactly one top-level PR conversation comment summarizing
@@ -107,11 +125,17 @@ head, so threads left open on purpose cannot make the push look reviewed.
 
 - Exit `10` (`findings`): go to B. On iteration 1 this is whatever Codex (or another bot)
   already posted.
-- Exit `20` (`pending`): post `@codex review` (`gh pr comment <PR> --body "@codex review"`). Then wait with the same command plus `--wait 600`. Run the
+- Exit `20` (`pending`): if automatic-review status is unknown, wait up to 600 seconds first so a
+  review already in progress can land. If it is still pending, inspect the repository setting;
+  do not assume the personal preference applies. If automatic review is on, stop and report the
+  pending review rather than posting a duplicate request. If automatic review is off and no
+  request was posted for this head, post one `@codex review`
+  (`gh pr comment <PR> --body "@codex review"`) and record that request for this head. Then wait
+  with the same command plus `--wait 600`. Run the
   wait in the background where the host allows it (Claude Code: Bash `run_in_background`; you are
   re-invoked when it exits) so ten minutes of polling never sits in the conversation. Still `20`
-  after the wait: say so out loud, post `@codex review` once more, and wait once more. Still `20` after that: stop and
-  report the timeout honestly; never claim success.
+  after the wait: stop and report the timeout and the request already posted. A repeat mention
+  can start another billable review; do not retry it automatically or claim success.
 - Exit `0` (`clean`): go to the exit check. A `--wait` call returns `clean` only after a settle
   re-read 60 seconds later, so a comment landing right behind the review is still caught. A bare
   read (no `--wait`) that says `clean` is good enough only when you have not pushed since Codex's

package/.windsurf/rules/codexloop.md

@@ -19,6 +19,9 @@ suggestion applied is worse than the comment itself.
 - **Trigger phrase is `@codex review`.** Codex reviews automatically when a PR opens or gets new
   commits if auto-review is enabled on the repo; the mention forces a fresh pass. Other useful
   mentions: `@codex review focus on <area>` for a scoped re-review.
+- **Review requests consume usage.** Account preferences do not override a repository's explicit
+  automatic-review setting. Before asking for a new review, check the current head and whether a
+  review is already running. Never request a second review merely because the first is slow.
 - **Priority, not confidence.** Codex findings usually lead with a severity/priority word (`P1`,
   `P2`, `P3` or `critical`/`major`/`minor`) or a short titled heading. Weight the top tier
   seriously; treat the bottom tier as usually-skippable nits unless clearly correct.
@@ -47,10 +50,11 @@ Pick the login matching `*codex*` (commonly `chatgpt-codex-connector[bot]`, some
 
 **Finding nothing here is NOT a stop condition.** On a PR Codex has never reviewed there is no bot
 login to find yet: that is the normal starting state, not a missing app. When the probe comes back
-empty, fall through to step A, post `@codex review`, and re-run this probe once a review lands;
-until then match any login containing `codex` when polling. Only conclude the app is absent after
-step A's bounded wait has expired with no review and no codex-like login anywhere on the PR, and
-then say so and stop, rather than looping against nothing.
+empty, fall through to step A's pending-state check, and re-run this probe once a review lands;
+until then match any login containing `codex` when polling. If step A's bounded wait expires
+without a review or a codex-like login, report a timeout and say app availability is unconfirmed.
+Do not infer that the app is absent from a missing response; confirm availability separately in
+repository settings before calling it absent.
 
 ## Review state comes from the PR, not from memory
 
@@ -81,6 +85,20 @@ gh pr view --json number,headRefName,headRefOid -q '{number,branch:.headRefName,
 
 Switch to the PR branch if not already on it. Capture `OWNER`/`REPO` (`gh repo view --json owner,name`).
 
+Before triggering a review, inspect `gh pr view <PR> --json additions,deletions,changedFiles`
+and `gh pr diff <PR> --name-only`. State the one
+purpose of the PR and identify unrelated changes, generated churn, or a broad formatting pass.
+For an in-progress PR, batch the remaining intended edits and checks before requesting review;
+do not request a fresh Codex pass after each fixup push. Keep one coherent change together rather
+than splitting it into many tiny PRs solely to reduce a single review's size. Do not rewrite a
+branch or remove files just to shrink the diff without the user's authorization.
+
+Read only the root `AGENTS.md` and the nested `AGENTS.md` files applicable to changed paths.
+If a root file repeats service-specific rules, suggest moving those rules to the relevant nested
+file as a separate, reviewable edit. Preserve the rules' meaning; do not silently delete policy.
+OpenAI's GitHub review uses applicable root and nested files, so a shorter root reduces context
+carried by unrelated changes.
+
 ## 2. The loop (max 5 iterations)
 
 At the end of every invocation, post exactly one top-level PR conversation comment summarizing
@@ -106,11 +124,17 @@ head, so threads left open on purpose cannot make the push look reviewed.
 
 - Exit `10` (`findings`): go to B. On iteration 1 this is whatever Codex (or another bot)
   already posted.
-- Exit `20` (`pending`): post `@codex review` (`gh pr comment <PR> --body "@codex review"`). Then wait with the same command plus `--wait 600`. Run the
+- Exit `20` (`pending`): if automatic-review status is unknown, wait up to 600 seconds first so a
+  review already in progress can land. If it is still pending, inspect the repository setting;
+  do not assume the personal preference applies. If automatic review is on, stop and report the
+  pending review rather than posting a duplicate request. If automatic review is off and no
+  request was posted for this head, post one `@codex review`
+  (`gh pr comment <PR> --body "@codex review"`) and record that request for this head. Then wait
+  with the same command plus `--wait 600`. Run the
   wait in the background where the host allows it (Claude Code: Bash `run_in_background`; you are
   re-invoked when it exits) so ten minutes of polling never sits in the conversation. Still `20`
-  after the wait: say so out loud, post `@codex review` once more, and wait once more. Still `20` after that: stop and
-  report the timeout honestly; never claim success.
+  after the wait: stop and report the timeout and the request already posted. A repeat mention
+  can start another billable review; do not retry it automatically or claim success.
 - Exit `0` (`clean`): go to the exit check. A `--wait` call returns `clean` only after a settle
   re-read 60 seconds later, so a comment landing right behind the review is still caught. A bare
   read (no `--wait`) that says `clean` is good enough only when you have not pushed since Codex's

package/adapters/claude/olko-github-pr/skills/codexloop/SKILL.md

@@ -28,6 +28,9 @@ suggestion applied is worse than the comment itself.
 - **Trigger phrase is `@codex review`.** Codex reviews automatically when a PR opens or gets new
   commits if auto-review is enabled on the repo; the mention forces a fresh pass. Other useful
   mentions: `@codex review focus on <area>` for a scoped re-review.
+- **Review requests consume usage.** Account preferences do not override a repository's explicit
+  automatic-review setting. Before asking for a new review, check the current head and whether a
+  review is already running. Never request a second review merely because the first is slow.
 - **Priority, not confidence.** Codex findings usually lead with a severity/priority word (`P1`,
   `P2`, `P3` or `critical`/`major`/`minor`) or a short titled heading. Weight the top tier
   seriously; treat the bottom tier as usually-skippable nits unless clearly correct.
@@ -56,10 +59,11 @@ Pick the login matching `*codex*` (commonly `chatgpt-codex-connector[bot]`, some
 
 **Finding nothing here is NOT a stop condition.** On a PR Codex has never reviewed there is no bot
 login to find yet: that is the normal starting state, not a missing app. When the probe comes back
-empty, fall through to step A, post `@codex review`, and re-run this probe once a review lands;
-until then match any login containing `codex` when polling. Only conclude the app is absent after
-step A's bounded wait has expired with no review and no codex-like login anywhere on the PR, and
-then say so and stop, rather than looping against nothing.
+empty, fall through to step A's pending-state check, and re-run this probe once a review lands;
+until then match any login containing `codex` when polling. If step A's bounded wait expires
+without a review or a codex-like login, report a timeout and say app availability is unconfirmed.
+Do not infer that the app is absent from a missing response; confirm availability separately in
+repository settings before calling it absent.
 
 ## Review state comes from the PR, not from memory
 
@@ -90,6 +94,20 @@ gh pr view --json number,headRefName,headRefOid -q '{number,branch:.headRefName,
 
 Switch to the PR branch if not already on it. Capture `OWNER`/`REPO` (`gh repo view --json owner,name`).
 
+Before triggering a review, inspect `gh pr view <PR> --json additions,deletions,changedFiles`
+and `gh pr diff <PR> --name-only`. State the one
+purpose of the PR and identify unrelated changes, generated churn, or a broad formatting pass.
+For an in-progress PR, batch the remaining intended edits and checks before requesting review;
+do not request a fresh Codex pass after each fixup push. Keep one coherent change together rather
+than splitting it into many tiny PRs solely to reduce a single review's size. Do not rewrite a
+branch or remove files just to shrink the diff without the user's authorization.
+
+Read only the root `AGENTS.md` and the nested `AGENTS.md` files applicable to changed paths.
+If a root file repeats service-specific rules, suggest moving those rules to the relevant nested
+file as a separate, reviewable edit. Preserve the rules' meaning; do not silently delete policy.
+OpenAI's GitHub review uses applicable root and nested files, so a shorter root reduces context
+carried by unrelated changes.
+
 ## 2. The loop (max 5 iterations)
 
 At the end of every invocation, post exactly one top-level PR conversation comment summarizing
@@ -115,11 +133,17 @@ head, so threads left open on purpose cannot make the push look reviewed.
 
 - Exit `10` (`findings`): go to B. On iteration 1 this is whatever Codex (or another bot)
   already posted.
-- Exit `20` (`pending`): post `@codex review` (`gh pr comment <PR> --body "@codex review"`). Then wait with the same command plus `--wait 600`. Run the
+- Exit `20` (`pending`): if automatic-review status is unknown, wait up to 600 seconds first so a
+  review already in progress can land. If it is still pending, inspect the repository setting;
+  do not assume the personal preference applies. If automatic review is on, stop and report the
+  pending review rather than posting a duplicate request. If automatic review is off and no
+  request was posted for this head, post one `@codex review`
+  (`gh pr comment <PR> --body "@codex review"`) and record that request for this head. Then wait
+  with the same command plus `--wait 600`. Run the
   wait in the background where the host allows it (Claude Code: Bash `run_in_background`; you are
   re-invoked when it exits) so ten minutes of polling never sits in the conversation. Still `20`
-  after the wait: say so out loud, post `@codex review` once more, and wait once more. Still `20` after that: stop and
-  report the timeout honestly; never claim success.
+  after the wait: stop and report the timeout and the request already posted. A repeat mention
+  can start another billable review; do not retry it automatically or claim success.
 - Exit `0` (`clean`): go to the exit check. A `--wait` call returns `clean` only after a settle
   re-read 60 seconds later, so a comment landing right behind the review is still caught. A bare
   read (no `--wait`) that says `clean` is good enough only when you have not pushed since Codex's

package/adapters/claude/olko-github-pr/skills/lekker-review/SKILL.md

@@ -45,7 +45,7 @@ metadata:
     - multi-agent
     - workflow
     - quality
-argument-hint: "<github-pr-url | repo pr-number | repo pr-title | branch [ref]> [scan|medium|deep] [--post] [--fix] [--base <ref>]"
+argument-hint: "<github-pr-url | repo pr-number | repo pr-title | branch [ref]> [scan|medium|deep|deps] [--post] [--fix] [--base <ref>]"
 ---
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
 
@@ -245,11 +245,17 @@ Then:
 `LOCAL_BRANCH` is `main`, `master`, `develop`, `staging`, or `production`, stop
 and say so.
 
-**Depth:** explicit keyword `scan`, `medium`, or `deep` wins. If absent, get
-the diff stat - in `pr` mode from
-`gh pr view <PR_NUMBER> --repo <REPO_SLUG> --json additions,deletions,changedFiles`,
-in `branch` mode from `git diff --shortstat <MERGE_BASE> HEAD` plus
-`git diff --name-only <MERGE_BASE> HEAD | wc -l` - and apply AUTO-DEPTH:
+**Depth:** explicit keyword `scan`, `medium`, `deep` or `deps` wins. If absent,
+get the per-file stat - in `pr` mode from
+`gh pr view <PR_NUMBER> --repo <REPO_SLUG> --json additions,deletions,changedFiles,files,baseRefName,state,mergeCommit`
+(keep `baseRefName` as `BASE_BRANCH` and `changedFiles` as `EXPECTED_FILES` for
+Track A; when `state` is `MERGED`, keep `mergeCommit.oid` as `MERGE_COMMIT`), in `branch` mode from `git diff --numstat <MERGE_BASE> HEAD` - and
+apply AUTO-DEPTH. Lockfiles (`package-lock.json`, `npm-shrinkwrap.json`,
+`yarn.lock`, `pnpm-lock.yaml`, `bun.lock`, `bun.lockb`) do NOT count toward
+additions+deletions: a regenerated lockfile is thousands of lines nobody reads.
+- `deps` (candidate) if every changed file is a lockfile or a `package.json`.
+  Confirmed after Track A by `scripts/deps-only.mjs` (see "Confirm deps depth");
+  until then run Track B as for `scan`.
 - `scan` if additions+deletions < 150 AND changedFiles <= 5
 - `deep` if additions+deletions > 800 OR changedFiles > 25 OR diff touches
   `migrations/` or `*.sql`
@@ -272,7 +278,8 @@ still needs explicit confirmation (Step 4).
 
 **`--base <ref>` flag (branch mode only):** overrides base-ref detection. Passed
 through to the scripts as `LEKKER_BASE_REF`. Ignored in `pr` mode, where the
-base comes from the PR.
+base comes from the PR: Track A passes `LEKKER_BASE_REF=origin/<BASE_BRANCH>`
+itself, so the script fetches the base and diffs against its current tip.
 
 **`--no-fix` flag:** parse and store as `FIX_MODE=false`, and do not offer fixes
 in Step 4. Use it for a read-only pre-push look.
@@ -288,8 +295,8 @@ to `workflow` for `HOST=claude` and `codex` for `HOST=codex`. Reject an explicit
 engine that does not exist on the current host (`workflow` requires Claude's
 Workflow tool; `codex` requires Codex native collaboration). `revmux` is
 allowed only at depth `medium` or `deep` - revmux's
-scripts reject `scan` (see Depth gate). If depth resolves to `scan` (explicit
-or auto), force `ENGINE` back to the current host's native engine regardless of
+scripts reject `scan` (see Depth gate). If depth resolves to `scan` or `deps`
+(explicit or auto), force `ENGINE` back to the current host's native engine regardless of
 the flag and note `engine forced to <workflow|codex> - revmux needs
 medium/deep` in the review header.
 
@@ -310,19 +317,19 @@ page for this PR.
 
 ## Depth gate
 
-| Step                        | scan                  | medium              | deep                       |
-|-----------------------------|-----------------------|---------------------|----------------------------|
-| Context: issue-tracker/CI/diff/existing-reviews | always | always | always |
-| Context: chat/docs/framework-docs/monitoring/prior-review-memory (optional, MCP-dependent) | skip | included | included + broader recall |
-| Worktree + static checks    | skip (WORKTREE_PATH=null) unless `--fix` | included | included          |
-| Review agents               | 2 triage (haiku)      | 5 specialists (sonnet) | 5 specialists (sonnet)  |
-| Per-finding verification    | Criticals + Importants | Criticals + Importants | Criticals + Importants |
-| Completeness critic         | skip                  | skip                | included                   |
-| Proof-of-bug (failing test per Critical or composed-boundary Important) | skip     | included (max 5)    | included (max 5)           |
-| Living review artifact      | included              | included            | included                   |
-| Housekeeping (optional memory/notes writeback) | skip | included            | included                   |
-| `--post`                    | supported             | supported           | supported                  |
-| `--fix` / fix offer         | supported (forces worktree) | supported     | supported                  |
+| Step                        | 📦 deps               | scan                  | medium              | deep                       |
+|-----------------------------|-----------------------|-----------------------|---------------------|----------------------------|
+| Context: issue-tracker/CI/diff/existing-reviews | always | always | always | always |
+| Context: chat/docs/framework-docs/monitoring/prior-review-memory (optional, MCP-dependent) | skip | skip | included | included + broader recall |
+| Worktree + static checks    | included (`npm ci` per changed lockfile) | skip (WORKTREE_PATH=null) unless `--fix` | included | included          |
+| Review agents               | 1 deps checklist      | 2 triage (haiku)      | 5 specialists (sonnet) | 5 specialists (sonnet)  |
+| Per-finding verification    | none                  | Criticals + Importants | Criticals + Importants | Criticals + Importants |
+| Completeness critic         | skip                  | skip                  | skip                | included                   |
+| Proof-of-bug (failing test per Critical or composed-boundary Important) | skip | skip | included (max 5)    | included (max 5)           |
+| Living review artifact      | included              | included              | included            | included                   |
+| Housekeeping (optional memory/notes writeback) | skip | skip                | included            | included                   |
+| `--post`                    | supported             | supported             | supported           | supported                  |
+| `--fix` / fix offer         | supported             | supported (forces worktree) | supported     | supported                  |
 
 For scan: note `⚡ scan - worktree unavailable, static checks skipped` in the
 review header. When `--fix` forced the worktree at scan depth, drop that note
@@ -351,7 +358,19 @@ Fire both tracks in the same turn.
 Run via Bash with `run_in_background`:
 
 ```bash
-# MODE=pr - checks out origin/<PR_BRANCH>, fetching if needed
+# MODE=pr - fetches origin/<PR_BRANCH> AND origin/<BASE_BRANCH>, then checks out
+# the PR branch. Without the base fetch the merge-base is whatever this clone
+# last saw, and the file list widens (65 files instead of 9 on one PR).
+# LEKKER_EXPECTED_FILES lets the script report a list that still disagrees.
+LEKKER_BASE_REF=origin/<BASE_BRANCH> LEKKER_EXPECTED_FILES=<EXPECTED_FILES> \
+${SKILL_ROOT}/scripts/setup-worktree.sh \
+  <REPO_SLUG> <PR_BRANCH> <scratchpad>/worktree.json [PREV_SHA]
+
+# MODE=pr, PR already MERGED - the head is inside the base branch now, so
+# merge-base(head, origin/<BASE_BRANCH>) is the head and the diff is empty.
+# Diff against the base as it was just before the merge instead.
+LEKKER_BASE_BRANCH=<BASE_BRANCH> LEKKER_BASE_REF=<MERGE_COMMIT>^1 \
+LEKKER_EXPECTED_FILES=<EXPECTED_FILES> \
 ${SKILL_ROOT}/scripts/setup-worktree.sh \
   <REPO_SLUG> <PR_BRANCH> <scratchpad>/worktree.json [PREV_SHA]
 ```
@@ -369,7 +388,32 @@ ${SKILL_ROOT}/scripts/setup-worktree.sh \
 On completion, read `worktree.json`. Keys emitted:
 `worktreePath`, `repoRoot`, `headSha`, `headShaShort`, `tscTail`,
 `tscChangedTail`, `tscErrorCount`, `eslintTail`, `eslintScope`, `changedFiles`,
-`baseRef`, `mergeBase`, `projectRules`, `deltaFile`, `notes`.
+`baseRef`, `mergeBase`, `projectRules`, `deltaFile`, `notes`, `depsInstall`.
+
+`notes` containing `changed-files-mismatch:<got>-vs-<expected>` means the
+merge-base still disagrees with the PR. Use the `files` list from `gh pr view`
+as the changed-file list for the review header and agents, and say so in the
+header; the static-check scoping is the script's best effort.
+
+`depsInstall` is non-empty when the diff changed a lockfile: one row per
+lockfile dir, `{dir, status: ok|failed|timeout, tail?}`. The script ran
+`npm ci --ignore-scripts` there instead of symlinking the repo's
+`node_modules`, which holds the pre-PR dependency tree. A row that is not `ok`
+is evidence for the review (a lockfile `npm ci` rejects fails the deploy too),
+not a reason to stop. Set `LEKKER_NO_INSTALL=1` to skip the install. Lockfile
+dirs using yarn, pnpm or bun are not installed (note `deps-install-unsupported`).
+
+**Confirm deps depth** (only when Step 0 picked the `deps` candidate):
+
+```bash
+node ${SKILL_ROOT}/scripts/deps-only.mjs \
+  <worktreePath> <mergeBase> <changedFiles...> > <scratchpad>/deps-report.json
+```
+
+`kind: "deps"` confirms it; pass the report as `depsReport` in CONTEXT_FILE.
+`kind: "mixed"` (a `scripts`, `name` or other non-dependency key changed, or a
+`package.json` was added) means re-apply AUTO-DEPTH without the `deps` rule, and
+fetch the Track B sources the new depth includes before Step 2.
 
 `mergeBase` is the commit the file list was scoped against. Branch mode
 generates its diff from that exact sha (below), so the diff the agents read and
@@ -469,7 +513,10 @@ Write `<scratchpad>/context.json` with keys:
   "deltaFile":       "<worktree.json deltaFile, or null>",
   "houseRulesFile":  "${SKILL_ROOT}/references/house-rules.md",
   "reviewTarget":    "<TARGET_LABEL, e.g. 'PR #412' or 'branch feat/offline-orders'>",
-  "prePush":         "<true in MODE=branch, false in MODE=pr>"
+  "prePush":         "<true in MODE=branch, false in MODE=pr>",
+  "depsReport":      "<deps-report.json contents at depth deps, else null>",
+  "depsInstall":     "<worktree.json depsInstall>",
+  "prBody":          "<PR body at depth deps, else omit>"
 }
 ```
 
@@ -539,7 +586,7 @@ that only when a specific run needs a smaller footprint.
 
 The workflow runs three phases:
 
-- **Review:** scan uses `[triage-quality, triage-logic]` on `haiku`; medium/deep
+- **Review:** deps uses the single `deps` checklist agent; scan uses `[triage-quality, triage-logic]` on `haiku`; medium/deep
   use 5 specialists (quality, implementation, simplification, conventions,
   test-quality) on `sonnet`. Agents receive DIFF_FILE + CONTEXT_FILE by path.
   All five run concurrently: the stage is self-limiting at one agent per
@@ -552,8 +599,9 @@ The workflow runs three phases:
   description/badCode/fix of the set - a Critical is never demoted by an
   Observation someone else filed at the same line - and records every
   contributing dimension in `agreedBy`.
-- **Verify:** every Critical and Important is checked at every depth because it
-  can affect the verdict. Hard-rule findings (`rule` set) use the verifier's
+- **Verify:** every Critical and Important is checked at scan, medium and deep because it
+  can affect the verdict. The `deps` depth verifies nothing: its findings are advisory
+  checklist facts (audit delta, install result) with nothing for a verifier to refute. Hard-rule findings (`rule` set) use the verifier's
   diff-anchor and rule-applicability checks instead of runtime challenges.
   Each verifier runs the five-challenge adversarial refutation from
   `references/agents/verifier.md` against one finding, returns
@@ -728,6 +776,23 @@ codebase. Never on taste alone. These land in their own section, not in
 Critical/Important. A finding without a cited precedent from the codebase is
 dropped.
 
+**Validate line numbers first.** When there is a worktree, write the workflow's
+`findings` to `<scratchpad>/findings.json` and run
+
+```bash
+node ${SKILL_ROOT}/scripts/validate-lines.mjs \
+  <scratchpad>/findings.json <worktreePath>
+```
+
+It checks each `line` against the file at HEAD using the finding's `badCode`:
+kept when it is within 3 lines, re-anchored on a unique match
+(`lineRemapped: true`), or set to `null` when the code is not in the file
+(a `pr.diff` line number cited as a file line). Use the rewritten file from
+here on. A `null` line is a PR-level finding: cite the file without a line, and
+never post it as an inline comment. With no worktree (scan), skip this and do
+not claim the lines were checked. Print the summary counts only when something
+was remapped or nulled.
+
 **Pick the closer** (skip when `FUN=false`): once the verdict is decided, run
 the picker ONCE and keep its JSON as `CLOSER` for the rest of the run, so the
 terminal, saved file, artifact and GitHub body all show the same joke:
@@ -827,7 +892,10 @@ post.
 ## Step 3.5 - Living review artifact (skip when ARTIFACT=false)
 
 Immediately after printing the review, follow `references/artifact-page.md`.
-Claude publishes through Artifact. Codex uses a publish-capable artifact tool
+On Claude, the renderer subagent only writes the HTML and returns its path; the
+main loop fetches the closer image into a base64 `data:` URI file
+(`CLOSER_DATAURI_FILE`), reads the HTML, checks its `<title>` and that it has no
+external `<img>`, and publishes it through Artifact. Codex uses a publish-capable artifact tool
 when one is already available; otherwise it writes or updates the stable local
 self-contained HTML path defined there. The page is the living version of the
 review: verdict header, since-last-review timeline, findings with proof panels.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/agents/deps.md

@@ -0,0 +1,54 @@
+# deps - lekker-review agent prompt
+You will receive in your task message: REPO_SLUG, PR_NUMBER, PR_URL, DIFF_FILE, CONTEXT_FILE (JSON), WORKTREE_PATH.
+Your findings are returned via the StructuredOutput schema enforced by the caller.
+
+This PR changes only lockfiles and the dependency keys of `package.json`
+(`depsReport` in CONTEXT_FILE says which keys, per file). You are the ONLY
+reviewer, so cover the whole checklist. Skip lockfile churn line by line: a
+regenerated lockfile is not reviewable by eye, and the install and audit below
+are the evidence for it.
+
+Inputs from CONTEXT_FILE:
+- `depsReport`: `{ packageJsons: [{ file, depKeysChanged }], lockDirs }`.
+- `depsInstall`: per lockfile dir, `{ dir, status: ok|failed|timeout, tail? }`
+  from `npm ci --ignore-scripts` in the worktree. Empty means none ran.
+- `prBody`, `ciStatus`, `existingReviews` (skip anything already raised).
+
+Checklist, in order:
+
+1. **Reason per change.** Every added or raised version, and every new
+   `overrides`/`resolutions` entry, has a stated reason: an advisory id
+   (GHSA/CVE), a Dependabot alert, or a line in the PR body. No reason ->
+   `observation`.
+2. **Overrides that force a major.** For each override, read the dependant's
+   own declared range (`WORKTREE_PATH/<dir>/node_modules/<dependant>/package.json`
+   or `npm ls <pkg>` in that dir). An override pinning a major the dependant does
+   not declare -> `observation` asking for a removal ticket, naming the
+   condition that lets it go (dependant upgrade).
+3. **Runtime compatibility.** A new major that drops a Node version: compare
+   with `engines.node` and with the runtime image (`Dockerfile` `FROM`, CI
+   `node-version`). An actual mismatch -> `important`.
+4. **Install.** Any `depsInstall` row not `ok` -> `important`, quoting the tail.
+   A lockfile that `npm ci` rejects will fail the deploy too.
+5. **Audit delta.** In each `lockDirs` dir run
+   `npm audit --omit=dev --json` in WORKTREE_PATH (head), and compare with the
+   advisories the PR body says it fixes. A high/critical advisory still present
+   that the PR claims to fix -> `important`. One introduced by the bump ->
+   `important`. Pre-existing ones with no fix -> one `observation`, not one per
+   advisory. If `npm audit` cannot run (no network), say so in that observation;
+   never report it as clean.
+   Read the whole `prBody` first: when it already names the residual advisories
+   or says the audit check stays red, say that in the observation and ask for
+   nothing; never request a note the author already wrote.
+6. **Runtime vs dev.** Note which bumps reach production (`dependencies`) and
+   which are dev-only; a runtime major bump with no test or changelog note in
+   the PR body -> `observation`.
+
+Rules:
+- `file` + `line`: anchor on the `package.json` line of the dependency or
+  override (1-based line in the file at HEAD), never on a lockfile line.
+- `badCode`: that `package.json` line verbatim. `fix`: the concrete change or
+  the ticket to open.
+- No Critical findings: a dependency bump that breaks something shows up as a
+  failed install, a failed check or an advisory, which are `important`.
+- Do not re-review lockfile integrity hashes or resolved URLs.