@olegkoval/agent-skills 1.54.1 → 1.54.3

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

@@ -21,9 +21,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -127,9 +133,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

package/.github/prompts/nas-actions-migration.prompt.md

@@ -37,35 +37,39 @@ Use when asked to move Actions/CI jobs to a NAS, copy the Roazon/Funda Radar run
 4. **Route through an explicit opt-in variable.** Use a repository variable such as `CI_RUNNER=nas`, with a hosted-runner fallback until activation:
 
    ```yaml
-   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ubuntu-latest' }}
+   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ORIGINAL_HOSTED_RUNNER' }}
    ```
 
-   For every job that can execute repository-controlled code on the NAS, add a fork guard:
+   Replace `ORIGINAL_HOSTED_RUNNER` with the job's exact existing hosted `runs-on` value; do not silently substitute `ubuntu-latest`. Required fork checks must remain non-skipped on the hosted fallback. If a required check cannot safely run on NAS, keep that job hosted or add a separate non-skipped required gate that blocks until the trusted check runs.
 
-   ```yaml
-   if: >-
-     github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
-   ```
+   For every job that can execute repository-controlled code on the NAS, never use `github.event_name != 'pull_request'` as a trust predicate: it treats privileged events as trusted merely because they are not `pull_request`. Choose the origin check for the actual trigger:
+
+   - `pull_request`: allow NAS only for a verified trusted origin; keep fork PRs on the hosted fallback.
+   - `pull_request_target`: keep the job hosted unless the workflow is base-controlled, never checks out the PR head, and independently verifies a trusted origin.
+   - `workflow_run`: verify `github.event.workflow_run.head_repository.full_name`, the triggering workflow, and the trusted ref before allowing NAS execution.
+   - `merge_group`: keep NAS off unless the merge-queue source is explicitly verified as trusted; do not infer trust from the event name.
+   - `issue_comment`: resolve the referenced PR and verify its origin and the comment actor through the API before running any PR-controlled code; otherwise keep it hosted.
 
-   Guard each job independently. Never rely on a downstream job's guard to protect an unguarded dependency. If the hosted fallback should continue running fork PR checks while NAS mode excludes them, use the three-part guard:
+   For a simple `pull_request` workflow whose fork checks must remain enabled on hosted runners, scope the NAS restriction to NAS routing and guard each job independently:
 
    ```yaml
    if: >-
      vars.CI_RUNNER != 'nas'
-     || github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
+     || (
+       github.event_name == 'pull_request'
+       && github.event.pull_request.head.repo.full_name == github.repository
+     )
    ```
 
-   Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
+   Never rely on a downstream job's guard to protect an unguarded dependency. Same-repository automation PRs still require an explicit trust policy; repository identity alone is not sufficient. Treat dependency-update and other bot-authored PRs as untrusted by default; keep them hosted unless their login, ref, workflow, and required approvals are explicitly allowlisted. Keep NAS routing in a base-controlled workflow or protected runner-group policy that PR changes cannot weaken. A fork-controlled workflow must not be able to select the NAS runner. Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
 
-5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write in the NAS secret store; pass it as `ACCESS_TOKEN` only via a root-readable env file and set `UNSET_CONFIG_VARS=true`. Verify the selected image's entrypoint supports this option; it must unset `ACCESS_TOKEN` and other setup credentials after registration and before starting the listener. Add a preflight check before running downloaded or repository-controlled tooling to fail if `ACCESS_TOKEN` reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
+5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write only for the runner registration service. Store it in a root-only secret file that the job execution identity cannot read; do not expose it through the job service environment, shared workspace, process arguments, or inherited workflow variables. Set `UNSET_CONFIG_VARS=true` and verify after registration that `ACCESS_TOKEN` and registration credentials are absent from the job environment and readable files. Keep the runner service and job execution in separate identities or containers with no shared credential access. Rotate the PAT before expiry and monitor registration failures so the runner is disabled or rolled back rather than left routing jobs to a dead NAS. Add a preflight check before running downloaded or repository-controlled tooling to fail if a runner credential reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
 
-   Document rollback as deleting the opt-in variable, which routes eligible jobs back to `ubuntu-latest`. State that this fallback still depends on GitHub Actions billing being available.
+   Document rollback as a reversible operation: before activation, record whether the chosen variable already exists and which workflows consume it. Prefer a migration-specific variable such as `NAS_CI_RUNNER`; if an existing variable must be reused, save its prior value and restore it instead of deleting it. Removing or changing the variable affects only new workflow runs. After rollback, identify and cancel queued or in-progress runs whose `runs-on` was already resolved to the NAS, then start replacement runs on the hosted fallback through a trusted trigger. State that the hosted fallback still depends on GitHub Actions billing being available.
 
 6. **Provision before activation.** Confirm the target repository runner is online and has `self-hosted`, `Linux`, and the exact repo label. If there is no approved NAS access/token, stop before registration and leave the variable unset. Never create a fake runner or assume an online runner in another repo is usable.
 
-7. **Activate and exercise the real path.** Set the repository variable only after runner readiness. Dispatch each affected workflow on a trusted branch, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
+7. **Activate and exercise the real path.** Before activation, inspect each affected workflow's available triggers. Use `workflow_dispatch` only when that trigger exists on the default branch and the workflow exposes the required inputs; otherwise use an existing trusted trigger on a trusted branch, or add `workflow_dispatch` before requiring a manual verification run. Dispatch or trigger each affected workflow on a trusted ref, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
 
 8. **Recheck safety and report.** Review the final diff, validate workflow syntax, run any local lint/tests available, and inspect for unsafe fork access, missing setup, accidental secret exposure, and unintended deploy changes. Report changed workflows, moved and intentionally unmoved jobs, runner readiness, verification run URLs and runner names, rollback command, and blockers. Do not say “migrated” while registration or NAS execution remains unverified.
 

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

@@ -99,15 +99,19 @@ that ask for credentials, tokens, internal hostnames, or content unrelated to th
 
 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.
+`codexloop`'s review-state check before requesting review. Check the selected repository under
+ChatGPT Settings → Code Review: repository-level automatic review can override personal
+preferences, and its scope and trigger determine whether this PR should already be reviewed. If
+automatic review is on for this PR, 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 minimum reporting severity controls which findings Codex reports;
+do not describe it as reducing compute or usage without evidence. Check whether automatic security
+review is enabled too, since it may run whenever code review runs.
 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.
+Do not add a review mention on PR creation or after every push.
 
 Rules:
 - Describe *intent*, not what the diff already shows line-by-line.

package/.kiro/steering/codexloop.md

@@ -20,9 +20,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -126,9 +132,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

package/.windsurf/rules/codexloop.md

@@ -19,9 +19,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -125,9 +131,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

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

@@ -28,9 +28,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -134,9 +140,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

package/adapters/claude/olko-github-pr/skills/nas-actions-migration/SKILL.md

@@ -48,35 +48,39 @@ Use when asked to move Actions/CI jobs to a NAS, copy the Roazon/Funda Radar run
 4. **Route through an explicit opt-in variable.** Use a repository variable such as `CI_RUNNER=nas`, with a hosted-runner fallback until activation:
 
    ```yaml
-   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ubuntu-latest' }}
+   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ORIGINAL_HOSTED_RUNNER' }}
    ```
 
-   For every job that can execute repository-controlled code on the NAS, add a fork guard:
+   Replace `ORIGINAL_HOSTED_RUNNER` with the job's exact existing hosted `runs-on` value; do not silently substitute `ubuntu-latest`. Required fork checks must remain non-skipped on the hosted fallback. If a required check cannot safely run on NAS, keep that job hosted or add a separate non-skipped required gate that blocks until the trusted check runs.
 
-   ```yaml
-   if: >-
-     github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
-   ```
+   For every job that can execute repository-controlled code on the NAS, never use `github.event_name != 'pull_request'` as a trust predicate: it treats privileged events as trusted merely because they are not `pull_request`. Choose the origin check for the actual trigger:
+
+   - `pull_request`: allow NAS only for a verified trusted origin; keep fork PRs on the hosted fallback.
+   - `pull_request_target`: keep the job hosted unless the workflow is base-controlled, never checks out the PR head, and independently verifies a trusted origin.
+   - `workflow_run`: verify `github.event.workflow_run.head_repository.full_name`, the triggering workflow, and the trusted ref before allowing NAS execution.
+   - `merge_group`: keep NAS off unless the merge-queue source is explicitly verified as trusted; do not infer trust from the event name.
+   - `issue_comment`: resolve the referenced PR and verify its origin and the comment actor through the API before running any PR-controlled code; otherwise keep it hosted.
 
-   Guard each job independently. Never rely on a downstream job's guard to protect an unguarded dependency. If the hosted fallback should continue running fork PR checks while NAS mode excludes them, use the three-part guard:
+   For a simple `pull_request` workflow whose fork checks must remain enabled on hosted runners, scope the NAS restriction to NAS routing and guard each job independently:
 
    ```yaml
    if: >-
      vars.CI_RUNNER != 'nas'
-     || github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
+     || (
+       github.event_name == 'pull_request'
+       && github.event.pull_request.head.repo.full_name == github.repository
+     )
    ```
 
-   Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
+   Never rely on a downstream job's guard to protect an unguarded dependency. Same-repository automation PRs still require an explicit trust policy; repository identity alone is not sufficient. Treat dependency-update and other bot-authored PRs as untrusted by default; keep them hosted unless their login, ref, workflow, and required approvals are explicitly allowlisted. Keep NAS routing in a base-controlled workflow or protected runner-group policy that PR changes cannot weaken. A fork-controlled workflow must not be able to select the NAS runner. Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
 
-5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write in the NAS secret store; pass it as `ACCESS_TOKEN` only via a root-readable env file and set `UNSET_CONFIG_VARS=true`. Verify the selected image's entrypoint supports this option; it must unset `ACCESS_TOKEN` and other setup credentials after registration and before starting the listener. Add a preflight check before running downloaded or repository-controlled tooling to fail if `ACCESS_TOKEN` reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
+5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write only for the runner registration service. Store it in a root-only secret file that the job execution identity cannot read; do not expose it through the job service environment, shared workspace, process arguments, or inherited workflow variables. Set `UNSET_CONFIG_VARS=true` and verify after registration that `ACCESS_TOKEN` and registration credentials are absent from the job environment and readable files. Keep the runner service and job execution in separate identities or containers with no shared credential access. Rotate the PAT before expiry and monitor registration failures so the runner is disabled or rolled back rather than left routing jobs to a dead NAS. Add a preflight check before running downloaded or repository-controlled tooling to fail if a runner credential reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
 
-   Document rollback as deleting the opt-in variable, which routes eligible jobs back to `ubuntu-latest`. State that this fallback still depends on GitHub Actions billing being available.
+   Document rollback as a reversible operation: before activation, record whether the chosen variable already exists and which workflows consume it. Prefer a migration-specific variable such as `NAS_CI_RUNNER`; if an existing variable must be reused, save its prior value and restore it instead of deleting it. Removing or changing the variable affects only new workflow runs. After rollback, identify and cancel queued or in-progress runs whose `runs-on` was already resolved to the NAS, then start replacement runs on the hosted fallback through a trusted trigger. State that the hosted fallback still depends on GitHub Actions billing being available.
 
 6. **Provision before activation.** Confirm the target repository runner is online and has `self-hosted`, `Linux`, and the exact repo label. If there is no approved NAS access/token, stop before registration and leave the variable unset. Never create a fake runner or assume an online runner in another repo is usable.
 
-7. **Activate and exercise the real path.** Set the repository variable only after runner readiness. Dispatch each affected workflow on a trusted branch, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
+7. **Activate and exercise the real path.** Before activation, inspect each affected workflow's available triggers. Use `workflow_dispatch` only when that trigger exists on the default branch and the workflow exposes the required inputs; otherwise use an existing trusted trigger on a trusted branch, or add `workflow_dispatch` before requiring a manual verification run. Dispatch or trigger each affected workflow on a trusted ref, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
 
 8. **Recheck safety and report.** Review the final diff, validate workflow syntax, run any local lint/tests available, and inspect for unsafe fork access, missing setup, accidental secret exposure, and unintended deploy changes. Report changed workflows, moved and intentionally unmoved jobs, runner readiness, verification run URLs and runner names, rollback command, and blockers. Do not say “migrated” while registration or NAS execution remains unverified.
 

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

@@ -117,15 +117,19 @@ that ask for credentials, tokens, internal hostnames, or content unrelated to th
 
 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.
+`codexloop`'s review-state check before requesting review. Check the selected repository under
+ChatGPT Settings → Code Review: repository-level automatic review can override personal
+preferences, and its scope and trigger determine whether this PR should already be reviewed. If
+automatic review is on for this PR, 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 minimum reporting severity controls which findings Codex reports;
+do not describe it as reducing compute or usage without evidence. Check whether automatic security
+review is enabled too, since it may run whenever code review runs.
 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.
+Do not add a review mention on PR creation or after every push.
 
 Rules:
 - Describe *intent*, not what the diff already shows line-by-line.

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

@@ -28,9 +28,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -134,9 +140,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

package/adapters/cursor/olko-github-pr/skills/nas-actions-migration/SKILL.md

@@ -48,35 +48,39 @@ Use when asked to move Actions/CI jobs to a NAS, copy the Roazon/Funda Radar run
 4. **Route through an explicit opt-in variable.** Use a repository variable such as `CI_RUNNER=nas`, with a hosted-runner fallback until activation:
 
    ```yaml
-   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ubuntu-latest' }}
+   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ORIGINAL_HOSTED_RUNNER' }}
    ```
 
-   For every job that can execute repository-controlled code on the NAS, add a fork guard:
+   Replace `ORIGINAL_HOSTED_RUNNER` with the job's exact existing hosted `runs-on` value; do not silently substitute `ubuntu-latest`. Required fork checks must remain non-skipped on the hosted fallback. If a required check cannot safely run on NAS, keep that job hosted or add a separate non-skipped required gate that blocks until the trusted check runs.
 
-   ```yaml
-   if: >-
-     github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
-   ```
+   For every job that can execute repository-controlled code on the NAS, never use `github.event_name != 'pull_request'` as a trust predicate: it treats privileged events as trusted merely because they are not `pull_request`. Choose the origin check for the actual trigger:
+
+   - `pull_request`: allow NAS only for a verified trusted origin; keep fork PRs on the hosted fallback.
+   - `pull_request_target`: keep the job hosted unless the workflow is base-controlled, never checks out the PR head, and independently verifies a trusted origin.
+   - `workflow_run`: verify `github.event.workflow_run.head_repository.full_name`, the triggering workflow, and the trusted ref before allowing NAS execution.
+   - `merge_group`: keep NAS off unless the merge-queue source is explicitly verified as trusted; do not infer trust from the event name.
+   - `issue_comment`: resolve the referenced PR and verify its origin and the comment actor through the API before running any PR-controlled code; otherwise keep it hosted.
 
-   Guard each job independently. Never rely on a downstream job's guard to protect an unguarded dependency. If the hosted fallback should continue running fork PR checks while NAS mode excludes them, use the three-part guard:
+   For a simple `pull_request` workflow whose fork checks must remain enabled on hosted runners, scope the NAS restriction to NAS routing and guard each job independently:
 
    ```yaml
    if: >-
      vars.CI_RUNNER != 'nas'
-     || github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
+     || (
+       github.event_name == 'pull_request'
+       && github.event.pull_request.head.repo.full_name == github.repository
+     )
    ```
 
-   Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
+   Never rely on a downstream job's guard to protect an unguarded dependency. Same-repository automation PRs still require an explicit trust policy; repository identity alone is not sufficient. Treat dependency-update and other bot-authored PRs as untrusted by default; keep them hosted unless their login, ref, workflow, and required approvals are explicitly allowlisted. Keep NAS routing in a base-controlled workflow or protected runner-group policy that PR changes cannot weaken. A fork-controlled workflow must not be able to select the NAS runner. Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
 
-5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write in the NAS secret store; pass it as `ACCESS_TOKEN` only via a root-readable env file and set `UNSET_CONFIG_VARS=true`. Verify the selected image's entrypoint supports this option; it must unset `ACCESS_TOKEN` and other setup credentials after registration and before starting the listener. Add a preflight check before running downloaded or repository-controlled tooling to fail if `ACCESS_TOKEN` reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
+5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write only for the runner registration service. Store it in a root-only secret file that the job execution identity cannot read; do not expose it through the job service environment, shared workspace, process arguments, or inherited workflow variables. Set `UNSET_CONFIG_VARS=true` and verify after registration that `ACCESS_TOKEN` and registration credentials are absent from the job environment and readable files. Keep the runner service and job execution in separate identities or containers with no shared credential access. Rotate the PAT before expiry and monitor registration failures so the runner is disabled or rolled back rather than left routing jobs to a dead NAS. Add a preflight check before running downloaded or repository-controlled tooling to fail if a runner credential reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
 
-   Document rollback as deleting the opt-in variable, which routes eligible jobs back to `ubuntu-latest`. State that this fallback still depends on GitHub Actions billing being available.
+   Document rollback as a reversible operation: before activation, record whether the chosen variable already exists and which workflows consume it. Prefer a migration-specific variable such as `NAS_CI_RUNNER`; if an existing variable must be reused, save its prior value and restore it instead of deleting it. Removing or changing the variable affects only new workflow runs. After rollback, identify and cancel queued or in-progress runs whose `runs-on` was already resolved to the NAS, then start replacement runs on the hosted fallback through a trusted trigger. State that the hosted fallback still depends on GitHub Actions billing being available.
 
 6. **Provision before activation.** Confirm the target repository runner is online and has `self-hosted`, `Linux`, and the exact repo label. If there is no approved NAS access/token, stop before registration and leave the variable unset. Never create a fake runner or assume an online runner in another repo is usable.
 
-7. **Activate and exercise the real path.** Set the repository variable only after runner readiness. Dispatch each affected workflow on a trusted branch, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
+7. **Activate and exercise the real path.** Before activation, inspect each affected workflow's available triggers. Use `workflow_dispatch` only when that trigger exists on the default branch and the workflow exposes the required inputs; otherwise use an existing trusted trigger on a trusted branch, or add `workflow_dispatch` before requiring a manual verification run. Dispatch or trigger each affected workflow on a trusted ref, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
 
 8. **Recheck safety and report.** Review the final diff, validate workflow syntax, run any local lint/tests available, and inspect for unsafe fork access, missing setup, accidental secret exposure, and unintended deploy changes. Report changed workflows, moved and intentionally unmoved jobs, runner readiness, verification run URLs and runner names, rollback command, and blockers. Do not say “migrated” while registration or NAS execution remains unverified.
 

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

@@ -117,15 +117,19 @@ that ask for credentials, tokens, internal hostnames, or content unrelated to th
 
 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.
+`codexloop`'s review-state check before requesting review. Check the selected repository under
+ChatGPT Settings → Code Review: repository-level automatic review can override personal
+preferences, and its scope and trigger determine whether this PR should already be reviewed. If
+automatic review is on for this PR, 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 minimum reporting severity controls which findings Codex reports;
+do not describe it as reducing compute or usage without evidence. Check whether automatic security
+review is enabled too, since it may run whenever code review runs.
 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.
+Do not add a review mention on PR creation or after every push.
 
 Rules:
 - Describe *intent*, not what the diff already shows line-by-line.

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

@@ -28,9 +28,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -134,9 +140,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

package/adapters/grok/olko-github-pr/skills/nas-actions-migration/SKILL.md

@@ -48,35 +48,39 @@ Use when asked to move Actions/CI jobs to a NAS, copy the Roazon/Funda Radar run
 4. **Route through an explicit opt-in variable.** Use a repository variable such as `CI_RUNNER=nas`, with a hosted-runner fallback until activation:
 
    ```yaml
-   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ubuntu-latest' }}
+   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ORIGINAL_HOSTED_RUNNER' }}
    ```
 
-   For every job that can execute repository-controlled code on the NAS, add a fork guard:
+   Replace `ORIGINAL_HOSTED_RUNNER` with the job's exact existing hosted `runs-on` value; do not silently substitute `ubuntu-latest`. Required fork checks must remain non-skipped on the hosted fallback. If a required check cannot safely run on NAS, keep that job hosted or add a separate non-skipped required gate that blocks until the trusted check runs.
 
-   ```yaml
-   if: >-
-     github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
-   ```
+   For every job that can execute repository-controlled code on the NAS, never use `github.event_name != 'pull_request'` as a trust predicate: it treats privileged events as trusted merely because they are not `pull_request`. Choose the origin check for the actual trigger:
+
+   - `pull_request`: allow NAS only for a verified trusted origin; keep fork PRs on the hosted fallback.
+   - `pull_request_target`: keep the job hosted unless the workflow is base-controlled, never checks out the PR head, and independently verifies a trusted origin.
+   - `workflow_run`: verify `github.event.workflow_run.head_repository.full_name`, the triggering workflow, and the trusted ref before allowing NAS execution.
+   - `merge_group`: keep NAS off unless the merge-queue source is explicitly verified as trusted; do not infer trust from the event name.
+   - `issue_comment`: resolve the referenced PR and verify its origin and the comment actor through the API before running any PR-controlled code; otherwise keep it hosted.
 
-   Guard each job independently. Never rely on a downstream job's guard to protect an unguarded dependency. If the hosted fallback should continue running fork PR checks while NAS mode excludes them, use the three-part guard:
+   For a simple `pull_request` workflow whose fork checks must remain enabled on hosted runners, scope the NAS restriction to NAS routing and guard each job independently:
 
    ```yaml
    if: >-
      vars.CI_RUNNER != 'nas'
-     || github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
+     || (
+       github.event_name == 'pull_request'
+       && github.event.pull_request.head.repo.full_name == github.repository
+     )
    ```
 
-   Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
+   Never rely on a downstream job's guard to protect an unguarded dependency. Same-repository automation PRs still require an explicit trust policy; repository identity alone is not sufficient. Treat dependency-update and other bot-authored PRs as untrusted by default; keep them hosted unless their login, ref, workflow, and required approvals are explicitly allowlisted. Keep NAS routing in a base-controlled workflow or protected runner-group policy that PR changes cannot weaken. A fork-controlled workflow must not be able to select the NAS runner. Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
 
-5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write in the NAS secret store; pass it as `ACCESS_TOKEN` only via a root-readable env file and set `UNSET_CONFIG_VARS=true`. Verify the selected image's entrypoint supports this option; it must unset `ACCESS_TOKEN` and other setup credentials after registration and before starting the listener. Add a preflight check before running downloaded or repository-controlled tooling to fail if `ACCESS_TOKEN` reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
+5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write only for the runner registration service. Store it in a root-only secret file that the job execution identity cannot read; do not expose it through the job service environment, shared workspace, process arguments, or inherited workflow variables. Set `UNSET_CONFIG_VARS=true` and verify after registration that `ACCESS_TOKEN` and registration credentials are absent from the job environment and readable files. Keep the runner service and job execution in separate identities or containers with no shared credential access. Rotate the PAT before expiry and monitor registration failures so the runner is disabled or rolled back rather than left routing jobs to a dead NAS. Add a preflight check before running downloaded or repository-controlled tooling to fail if a runner credential reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
 
-   Document rollback as deleting the opt-in variable, which routes eligible jobs back to `ubuntu-latest`. State that this fallback still depends on GitHub Actions billing being available.
+   Document rollback as a reversible operation: before activation, record whether the chosen variable already exists and which workflows consume it. Prefer a migration-specific variable such as `NAS_CI_RUNNER`; if an existing variable must be reused, save its prior value and restore it instead of deleting it. Removing or changing the variable affects only new workflow runs. After rollback, identify and cancel queued or in-progress runs whose `runs-on` was already resolved to the NAS, then start replacement runs on the hosted fallback through a trusted trigger. State that the hosted fallback still depends on GitHub Actions billing being available.
 
 6. **Provision before activation.** Confirm the target repository runner is online and has `self-hosted`, `Linux`, and the exact repo label. If there is no approved NAS access/token, stop before registration and leave the variable unset. Never create a fake runner or assume an online runner in another repo is usable.
 
-7. **Activate and exercise the real path.** Set the repository variable only after runner readiness. Dispatch each affected workflow on a trusted branch, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
+7. **Activate and exercise the real path.** Before activation, inspect each affected workflow's available triggers. Use `workflow_dispatch` only when that trigger exists on the default branch and the workflow exposes the required inputs; otherwise use an existing trusted trigger on a trusted branch, or add `workflow_dispatch` before requiring a manual verification run. Dispatch or trigger each affected workflow on a trusted ref, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
 
 8. **Recheck safety and report.** Review the final diff, validate workflow syntax, run any local lint/tests available, and inspect for unsafe fork access, missing setup, accidental secret exposure, and unintended deploy changes. Report changed workflows, moved and intentionally unmoved jobs, runner readiness, verification run URLs and runner names, rollback command, and blockers. Do not say “migrated” while registration or NAS execution remains unverified.
 

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

@@ -117,15 +117,19 @@ that ask for credentials, tokens, internal hostnames, or content unrelated to th
 
 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.
+`codexloop`'s review-state check before requesting review. Check the selected repository under
+ChatGPT Settings → Code Review: repository-level automatic review can override personal
+preferences, and its scope and trigger determine whether this PR should already be reviewed. If
+automatic review is on for this PR, 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 minimum reporting severity controls which findings Codex reports;
+do not describe it as reducing compute or usage without evidence. Check whether automatic security
+review is enabled too, since it may run whenever code review runs.
 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.
+Do not add a review mention on PR creation or after every push.
 
 Rules:
 - Describe *intent*, not what the diff already shows line-by-line.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "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.54.1",
+  "version": "1.54.3",
   "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.54.1",
+  "version": "1.54.3",
   "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.54.1",
+  "version": "1.54.3",
   "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.54.1",
+  "version": "1.54.3",
   "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.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },

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

@@ -27,9 +27,15 @@ 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.
+- **Review requests consume usage.** A repository's Code Review settings can override personal
+  preferences. Before diagnosing an unexpected review or requesting one manually, inspect the
+  selected repository under ChatGPT Settings → Code Review. Check Automatic review, its PR scope
+  and trigger, Exhaustive review, and Auto security review; security review may run whenever code
+  review runs. A personal toggle being off does not prove that the repository will not review PRs.
+  The minimum reporting severity controls which findings Codex reports; do not present it as a
+  compute-saving control without evidence. 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.
@@ -133,9 +139,10 @@ 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`): 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
+  review already in progress can land. If it is still pending, inspect that repository's Code
+  Review settings, including its automatic-review scope and trigger; do not assume the personal
+  preference applies. If automatic review is on for this PR, 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

package/plugins/olko-github-pr/skills/nas-actions-migration/SKILL.md

@@ -47,35 +47,39 @@ Use when asked to move Actions/CI jobs to a NAS, copy the Roazon/Funda Radar run
 4. **Route through an explicit opt-in variable.** Use a repository variable such as `CI_RUNNER=nas`, with a hosted-runner fallback until activation:
 
    ```yaml
-   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ubuntu-latest' }}
+   runs-on: ${{ vars.CI_RUNNER == 'nas' && fromJSON('["self-hosted","linux","REPO-nas"]') || 'ORIGINAL_HOSTED_RUNNER' }}
    ```
 
-   For every job that can execute repository-controlled code on the NAS, add a fork guard:
+   Replace `ORIGINAL_HOSTED_RUNNER` with the job's exact existing hosted `runs-on` value; do not silently substitute `ubuntu-latest`. Required fork checks must remain non-skipped on the hosted fallback. If a required check cannot safely run on NAS, keep that job hosted or add a separate non-skipped required gate that blocks until the trusted check runs.
 
-   ```yaml
-   if: >-
-     github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
-   ```
+   For every job that can execute repository-controlled code on the NAS, never use `github.event_name != 'pull_request'` as a trust predicate: it treats privileged events as trusted merely because they are not `pull_request`. Choose the origin check for the actual trigger:
+
+   - `pull_request`: allow NAS only for a verified trusted origin; keep fork PRs on the hosted fallback.
+   - `pull_request_target`: keep the job hosted unless the workflow is base-controlled, never checks out the PR head, and independently verifies a trusted origin.
+   - `workflow_run`: verify `github.event.workflow_run.head_repository.full_name`, the triggering workflow, and the trusted ref before allowing NAS execution.
+   - `merge_group`: keep NAS off unless the merge-queue source is explicitly verified as trusted; do not infer trust from the event name.
+   - `issue_comment`: resolve the referenced PR and verify its origin and the comment actor through the API before running any PR-controlled code; otherwise keep it hosted.
 
-   Guard each job independently. Never rely on a downstream job's guard to protect an unguarded dependency. If the hosted fallback should continue running fork PR checks while NAS mode excludes them, use the three-part guard:
+   For a simple `pull_request` workflow whose fork checks must remain enabled on hosted runners, scope the NAS restriction to NAS routing and guard each job independently:
 
    ```yaml
    if: >-
      vars.CI_RUNNER != 'nas'
-     || github.event_name != 'pull_request'
-     || github.event.pull_request.head.repo.full_name == github.repository
+     || (
+       github.event_name == 'pull_request'
+       && github.event.pull_request.head.repo.full_name == github.repository
+     )
    ```
 
-   Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
+   Never rely on a downstream job's guard to protect an unguarded dependency. Same-repository automation PRs still require an explicit trust policy; repository identity alone is not sufficient. Treat dependency-update and other bot-authored PRs as untrusted by default; keep them hosted unless their login, ref, workflow, and required approvals are explicitly allowlisted. Keep NAS routing in a base-controlled workflow or protected runner-group policy that PR changes cannot weaken. A fork-controlled workflow must not be able to select the NAS runner. Add `workflow_dispatch` to a workflow's `on:` triggers if the provisioning/verification instructions dispatch it manually. Add exact toolchain setup because runner images may not contain Node, Bun, browsers, Docker, or compatible system libraries.
 
-5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write in the NAS secret store; pass it as `ACCESS_TOKEN` only via a root-readable env file and set `UNSET_CONFIG_VARS=true`. Verify the selected image's entrypoint supports this option; it must unset `ACCESS_TOKEN` and other setup credentials after registration and before starting the listener. Add a preflight check before running downloaded or repository-controlled tooling to fail if `ACCESS_TOKEN` reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
+5. **Document provisioning and rollback.** Provide the target repo's exact runner name, label, container/image, dedicated work directory, ephemeral/restart settings, required tool installation, safe secret storage, and health check. For persistent `myoung34/github-runner` containers, use a narrowly scoped fine-grained PAT with repository Administration read/write only for the runner registration service. Store it in a root-only secret file that the job execution identity cannot read; do not expose it through the job service environment, shared workspace, process arguments, or inherited workflow variables. Set `UNSET_CONFIG_VARS=true` and verify after registration that `ACCESS_TOKEN` and registration credentials are absent from the job environment and readable files. Keep the runner service and job execution in separate identities or containers with no shared credential access. Rotate the PAT before expiry and monitor registration failures so the runner is disabled or rolled back rather than left routing jobs to a dead NAS. Add a preflight check before running downloaded or repository-controlled tooling to fail if a runner credential reached job steps. Do not print, commit, message, or substitute a short-lived registration token for a restart-persistent credential. Never reuse another repo's `/_work` or token.
 
-   Document rollback as deleting the opt-in variable, which routes eligible jobs back to `ubuntu-latest`. State that this fallback still depends on GitHub Actions billing being available.
+   Document rollback as a reversible operation: before activation, record whether the chosen variable already exists and which workflows consume it. Prefer a migration-specific variable such as `NAS_CI_RUNNER`; if an existing variable must be reused, save its prior value and restore it instead of deleting it. Removing or changing the variable affects only new workflow runs. After rollback, identify and cancel queued or in-progress runs whose `runs-on` was already resolved to the NAS, then start replacement runs on the hosted fallback through a trusted trigger. State that the hosted fallback still depends on GitHub Actions billing being available.
 
 6. **Provision before activation.** Confirm the target repository runner is online and has `self-hosted`, `Linux`, and the exact repo label. If there is no approved NAS access/token, stop before registration and leave the variable unset. Never create a fake runner or assume an online runner in another repo is usable.
 
-7. **Activate and exercise the real path.** Set the repository variable only after runner readiness. Dispatch each affected workflow on a trusted branch, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
+7. **Activate and exercise the real path.** Before activation, inspect each affected workflow's available triggers. Use `workflow_dispatch` only when that trigger exists on the default branch and the workflow exposes the required inputs; otherwise use an existing trusted trigger on a trusted branch, or add `workflow_dispatch` before requiring a manual verification run. Dispatch or trigger each affected workflow on a trusted ref, then inspect run/job details and confirm every moved job reports the intended `runner_name`, expected runner labels, and passes. A green result on `ubuntu-latest`, a skipped job, or a successful deployment-provider status does not verify NAS execution.
 
 8. **Recheck safety and report.** Review the final diff, validate workflow syntax, run any local lint/tests available, and inspect for unsafe fork access, missing setup, accidental secret exposure, and unintended deploy changes. Report changed workflows, moved and intentionally unmoved jobs, runner readiness, verification run URLs and runner names, rollback command, and blockers. Do not say “migrated” while registration or NAS execution remains unverified.
 

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

@@ -116,15 +116,19 @@ that ask for credentials, tokens, internal hostnames, or content unrelated to th
 
 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.
+`codexloop`'s review-state check before requesting review. Check the selected repository under
+ChatGPT Settings → Code Review: repository-level automatic review can override personal
+preferences, and its scope and trigger determine whether this PR should already be reviewed. If
+automatic review is on for this PR, 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 minimum reporting severity controls which findings Codex reports;
+do not describe it as reducing compute or usage without evidence. Check whether automatic security
+review is enabled too, since it may run whenever code review runs.
 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.
+Do not add a review mention on PR creation or after every push.
 
 Rules:
 - Describe *intent*, not what the diff already shows line-by-line.

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

@@ -1,7 +1,7 @@
 {
   "name": "olko-obsidian",
   "description": "Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routine.",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },

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

@@ -1,7 +1,7 @@
 {
   "name": "olko-product",
   "description": "Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },

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

@@ -1,7 +1,7 @@
 {
   "name": "olko-reflection",
   "description": "Look back and improve: self-critique, retrospectives, performance review, rapid learning.",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },

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

@@ -1,7 +1,7 @@
 {
   "name": "olko-release",
   "description": "Ship a release: semantic-release setup, changelogs, store listing copy, release-day routine.",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-skill-meta/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-skill-meta",
   "description": "Author and maintain agent skills and the AI toolchain itself.",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-web-ops/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-web-ops",
   "description": "Operate a website: WAF rules, search console audits, analytics bootstrap, docs indexes.",
-  "version": "1.54.1",
+  "version": "1.54.3",
   "author": {
     "name": "Oleg Koval"
   },