@olegkoval/agent-skills 1.36.0 → 1.37.0

package/README.md

@@ -174,6 +174,15 @@ Drive GitHub pull requests to merge-ready: review-bot loops, CI fixes, descripti
 | [dependabot-triage](plugins/olko-github-pr/skills/dependabot-triage/SKILL.md) | Triages open Dependabot and Renovate PRs in bulk: classifies by risk tier, auto-approves safe patch bumps, flags breaking major upgrades for human review, and posts a digest | Clearing a backlog of dependency update PRs during a maintenance window |
 | [lekker-review](plugins/olko-github-pr/skills/lekker-review/SKILL.md) | Runs a FAANG-quality PR review in an isolated worktree: 5 parallel specialist agents, adversarial finding verification, proof-of-bug tests for Criticals, and an optional --fix mode that applies and commits its own findings (Claude Code only, needs the Workflow tool) | Reviewing a GitHub PR beyond what a single-pass review or a bot reviewer catches |
 
+#### lekker-review at a glance
+
+Full write-up in the [skill README](plugins/olko-github-pr/skills/lekker-review/README.md).
+
+![The five specialist agents, the severity tiers, and the approval standard](plugins/olko-github-pr/skills/lekker-review/assets/poster-overview.png)
+
+![Adversarial refutation, the hard-rule exemption, proof of bug, and the fix-mode proof flip](plugins/olko-github-pr/skills/lekker-review/assets/poster-proof.png)
+
+
 ### olko-git-tools (3)
 
 Everyday git and GitHub CLI operations: conventional commits, branch hygiene.

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

@@ -330,6 +330,50 @@ anchors. Apply your own judgment to every finding.
 - Pre-existing code not touched by this diff
 - Anything you are not confident about - omit rather than hedge
 
+**Approval standard.** The verdict answers "does this definitely improve the
+codebase's health", not "is this how I would have written it". Perfect code does
+not exist. `✅ LGTM - ship it` is the right call for a change that improves
+health and violates no hard rule, even with open Observations or Idiomatic
+findings. Reserve `🚫 Needs work` for an unfixed Critical, a hard-rule
+violation, or an Important finding that changes external behaviour or data
+shape. Never manufacture a Critical to justify a verdict, and never block on
+taste.
+
+**PR sizing.** Judge how much a reviewer must hold at once, not the raw diff
+count:
+- Under ~300 changed lines, or larger but one logical change: no finding.
+- Over ~800 changed lines spanning more than one logical change: `important`,
+  and name the split. Pick the strategy that fits - stack (sequential
+  dependencies), by file group (different reviewers), horizontal (shared code
+  and stubs first, then consumers), vertical (smaller full-stack slices).
+- A diff that both refactors existing code and adds new behaviour: `important`
+  at any size. Those are two PRs, and bundling them hides the real change.
+- A change that pushes a single file past ~1000 total lines with no
+  decomposition: `observation`. Ask for the extraction first, then the feature.
+Exempt: whole-file deletions and mechanical or automated refactors, where the
+reviewer verifies intent rather than every line.
+
+**Verify the verification.** Read the PR body for the author's verification
+story: which tests were run, whether the build passed, whether it was exercised
+manually, screenshots for a UI change, a before/after for a behaviour or
+performance change. A non-trivial PR whose body claims nothing about
+verification is an `observation` naming the evidence that is missing. `CI: ✅
+All passing` is not a verification story - it only says the suite that already
+existed still runs.
+
+**Rationalizations to reject.** If one of these is the reason a finding is about
+to be dropped or softened, keep the finding:
+
+| Rationalization | Reality |
+|---|---|
+| "The tests pass, so it's fine" | Tests do not catch architecture, security, or data-shape problems. |
+| "It works, that's good enough" | Working code that is unreadable or insecure is debt that compounds. |
+| "The refactor makes it cleaner" | Relocating complexity is not reducing it. Count the concepts a reader holds. |
+| "It's only a small addition to this file" | Judge the resulting structure, not the diff size. |
+| "It's just a version bump" | A bump is a behaviour change nobody in the PR wrote. |
+| "They'll clean it up later" | Later does not come. Require it now, or require a ticket. |
+| "An agent wrote it, so it's probably fine" | Generated code needs more scrutiny, not less: it is confident and plausible when wrong. |
+
 **Idiomatic & Consistency exception:** the conventions agent raises non-blocking
 suggestions ONLY when a concrete better pattern provably already exists in the
 codebase. Never on taste alone. These land in their own section, not in

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

@@ -36,6 +36,24 @@ Axes to cover:
 - No JavaScript files (TS-2): if the diff adds any `.js` file to a non-Liquid
   theme repo, flag as Critical — must be `.ts`. Set `rule: "TS-2"` on the
   finding.
+- Dependency changes. Skip this axis entirely unless the diff touches
+  `package.json`, a lockfile, or a vendored dependency. Where it applies:
+  (a) A version bump is a behaviour change nobody in this PR wrote. If neither
+      the PR body nor a commit message cites the changelog or migration notes,
+      that is `important`: semver is a promise the maintainer may not have kept,
+      and a "patch" can carry a behavioural change.
+  (b) A bulk bump of several unrelated packages in one PR is `important`. When
+      it breaks the build you have lost which package did it. The `fix` is to
+      split it per package, or per genuinely related group.
+  (c) When the repository tracks a committed lockfile, a `package.json`
+      dependency change with no matching lockfile change in the same diff is
+      `critical`: the lockfile is what actually ships. A lockfile change with no
+      `package.json` change and no explanation is also `critical`. Do not require
+      a lockfile from a repository that intentionally does not commit one.
+  (d) A new direct dependency that duplicates something already in the stack is
+      `important`. Name the existing thing that already solves it.
+  Raise NO naming, comment, complexity, or hard-rule finding inside a lockfile
+  or a `node_modules` path.
 
 Setting rule tags the finding as a house hard rule: it keeps its Critical
 severity and skips adversarial verification. Only set it for a genuine

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

@@ -20,10 +20,39 @@ Look for:
   anti-pattern (handler → service → repo with no logic in any layer).
 - Feature flags always on/off, fallback that can never trigger, dual
   implementations where old has no callers.
+- Relocated complexity: a refactor that moves code without reducing the number
+  of concepts a reader must hold to follow it. Count them before and after, but
+  an unchanged count alone is not a finding. Flag only when the move leaves a
+  concrete residual coupling, duplication, branch, or bug-surface maintenance
+  risk, and name both that risk and the cheaper move available (deleting a
+  branch, a mode, or a layer outright, rather than re-centralising the same
+  logic). `important` when the PR is sold as a cleanup or refactor,
+  `observation` otherwise.
+- Feature logic in a shared module: feature-specific behaviour added to a
+  general-purpose util, a shared client, or a base class. The branch belongs in
+  the package that owns the concept. Name the owning layer in the `fix`.
+- Dead code this diff orphans: when the diff replaces or reroutes something,
+  grep the worktree for remaining callers of what it superseded (the old helper,
+  the old component, a now-unreferenced constant, a flag that can no longer be
+  false). Enumerate what is now unreachable. NEVER propose a silent deletion:
+  the `fix` lists the orphans and asks the author to confirm removal.
+  `observation`, or `important` when the dead path is still reachable from
+  production code. When WORKTREE_PATH is null in scan mode, do not infer absent
+  callers from the diff: mark orphan analysis unverified and request
+  worktree-backed verification instead.
 
 Only flag where duplication or complexity creates a real maintenance risk or
 bug surface — not aesthetic preference.
 
+When you flag a structural problem, name the move, not just the smell: replace a
+chain of conditionals with a typed model or an explicit dispatcher, collapse
+duplicate branches into one flow, separate orchestration from business logic,
+move feature logic into the package that owns it, reuse the canonical helper
+instead of a near-duplicate, delete a pass-through wrapper. Prefer the remedy
+that removes moving pieces over one that spreads the same complexity around. A
+finding that says "this is complex" without naming the restructuring is not
+actionable: name the move or drop the finding.
+
 EXISTING_REVIEWS: read key "existingReviews" from CONTEXT_FILE (awareness only — skip findings already raised)
 
 PROJECT_RULES to verify: read key "projectRules" from CONTEXT_FILE.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/output-format.md

@@ -140,6 +140,36 @@ proof inline.>
 
 ---
 
+## 📋 PR-level findings
+
+PR-level findings have no single file:line. Render them with this dedicated
+contract instead of demoting them to Observations because a location is absent:
+
+For an `important` sizing finding:
+
+### #N — Sizing
+
+**Scope:** PR-level · **Severity:** Important
+
+**Risk:** <why the PR cannot be reviewed safely as presented>
+
+**Action:** <the recommended split and strategy>
+
+For a missing verification story:
+
+### Verification story — action required
+
+**Missing evidence:** <tests run, manual exercise, screenshots for UI, or
+before/after for behaviour or performance>
+
+**Action:** <exactly what the author must add to the PR description>
+
+An `important` sizing finding counts toward the Important total and continues
+the finding-number sequence. Missing verification evidence is an explicit
+action, not a no-action Observation.
+
+*(Omit section entirely if empty.)*
+
 ## 📝 Observations
 
 - <note — tradeoff, risk to watch, or design question worth raising>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.36.0",
+  "version": "1.37.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.36.0",
+  "version": "1.37.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.36.0",
+  "version": "1.37.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.36.0",
+  "version": "1.37.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.36.0",
+  "version": "1.37.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.36.0",
+  "version": "1.37.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/skills/lekker-review/README.md

@@ -0,0 +1,60 @@
+# lekker-review
+
+FAANG-quality PR code review for GitHub. It gathers the context a human reviewer
+would gather and checks the branch out into an isolated worktree when the depth
+requires one. `scan` runs two triage agents without a verifier. `medium` and
+`deep` run five specialists and attempt proofs for at most five non-rule
+Critical findings.
+
+![lekker-review at a glance](assets/poster-overview.png)
+
+## Why it is not a checklist reviewer
+
+Most review tooling reports whatever the model believed on its first pass.
+This skill spends most of its budget trying to disprove itself.
+
+![How findings are proved](assets/poster-proof.png)
+
+- **Adversarial verification.** `medium` sends non-rule Criticals through an
+  independent verifier's five-challenge refutation; `deep` also sends
+  Importants. `scan` does not run verifiers.
+- **Proof of bug.** In `medium` and `deep`, up to five non-rule Criticals are
+  sent to prover agents that attempt to write and run a failing test. A proof
+  that comes back green is counter-evidence: the finding is downgraded or
+  explicitly justified, never quietly kept.
+- **Hard-rule exemption.** A finding tagged with a `rule` keeps Critical
+  severity and skips verification, because the verifier asks runtime-failure
+  questions that a standards violation can never answer.
+- **Fix mode.** `--fix` has one agent edit each file, a read-only verifier read
+  the real `git diff`, and the captured proof re-run. If the proof stays red the
+  group is reverted. Nothing is pushed without explicit confirmation.
+
+## Requirements
+
+Claude Code only. The review pipeline needs the Workflow tool for multi-agent
+orchestration and the Artifact tool for the living review page. `git` and an
+authenticated `gh` are required.
+
+## Setup
+
+`references/house-rules.md` ships as a template. Replace its example rules with
+your team's own non-negotiables, the ones that should always be Critical
+regardless of review depth. The skill has no hard rules of its own: everything
+blocking comes from that file.
+
+## Usage
+
+```text
+lekker-review https://github.com/owner/repo/pull/123
+lekker-review owner/repo 123 deep --post
+lekker-review owner/repo 123 --fix
+```
+
+Depth is auto-selected from the diff size when you do not name one: `scan` under
+150 changed lines and 5 files, `deep` over 800 changed lines or 25 files or when
+the diff touches migrations or `*.sql`, `medium` otherwise.
+
+## Regenerating the posters
+
+The posters are self-contained HTML in `assets/`. Open either file in a browser
+at a 1280x720 viewport and screenshot it to regenerate the PNG.

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

@@ -329,6 +329,50 @@ anchors. Apply your own judgment to every finding.
 - Pre-existing code not touched by this diff
 - Anything you are not confident about - omit rather than hedge
 
+**Approval standard.** The verdict answers "does this definitely improve the
+codebase's health", not "is this how I would have written it". Perfect code does
+not exist. `✅ LGTM - ship it` is the right call for a change that improves
+health and violates no hard rule, even with open Observations or Idiomatic
+findings. Reserve `🚫 Needs work` for an unfixed Critical, a hard-rule
+violation, or an Important finding that changes external behaviour or data
+shape. Never manufacture a Critical to justify a verdict, and never block on
+taste.
+
+**PR sizing.** Judge how much a reviewer must hold at once, not the raw diff
+count:
+- Under ~300 changed lines, or larger but one logical change: no finding.
+- Over ~800 changed lines spanning more than one logical change: `important`,
+  and name the split. Pick the strategy that fits - stack (sequential
+  dependencies), by file group (different reviewers), horizontal (shared code
+  and stubs first, then consumers), vertical (smaller full-stack slices).
+- A diff that both refactors existing code and adds new behaviour: `important`
+  at any size. Those are two PRs, and bundling them hides the real change.
+- A change that pushes a single file past ~1000 total lines with no
+  decomposition: `observation`. Ask for the extraction first, then the feature.
+Exempt: whole-file deletions and mechanical or automated refactors, where the
+reviewer verifies intent rather than every line.
+
+**Verify the verification.** Read the PR body for the author's verification
+story: which tests were run, whether the build passed, whether it was exercised
+manually, screenshots for a UI change, a before/after for a behaviour or
+performance change. A non-trivial PR whose body claims nothing about
+verification is an `observation` naming the evidence that is missing. `CI: ✅
+All passing` is not a verification story - it only says the suite that already
+existed still runs.
+
+**Rationalizations to reject.** If one of these is the reason a finding is about
+to be dropped or softened, keep the finding:
+
+| Rationalization | Reality |
+|---|---|
+| "The tests pass, so it's fine" | Tests do not catch architecture, security, or data-shape problems. |
+| "It works, that's good enough" | Working code that is unreadable or insecure is debt that compounds. |
+| "The refactor makes it cleaner" | Relocating complexity is not reducing it. Count the concepts a reader holds. |
+| "It's only a small addition to this file" | Judge the resulting structure, not the diff size. |
+| "It's just a version bump" | A bump is a behaviour change nobody in the PR wrote. |
+| "They'll clean it up later" | Later does not come. Require it now, or require a ticket. |
+| "An agent wrote it, so it's probably fine" | Generated code needs more scrutiny, not less: it is confident and plausible when wrong. |
+
 **Idiomatic & Consistency exception:** the conventions agent raises non-blocking
 suggestions ONLY when a concrete better pattern provably already exists in the
 codebase. Never on taste alone. These land in their own section, not in

package/plugins/olko-github-pr/skills/lekker-review/assets/poster-overview.html

@@ -0,0 +1,204 @@
+<!doctype html>
+<html lang="en">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=1280, initial-scale=1">
+  <title>Lekker Review Overview</title>
+  <style>
+    * { box-sizing: border-box; }
+    html, body { width: 1280px; height: 720px; margin: 0; overflow: hidden; }
+    body {
+      color: #e8e8e8;
+      background: radial-gradient(circle at 0 0, rgba(255, 200, 60, 0.05), transparent 38%), #0d0d0d;
+      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
+    }
+    .poster {
+      width: 1280px;
+      height: 720px;
+      padding: 40px;
+      display: grid;
+      grid-template-rows: 62px 38px 220px 128px 60px 22px;
+      gap: 16px;
+      align-content: space-between;
+      overflow: hidden;
+    }
+    h1 {
+      margin: 0 0 8px;
+      color: #f5c542;
+      font: 700 30px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      letter-spacing: 0.06em;
+    }
+    .subtitle { margin: 0; color: #9a9a9a; font-size: 15px; line-height: 1.35; white-space: nowrap; }
+    .pipeline { display: flex; align-items: center; gap: 8px; min-width: 0; }
+    .step {
+      height: 38px;
+      padding: 0 13px;
+      display: flex;
+      align-items: center;
+      justify-content: center;
+      color: #9a9a9a;
+      background: #161616;
+      border: 1px solid #2c2c2c;
+      border-radius: 8px;
+      font: 13px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      white-space: nowrap;
+    }
+    .step.hot { color: #f5c542; border-color: #f5c542; }
+    .arrow { flex: 0 0 auto; color: #555; font: 15px/1 ui-monospace, "SFMono-Regular", Menlo, monospace; }
+    .cards { display: flex; gap: 16px; min-width: 0; }
+    .card {
+      flex: 1 1 0;
+      min-width: 0;
+      height: 220px;
+      padding: 16px;
+      background: #161616;
+      border: 1px solid #262626;
+      border-radius: 10px;
+      overflow: hidden;
+    }
+    .kicker {
+      margin: 0 0 8px;
+      color: #f5c542;
+      font: 700 11px/1.2 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      letter-spacing: 0.11em;
+      text-transform: uppercase;
+    }
+    h2 { margin: 0 0 14px; font-size: 19px; line-height: 1.1; font-weight: 600; }
+    .claims { display: grid; gap: 9px; }
+    .claim { margin: 0; color: #9a9a9a; font-size: 12.5px; line-height: 1.38; }
+    .panel {
+      padding: 14px 16px;
+      background: #161616;
+      border: 1px solid #262626;
+      border-radius: 10px;
+      overflow: hidden;
+    }
+    .panel-title {
+      margin: 0 0 10px;
+      color: #f5c542;
+      font: 700 11px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      letter-spacing: 0.11em;
+    }
+    .severity-row { display: flex; flex-wrap: wrap; gap: 10px; min-width: 0; margin-bottom: 10px; }
+    .chip {
+      flex: 1 1 0;
+      min-width: 0;
+      padding: 7px 10px;
+      color: #8a8a8a;
+      background: #1e1e1e;
+      border: 1px solid #2c2c2c;
+      border-radius: 6px;
+      font: 11.5px/1.15 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      white-space: normal;
+    }
+    .chip strong { color: #e8e8e8; font-weight: 700; }
+    .chip.critical { color: #f0dcdc; background: #a35c60; border-color: #a35c60; }
+    .chip.critical strong { color: #f0dcdc; }
+    .rule { margin: 0; color: #e8e8e8; font-size: 12.5px; line-height: 1.25; font-weight: 600; }
+    .statement {
+      display: flex;
+      align-items: center;
+      color: #e8e8e8;
+      font-size: 18px;
+      line-height: 1.2;
+      font-weight: 600;
+    }
+    footer {
+      display: flex;
+      align-items: end;
+      justify-content: space-between;
+      color: #6a6a6a;
+      font: 11.5px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      white-space: nowrap;
+    }
+  </style>
+</head>
+<body>
+  <main class="poster">
+    <header>
+      <h1>LEKKER REVIEW</h1>
+      <p class="subtitle">Depth selects two triage agents or five specialists; verification follows depth. Nothing is pushed without confirmation.</p>
+    </header>
+
+    <section class="pipeline" aria-label="Review pipeline">
+      <div class="step">parse input</div><span class="arrow">→</span>
+      <div class="step">context + worktree</div><span class="arrow">→</span>
+      <div class="step">review agents</div><span class="arrow">→</span>
+      <div class="step hot">verify + prove</div><span class="arrow">→</span>
+      <div class="step">synthesize</div><span class="arrow">→</span>
+      <div class="step">fix / post</div>
+    </section>
+
+    <section class="cards" aria-label="Review agents">
+      <article class="card">
+        <p class="kicker">AGENT 01</p>
+        <h2>Quality</h2>
+        <div class="claims">
+          <p class="claim">Business logic</p>
+          <p class="claim">Data integrity and security</p>
+          <p class="claim">Error handling and scalability</p>
+          <p class="claim">Pre-existing code stays out of scope</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">AGENT 02</p>
+        <h2>Implementation</h2>
+        <div class="claims">
+          <p class="claim">Integration contracts</p>
+          <p class="claim">Migration safety</p>
+          <p class="claim">CI failures feed Critical findings</p>
+          <p class="claim">External behavior and data shape</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">AGENT 03</p>
+        <h2>Simplification</h2>
+        <div class="claims">
+          <p class="claim">Count reader-held concepts</p>
+          <p class="claim">Relocating is not reducing</p>
+          <p class="claim">Split refactor from behavior</p>
+          <p class="claim">Ignore 2-3 duplicated lines</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">AGENT 04</p>
+        <h2>Conventions</h2>
+        <div class="claims">
+          <p class="claim">Existing precedent required</p>
+          <p class="claim">Cite the precedent</p>
+          <p class="claim">Taste alone is dropped</p>
+          <p class="claim">Idiomatic findings never block</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">AGENT 05</p>
+        <h2>Test Quality</h2>
+        <div class="claims">
+          <p class="claim">Coverage verdict</p>
+          <p class="claim">Mutation-slip risk</p>
+          <p class="claim">Mock smells and gaps</p>
+          <p class="claim">Would tests catch a regression?</p>
+        </div>
+      </article>
+    </section>
+
+    <section class="panel" aria-label="Severity tiers">
+      <p class="panel-title">SEVERITY</p>
+      <div class="severity-row">
+        <div class="chip critical"><strong>Critical</strong> / blocks the merge</div>
+        <div class="chip"><strong>Important</strong> / should fix</div>
+        <div class="chip"><strong>Observation</strong> / worth raising</div>
+        <div class="chip"><strong>Idiomatic</strong> / cited precedent</div>
+      </div>
+      <p class="rule">Critical and Important cover real failure risk; adopter-defined hard-rule violations also remain Critical. No nitpicking.</p>
+    </section>
+
+    <div class="statement">Approve when the change definitely improves codebase health, violates no hard rule, and leaves only non-blocking findings.</div>
+
+    <footer>
+      <span>AUTO: SCAN additions+deletions &lt;150 AND ≤5 files · DEEP &gt;800 OR &gt;25 files OR migrations/ OR *.sql · MEDIUM otherwise</span>
+      <span>lekker-review</span>
+    </footer>
+  </main>
+</body>
+</html>

package/plugins/olko-github-pr/skills/lekker-review/assets/poster-proof.html

@@ -0,0 +1,199 @@
+<!doctype html>
+<html lang="en">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=1280, initial-scale=1">
+  <title>Lekker Review Proof</title>
+  <style>
+    * { box-sizing: border-box; }
+    html, body { width: 1280px; height: 720px; margin: 0; overflow: hidden; }
+    body {
+      color: #e8e8e8;
+      background: radial-gradient(circle at 0 0, rgba(255, 200, 60, 0.05), transparent 38%), #0d0d0d;
+      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
+    }
+    .poster {
+      width: 1280px;
+      height: 720px;
+      padding: 40px;
+      display: grid;
+      grid-template-rows: 62px 38px 286px 86px 66px 22px;
+      gap: 16px;
+      overflow: hidden;
+    }
+    h1 {
+      margin: 0 0 8px;
+      color: #f5c542;
+      font: 700 30px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      letter-spacing: 0.06em;
+    }
+    .subtitle { margin: 0; color: #9a9a9a; font-size: 15px; line-height: 1.35; white-space: nowrap; }
+    .pipeline { display: flex; align-items: center; gap: 8px; min-width: 0; }
+    .step {
+      height: 38px;
+      padding: 0 14px;
+      display: flex;
+      align-items: center;
+      justify-content: center;
+      color: #9a9a9a;
+      background: #161616;
+      border: 1px solid #2c2c2c;
+      border-radius: 8px;
+      font: 13px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      white-space: nowrap;
+    }
+    .step.hot { color: #f5c542; border-color: #f5c542; }
+    .arrow { flex: 0 0 auto; color: #555; font: 15px/1 ui-monospace, "SFMono-Regular", Menlo, monospace; }
+    .cards { display: flex; gap: 16px; min-width: 0; }
+    .card {
+      flex: 1 1 0;
+      min-width: 0;
+      height: 286px;
+      padding: 16px;
+      background: #161616;
+      border: 1px solid #262626;
+      border-radius: 10px;
+      overflow: hidden;
+    }
+    .kicker {
+      margin: 0 0 8px;
+      color: #f5c542;
+      font: 700 11px/1.2 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      letter-spacing: 0.11em;
+    }
+    h2 { margin: 0 0 14px; font-size: 19px; line-height: 1.1; font-weight: 600; }
+    .claims { display: grid; gap: 9px; }
+    .claim { margin: 0; color: #9a9a9a; font-size: 12.5px; line-height: 1.38; }
+    .claim strong { color: #e8e8e8; font-weight: 600; }
+    .panel {
+      padding: 13px 16px;
+      background: #161616;
+      border: 1px solid #262626;
+      border-radius: 10px;
+      display: flex;
+      align-items: center;
+      gap: 14px;
+      overflow: hidden;
+    }
+    .panel-title {
+      flex: 0 0 auto;
+      margin: 0;
+      color: #f5c542;
+      font: 700 11px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      letter-spacing: 0.11em;
+    }
+    .chip {
+      flex: 0 0 auto;
+      padding: 8px 11px;
+      color: #8a8a8a;
+      background: #1e1e1e;
+      border: 1px solid #2c2c2c;
+      border-radius: 6px;
+      font: 11.5px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      white-space: nowrap;
+    }
+    .chip.red { color: #f0dcdc; background: #a35c60; border-color: #a35c60; }
+    .panel-rule { margin: 0; color: #e8e8e8; font-size: 12.5px; line-height: 1.28; font-weight: 600; }
+    .statement {
+      display: flex;
+      align-items: center;
+      color: #e8e8e8;
+      font-size: 18px;
+      line-height: 1.2;
+      font-weight: 600;
+    }
+    footer {
+      display: flex;
+      align-items: end;
+      justify-content: space-between;
+      color: #6a6a6a;
+      font: 11.5px/1 ui-monospace, "SFMono-Regular", Menlo, monospace;
+      white-space: nowrap;
+    }
+  </style>
+</head>
+<body>
+  <main class="poster">
+    <header>
+      <h1>LEKKER PROOF</h1>
+      <p class="subtitle">Depth gates verification and proof attempts; a proven Critical must flip green after a fix.</p>
+    </header>
+
+    <section class="pipeline" aria-label="Evidence pipeline">
+      <div class="step">finding</div><span class="arrow">→</span>
+      <div class="step">five challenges</div><span class="arrow">→</span>
+      <div class="step hot">proof attempt</div><span class="arrow">→</span>
+      <div class="step">real git diff</div><span class="arrow">→</span>
+      <div class="step">green proof</div><span class="arrow">→</span>
+      <div class="step">confirmed push</div>
+    </section>
+
+    <section class="cards" aria-label="Proof mechanisms">
+      <article class="card">
+        <p class="kicker">PROOF 01</p>
+        <h2>Refute It</h2>
+        <div class="claims">
+          <p class="claim">One verifier applies five adversarial challenges to one finding.</p>
+          <p class="claim"><strong>Scan:</strong> no findings verified.</p>
+          <p class="claim"><strong>Medium:</strong> Criticals verified.</p>
+          <p class="claim"><strong>Deep:</strong> Criticals and Importants verified.</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">PROOF 02</p>
+        <h2>Keep the Rule</h2>
+        <div class="claims">
+          <p class="claim">Teams define hard rules in <strong>references/house-rules.md</strong>.</p>
+          <p class="claim">Reviewers tag violations with <strong>rule</strong>; they stay Critical.</p>
+          <p class="claim">Runtime questions cannot prove standards and would drop non-negotiable findings.</p>
+          <p class="claim">Rule-tagged findings skip provers; policy has no failing test.</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">PROOF 03</p>
+        <h2>Prove the Bug</h2>
+        <div class="claims">
+          <p class="claim">At medium and deep depth, up to five non-rule Criticals get a prover.</p>
+          <p class="claim">It runs in the isolated worktree.</p>
+          <p class="claim">Captured red demonstrates the Critical bug.</p>
+          <p class="claim">Green is counter-evidence: downgrade or justify.</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">PROOF 04</p>
+        <h2>Fix, Then Verify</h2>
+        <div class="claims">
+          <p class="claim">One fix agent edits each file.</p>
+          <p class="claim">A read-only verifier reads the real git diff.</p>
+          <p class="claim">A red proof after the fix reverts the group.</p>
+          <p class="claim">Nothing is pushed without explicit confirmation.</p>
+        </div>
+      </article>
+      <article class="card">
+        <p class="kicker">PROOF 05</p>
+        <h2>Keep It Living</h2>
+        <div class="claims">
+          <p class="claim">Reviews publish a private artifact page by default.</p>
+          <p class="claim">Re-reviews update the same URL.</p>
+          <p class="claim">A timeline shows what changed since the last review.</p>
+          <p class="claim">Findings close commit by commit.</p>
+        </div>
+      </article>
+    </section>
+
+    <section class="panel" aria-label="Counter-evidence rule">
+      <p class="panel-title">COUNTER-EVIDENCE</p>
+      <span class="chip red">RED = bug demonstrated</span>
+      <span class="chip">GREEN = code behaved correctly</span>
+      <p class="panel-rule">A green proof cannot silently remain Critical. It must be downgraded or explicitly justified.</p>
+    </section>
+
+    <div class="statement">An executed test outranks an agent's opinion. If the proof stays red after a fix, the group is reverted.</div>
+
+    <footer>
+      <span>VERIFY: scan none · medium Critical · deep Critical + Important · rule-tagged findings exempt and never proved</span>
+      <span>lekker-review</span>
+    </footer>
+  </main>
+</body>
+</html>

package/plugins/olko-github-pr/skills/lekker-review/references/agents/quality.md

@@ -36,6 +36,24 @@ Axes to cover:
 - No JavaScript files (TS-2): if the diff adds any `.js` file to a non-Liquid
   theme repo, flag as Critical — must be `.ts`. Set `rule: "TS-2"` on the
   finding.
+- Dependency changes. Skip this axis entirely unless the diff touches
+  `package.json`, a lockfile, or a vendored dependency. Where it applies:
+  (a) A version bump is a behaviour change nobody in this PR wrote. If neither
+      the PR body nor a commit message cites the changelog or migration notes,
+      that is `important`: semver is a promise the maintainer may not have kept,
+      and a "patch" can carry a behavioural change.
+  (b) A bulk bump of several unrelated packages in one PR is `important`. When
+      it breaks the build you have lost which package did it. The `fix` is to
+      split it per package, or per genuinely related group.
+  (c) When the repository tracks a committed lockfile, a `package.json`
+      dependency change with no matching lockfile change in the same diff is
+      `critical`: the lockfile is what actually ships. A lockfile change with no
+      `package.json` change and no explanation is also `critical`. Do not require
+      a lockfile from a repository that intentionally does not commit one.
+  (d) A new direct dependency that duplicates something already in the stack is
+      `important`. Name the existing thing that already solves it.
+  Raise NO naming, comment, complexity, or hard-rule finding inside a lockfile
+  or a `node_modules` path.
 
 Setting rule tags the finding as a house hard rule: it keeps its Critical
 severity and skips adversarial verification. Only set it for a genuine

package/plugins/olko-github-pr/skills/lekker-review/references/agents/simplification.md

@@ -20,10 +20,39 @@ Look for:
   anti-pattern (handler → service → repo with no logic in any layer).
 - Feature flags always on/off, fallback that can never trigger, dual
   implementations where old has no callers.
+- Relocated complexity: a refactor that moves code without reducing the number
+  of concepts a reader must hold to follow it. Count them before and after, but
+  an unchanged count alone is not a finding. Flag only when the move leaves a
+  concrete residual coupling, duplication, branch, or bug-surface maintenance
+  risk, and name both that risk and the cheaper move available (deleting a
+  branch, a mode, or a layer outright, rather than re-centralising the same
+  logic). `important` when the PR is sold as a cleanup or refactor,
+  `observation` otherwise.
+- Feature logic in a shared module: feature-specific behaviour added to a
+  general-purpose util, a shared client, or a base class. The branch belongs in
+  the package that owns the concept. Name the owning layer in the `fix`.
+- Dead code this diff orphans: when the diff replaces or reroutes something,
+  grep the worktree for remaining callers of what it superseded (the old helper,
+  the old component, a now-unreferenced constant, a flag that can no longer be
+  false). Enumerate what is now unreachable. NEVER propose a silent deletion:
+  the `fix` lists the orphans and asks the author to confirm removal.
+  `observation`, or `important` when the dead path is still reachable from
+  production code. When WORKTREE_PATH is null in scan mode, do not infer absent
+  callers from the diff: mark orphan analysis unverified and request
+  worktree-backed verification instead.
 
 Only flag where duplication or complexity creates a real maintenance risk or
 bug surface — not aesthetic preference.
 
+When you flag a structural problem, name the move, not just the smell: replace a
+chain of conditionals with a typed model or an explicit dispatcher, collapse
+duplicate branches into one flow, separate orchestration from business logic,
+move feature logic into the package that owns it, reuse the canonical helper
+instead of a near-duplicate, delete a pass-through wrapper. Prefer the remedy
+that removes moving pieces over one that spreads the same complexity around. A
+finding that says "this is complex" without naming the restructuring is not
+actionable: name the move or drop the finding.
+
 EXISTING_REVIEWS: read key "existingReviews" from CONTEXT_FILE (awareness only — skip findings already raised)
 
 PROJECT_RULES to verify: read key "projectRules" from CONTEXT_FILE.

package/plugins/olko-github-pr/skills/lekker-review/references/output-format.md

@@ -140,6 +140,36 @@ proof inline.>
 
 ---
 
+## 📋 PR-level findings
+
+PR-level findings have no single file:line. Render them with this dedicated
+contract instead of demoting them to Observations because a location is absent:
+
+For an `important` sizing finding:
+
+### #N — Sizing
+
+**Scope:** PR-level · **Severity:** Important
+
+**Risk:** <why the PR cannot be reviewed safely as presented>
+
+**Action:** <the recommended split and strategy>
+
+For a missing verification story:
+
+### Verification story — action required
+
+**Missing evidence:** <tests run, manual exercise, screenshots for UI, or
+before/after for behaviour or performance>
+
+**Action:** <exactly what the author must add to the PR description>
+
+An `important` sizing finding counts toward the Important total and continues
+the finding-number sequence. Missing verification evidence is an explicit
+action, not a no-action Observation.
+
+*(Omit section entirely if empty.)*
+
 ## 📝 Observations
 
 - <note — tradeoff, risk to watch, or design question worth raising>

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.36.0",
+  "version": "1.37.0",
   "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, launch plans.",
-  "version": "1.36.0",
+  "version": "1.37.0",
   "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.36.0",
+  "version": "1.37.0",
   "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.36.0",
+  "version": "1.37.0",
   "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.36.0",
+  "version": "1.37.0",
   "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.36.0",
+  "version": "1.37.0",
   "author": {
     "name": "Oleg Koval"
   },