@olegkoval/agent-skills 1.52.0 → 1.53.0

package/adapters/claude/olko-github-pr/skills/lekker-review/scripts/validate-lines.mjs

@@ -0,0 +1,122 @@
+#!/usr/bin/env node
+// Checks every finding's `line` against the file at HEAD before synthesis.
+// Reviewers sometimes cite a line number of pr.diff instead of the file (a
+// 2026-10-15 finding said package.json:398 for code at line 70), and an
+// inline GitHub comment on the wrong line is worse than none.
+//
+//   node validate-lines.mjs <findings.json> <worktreePath>
+//
+// <findings.json> is an array or { findings: [...] }; it is rewritten in
+// place, same shape. For each finding whose file exists in the worktree:
+//   - badCode's first non-blank line within +-3 of `line` -> kept
+//   - otherwise one unique match in the file -> re-anchored, lineRemapped: true
+//   - no match -> line: null (the finding becomes PR-level, not inline)
+//   - several matches -> kept, lineAmbiguous: true
+// Then dedup (lifted from workflow.js) merges findings that now share an anchor.
+// Prints a one-line JSON summary on stdout.
+import { readFileSync, writeFileSync, existsSync, realpathSync } from 'node:fs'
+import { fileURLToPath } from 'node:url'
+import { dirname, join, resolve, sep } from 'node:path'
+
+const WINDOW = 3
+const SKILL = dirname(dirname(fileURLToPath(import.meta.url)))
+
+function candidates(badCode) {
+  const first = String(badCode || '').split('\n').map(l => l.trim()).find(l => l.length > 0)
+  if (!first) return []
+  // Agents copy from the diff and sometimes keep its "+" marker.
+  const unmarked = first.replace(/^\+\s?/, '').trim()
+  return [...new Set([first, unmarked])].filter(Boolean)
+}
+
+function matches(fileLine, cands) {
+  const t = fileLine.trim()
+  return cands.some(c => t === c || (c.length >= 12 && t.includes(c)))
+}
+
+export function anchor(finding, fileLines) {
+  const cands = candidates(finding.badCode)
+  if (cands.length === 0 || !Number.isInteger(finding.line)) return { finding, outcome: 'unchecked' }
+  const near = []
+  for (let n = Math.max(1, finding.line - WINDOW); n <= Math.min(fileLines.length, finding.line + WINDOW); n++) {
+    if (matches(fileLines[n - 1], cands)) near.push(n)
+  }
+  if (near.length > 0) return { finding, outcome: 'kept' }
+  const hits = []
+  fileLines.forEach((l, i) => { if (matches(l, cands)) hits.push(i + 1) })
+  if (hits.length === 1) {
+    return { finding: { ...finding, line: hits[0], originalLine: finding.line, lineRemapped: true }, outcome: 'remapped' }
+  }
+  if (hits.length === 0) {
+    return { finding: { ...finding, line: null, originalLine: finding.line }, outcome: 'nulled' }
+  }
+  return { finding: { ...finding, lineAmbiguous: true }, outcome: 'ambiguous' }
+}
+
+// Same source-lift selftest.mjs uses: workflow.js runs inside the Workflow
+// harness and cannot be imported, so its dedup is extracted by brace matching.
+export function loadDedup(workflowPath = join(SKILL, 'workflow.js')) {
+  const src = readFileSync(workflowPath, 'utf8')
+  const lift = name => {
+    const i = src.indexOf(`function ${name}`)
+    if (i === -1) throw new Error(`function ${name} not found in workflow.js`)
+    let d = 0, j = i
+    for (;; j++) {
+      if (src[j] === '{') d++
+      else if (src[j] === '}') { d--; if (d === 0) break }
+    }
+    return src.slice(i, j + 1)
+  }
+  const liftConst = (name, fallback) => {
+    const m = new RegExp(`^const ${name} = .*$`, 'm').exec(src)
+    return m ? m[0] : fallback
+  }
+  const preamble = [
+    liftConst('HARD_RULES', 'const HARD_RULES = new Set()'),
+    liftConst('SAME_ISSUE_LINE_WINDOW', 'const SAME_ISSUE_LINE_WINDOW = 30'),
+    liftConst('SEVERITY_RANK', 'const SEVERITY_RANK = { critical: 3, important: 2, observation: 1, idiomatic: 0 }'),
+    ...['titleTokens', 'sameIssue', 'nearbyLines', 'spanWithinWindow',
+        'isHardRule', 'longest', 'mergeFindings', 'dedup'].map(lift),
+  ].join('\n')
+  return new Function(preamble + '\nreturn dedup')()
+}
+
+export function validate(findings, worktree, dedup) {
+  const root = resolve(worktree)
+  const summary = { kept: 0, remapped: 0, nulled: 0, ambiguous: 0, unchecked: 0, merged: 0 }
+  const cache = new Map()
+  const out = findings.map(f => {
+    const path = resolve(root, String(f.file || ''))
+    if (!f.file || !path.startsWith(root + sep) || !existsSync(path)) {
+      summary.unchecked++
+      return f
+    }
+    if (!cache.has(path)) cache.set(path, readFileSync(path, 'utf8').split('\n'))
+    const { finding, outcome } = anchor(f, cache.get(path))
+    summary[outcome]++
+    return finding
+  })
+  // dedup compares line distances, so only anchored findings go through it.
+  const anchored = out.filter(f => Number.isInteger(f.line))
+  const rest = out.filter(f => !Number.isInteger(f.line))
+  const merged = summary.remapped > 0 && dedup ? dedup(anchored) : anchored
+  summary.merged = anchored.length - merged.length
+  return { findings: merged.concat(rest), summary }
+}
+
+function isMain() {
+  try { return realpathSync(process.argv[1]) === realpathSync(fileURLToPath(import.meta.url)) } catch { return false }
+}
+
+if (isMain()) {
+  const [file, worktree] = process.argv.slice(2)
+  if (!file || !worktree) {
+    console.error('usage: validate-lines.mjs <findings.json> <worktreePath>')
+    process.exit(2)
+  }
+  const raw = JSON.parse(readFileSync(file, 'utf8'))
+  const list = Array.isArray(raw) ? raw : (raw.findings || [])
+  const { findings, summary } = validate(list, worktree, loadDedup())
+  writeFileSync(file, JSON.stringify(Array.isArray(raw) ? findings : { ...raw, findings }, null, 2))
+  console.log(JSON.stringify(summary))
+}

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

@@ -7,7 +7,7 @@ description: >
   Chains naturally after git-commit and before qodoloop / coderabbitloop.
 license: MIT
 allowed-tools: Bash, Read, Write
-compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git, jq, and gh (GitHub CLI) authenticated.
 metadata:
   targets: [_source-only]
   author: Oleg Koval
@@ -52,11 +52,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
 
@@ -104,6 +115,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/adapters/cursor/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/cursor/olko-github-pr/skills/pr-description-writer/SKILL.md

@@ -7,7 +7,7 @@ description: >
   Chains naturally after git-commit and before qodoloop / coderabbitloop.
 license: MIT
 allowed-tools: Bash, Read, Write
-compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git, jq, and gh (GitHub CLI) authenticated.
 metadata:
   targets: [_source-only]
   author: Oleg Koval
@@ -52,11 +52,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
 
@@ -104,6 +115,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/adapters/grok/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/grok/olko-github-pr/skills/pr-description-writer/SKILL.md

@@ -7,7 +7,7 @@ description: >
   Chains naturally after git-commit and before qodoloop / coderabbitloop.
 license: MIT
 allowed-tools: Bash, Read, Write
-compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git, jq, and gh (GitHub CLI) authenticated.
 metadata:
   targets: [_source-only]
   author: Oleg Koval
@@ -52,11 +52,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
 
@@ -104,6 +115,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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.52.0",
+  "version": "1.53.0",
   "private": false,
   "publishConfig": {
     "access": "public"

package/plugins/olko-apple-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-apple-kit",
   "description": "Build and ship Apple platform apps: macOS menubar apps, App Store submissions.",
-  "version": "1.52.0",
+  "version": "1.53.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-creative/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-creative",
   "description": "Creative and personal projects: photo galleries, music players, listings, wiki editing.",
-  "version": "1.52.0",
+  "version": "1.53.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-garmin-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-garmin-kit",
   "description": "Build, test and publish Garmin Connect IQ watch faces.",
-  "version": "1.52.0",
+  "version": "1.53.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-git-tools/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-git-tools",
   "description": "Everyday git and GitHub CLI operations: conventional commits, branch hygiene.",
-  "version": "1.52.0",
+  "version": "1.53.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-github-pr",
   "description": "Drive GitHub pull requests to merge-ready: review-bot loops, CI fixes, descriptions, dependency triage.",
-  "version": "1.52.0",
+  "version": "1.53.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/skills/codexloop/SKILL.md

@@ -27,6 +27,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.
@@ -55,10 +58,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
 
@@ -89,6 +93,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
@@ -114,11 +132,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