@olegkoval/agent-skills 1.43.1 → 1.44.0

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

@@ -56,6 +56,10 @@ FAANG-grade code review. Isolated worktree checkout, full context gathering
 you have MCP tools configured for), then 5 parallel specialized review
 agents, a finding-verification pass, and one unified markdown output.
 
+An optional `--engine revmux` flag can replace the Step 2 Workflow-tool pipeline
+with revmux (profiles and lenses under `references/revmux/`); default stays
+`workflow`, and both engines feed the same Step 3 synthesis.
+
 Two modes, same review engine:
 
 | Mode       | Target                              | Entry                                  |
@@ -233,6 +237,12 @@ in Step 4. Use it for a read-only pre-push look.
 **`--no-artifact` flag:** parse and store as `ARTIFACT=false` (default true).
 Skips Step 3.5 (living review artifact) silently.
 
+**`--engine revmux|workflow` flag:** parse and store as `ENGINE`, default
+`workflow`. `revmux` is allowed only at depth `medium` or `deep` - revmux's
+scripts reject `scan` (see Depth gate). If depth resolves to `scan` (explicit
+or auto), force `ENGINE=workflow` regardless of the flag and note `engine
+forced to workflow - revmux needs medium/deep` in the review header.
+
 **Re-review detection:** run
 `ls ~/code-reviews/*-<TARGET_SLUG>-<repo-short-name>.md 2>/dev/null | sort | tail -1`
 (`TARGET_SLUG` = `pr-<PR_NUMBER>` in pr mode, `branch-<LOCAL_BRANCH sanitized to
@@ -421,7 +431,9 @@ their prompts wholesale - the workflow script delivers it by path.
 
 ---
 
-## Step 2 - Workflow (review + verify + critic)
+## Step 2 - Review engine (review + verify + critic)
+
+### ENGINE=workflow (default)
 
 Invoke the Workflow tool:
 
@@ -500,12 +512,61 @@ provers on `sonnet`, housekeeping on `haiku`. Only the synthesis in Step 3 runs
 on the session model.
 
 Return value from the workflow:
-`{findings, droppedCount, downgradedCount, hardRuleCount, proveAttemptCount, provenCount, acCoverage, coverageVerdict, mutationSlip, mockSmells, agentCount, outputTokens, turnTokensTotal}`
+`{engine, findings, droppedCount, downgradedCount, hardRuleCount, proveAttemptCount, provenCount, acCoverage, coverageVerdict, mutationSlip, mockSmells, agentCount, outputTokens, turnTokensTotal}`
 `outputTokens` is this workflow's own output spend; `turnTokensTotal` is the
 whole turn's shared pool (main loop included).
 
 Wait for the workflow to complete before proceeding to Step 3.
 
+### ENGINE=revmux
+
+revmux replaces Review, Dedup, Verify, and Critic with its own multi-agent
+round; Prove still runs inside `workflow.js`. Steps:
+
+1. `TASK_SLUG` = `<repo-short-name>-<TARGET_SLUG>`, `RUN` = `01-review`.
+2. Run the engine:
+
+   ```bash
+   ${CLAUDE_PLUGIN_ROOT}/scripts/revmux-engine.sh \
+     --task <TASK_SLUG> --run <RUN> --depth <depth> \
+     --workdir <worktreePath> \
+     --diff-file <scratchpad>/pr.diff \
+     --context-file <scratchpad>/context.json \
+     --profile-file ${CLAUDE_PLUGIN_ROOT}/references/revmux/profile.md \
+     --config-dir ~/.config/revmux \
+     --out <scratchpad>/revmux.json
+   ```
+
+3. Adapt the report:
+
+   ```bash
+   node ${CLAUDE_PLUGIN_ROOT}/scripts/revmux-adapter.mjs \
+     <scratchpad>/revmux.json --pricing \
+     ${CLAUDE_PLUGIN_ROOT}/references/pricing.json \
+     --context <scratchpad>/context.json \
+     > <scratchpad>/findings.json
+   ```
+
+4. Invoke Workflow(`workflow.js`) with the same args as the `ENGINE=workflow`
+   path above, plus `engine: "revmux"` and
+   `findingsFile: "<scratchpad>/findings.json"`. It skips Review/Dedup/
+   Verify/Critic, runs Prove only, and its return adds `engine, questions,
+   agents, degraded, totalTokens, totalUsd` on top of the usual keys.
+5. **Fallback to `ENGINE=workflow` for this run** when either holds: the
+   engine script exits `2` (tool error - also raised for a missing profile
+   file, the codex guard, or an unsupported depth), or every row in the
+   adapter's `agents` array has `degraded: true`. State the fallback in the
+   review header (`**Note:** revmux unavailable - fell back to workflow
+   engine`) and re-run the `ENGINE=workflow` path from the top of Step 2.
+
+**Trust boundary:** always pass `--config-dir ~/.config/revmux` explicitly.
+Without it revmux also reads the reviewed repo's checked-in `.revmux/`, which
+is executed as prompts. `~/.config/revmux` is where
+`scripts/install-revmux-prompts.sh` puts the lekker profiles and lenses; run it
+with `--check` when the engine exits 2 complaining about a missing profile. The task archive lives under the tasks dir
+(`LEKKER_REVMUX_TASKS_DIR`, default `~/code-reviews/revmux-tasks`) and is not
+committed anywhere.
+
 ---
 
 ## Step 3 - Synthesize and output
@@ -601,6 +662,17 @@ requirements:
   cost. Input tokens are estimated (diff tokens x agent passes + context
   + prompt files). Use the pricing table in `references/output-format.md`.
   Real numbers only - no `<N>` placeholders.
+  When `ENGINE=revmux`: build the rows from the adapter's `agents` array
+  (`name`, `model`, `tokens`, `usd` per row) and report `totalUsd` as the
+  total. Read `pricingMissing`; when it is non-empty, explicitly mark `totalUsd`
+  as incomplete and name the unpriced models. State plainly that the USD figures are an API list-price estimate
+  computed from `references/pricing.json`'s placeholder prices
+  (`verified: false`) until that file is verified against real invoices.
+  Prove-phase tokens still come from the workflow return's `outputTokens`,
+  same as the workflow engine. When `questions` (from the adapter) is
+  non-empty, render them under a `## Questions for the author` section. When
+  `degraded` is non-empty, add one banner line in the review header naming
+  the degraded agents, e.g. `⚠️ degraded: implementation, test-quality`.
 
 **Save the review:**
 
@@ -858,6 +930,17 @@ do verification inline per `references/agents/verifier.md`, and state this
 fallback in the review output under a
 `**Note:** Workflow tool unavailable - ran agents directly` line in the header.
 
+- `ENGINE=revmux` specific: on an exit-2 from `revmux-engine.sh`, or an
+  adapter report where every agent came back `degraded`, fall back to
+  `ENGINE=workflow` for that run (Step 2) rather than retrying revmux - this
+  is a fallback, not a retry loop, so it does not count against the
+  two-identical-failures rule above.
+- Never delete or rename anything under the revmux tasks dir
+  (`LEKKER_REVMUX_TASKS_DIR`, default `~/code-reviews/revmux-tasks`). A
+  duplicate run name (same `TASK_SLUG`/`RUN` pair) is revmux's own hard
+  error, by design - pick the next `NN-...` name (e.g. `03-...`) rather than
+  clearing the old one.
+
 Fix-mode specific:
 - Never claim a fix landed without a `git log` / `git status` receipt from the
   worktree. The review's proposed `fix` text is not an applied fix.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/pricing.json

@@ -0,0 +1,9 @@
+{
+  "note": "USD per million tokens, keyed by revmux's actual_model. revmux runs `claude --print` under subscription (Max plan) auth, so nothing here is a real API bill; this is an API-list-price ESTIMATE for the cost block only. Where a model exposes separate input/output prices, usd = tokens/1e6 * output price (output-only, not blended), because revmux reports a single combined `tokens` figure per agent with no input/output split to weight a blend. verified:false entries are not confirmed against a current price sheet (no local claude-api pricing doc found on this machine as of 2026-09-09) and must be checked before this cost block is trusted for a real decision.",
+  "claude-opus-5":   { "input": 15,  "output": 75,  "blended": 45,  "verified": false },
+  "claude-sonnet-5": { "input": 3,   "output": 15,  "blended": 9,   "verified": false },
+  "claude-haiku-4-5-20251001": { "input": 1, "output": 5, "blended": 3, "verified": false },
+  "opus":   { "input": 15, "output": 75, "blended": 45, "verified": false },
+  "sonnet": { "input": 3,  "output": 15, "blended": 9,  "verified": false },
+  "haiku":  { "input": 1,  "output": 5,  "blended": 3,  "verified": false }
+}

package/adapters/claude/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-conventions.md

@@ -0,0 +1,158 @@
+---
+description: deviations from Teifi's own codebase conventions — the "strong teammate" non-blocking lens
+---
+## Lens: lekker-conventions
+
+Review the change for deviations from Teifi's established codebase
+conventions and idioms. This is the "strong teammate" lens: the suggestions a
+senior Teifi engineer leaves — non-blocking, but they make the code match how
+the rest of the codebase is written. Look beyond the diff only for
+convention-specific precedent and reuse searches. Other lenses may inspect the
+runtime context they need for their own cross-file checks.
+
+Read `{{PROFILE}}` now, before forming any opinion — it carries the Teifi
+conventions text. Its §1 (naming matrix), §2 (comment policy), §5 (commit
+hygiene) and §6 (generated code) are yours — they are the house style, so a
+deviation needs NO codebase precedent beyond that file (the file IS the
+precedent; cite the section, e.g. "teifi-conventions §1 verbs").
+Everything else in this lens still requires a cited precedent from the code.
+
+Axes to cover:
+- Naming (teifi-conventions §1): every symbol the diff INTRODUCES against the
+  matrix — boolean without `is`/`has`, async I/O named `get`, a row lock or a
+  throw-on-miss or a cache read absent from the name (`…ForUpdate`,
+  `…OrThrow`, `…Cached`), a collidable component without its domain prefix, a
+  bare generic noun (`line`, `node`, `row`) where the domain has two variants in
+  scope. NEVER flag a boundary name (DB column, GraphQL/oRPC field, enum value,
+  route string, wire key) — renaming it breaks callers outside the diff.
+- Comments (teifi-conventions §2): one finding per over-commenting offender the
+  diff ADDED, with the deletion as the fix. Never a vague "too many comments",
+  never a pre-existing comment, never a lint/type pragma or a genuine
+  non-obvious "why".
+- Generated code (teifi-conventions §6): a changed `.sql` / `.graphql` /
+  `.json` schema / `prisma/schema.prisma` whose generated artifact is absent
+  from the diff (or the reverse) — major. Raise NO naming, comment, or
+  complexity finding inside a `generated/` directory. A hand-rolled `fetch` to
+  the Shopify Admin GraphQL endpoint instead of the genql client — major.
+- Commits (teifi-conventions §5): non-conventional or vague commit subjects, and
+  any Claude Code / assistant mention in the commit or PR text.
+- Type-system idioms:
+  * A hand-written interface/type that duplicates an existing Zod schema —
+    should be `z.infer<typeof zSchema>` so the schema stays the single source
+    of truth. (Grep for a matching z-schema in the same feature folder.)
+  * Raw `string` used for a Shopify GID or an entity id where a branded
+    `ID<'Customer'>` (or similar) type exists and is used elsewhere.
+  * A union typed as `as readonly string[]` / a hand-rolled `is...` guard where
+    a `z.enum([...])` + `z.infer` would give validation, narrowing, and the
+    options array in one declaration.
+  * An unnecessary `satisfies` / redundant type annotation the compiler already
+    infers.
+  * A GID validated/parsed inline where a shared helper exists (e.g.
+    `zNamespacedGid`). Grep the shared libs and the repo before asserting.
+- Reuse (search the worktree AND sibling Teifi repos before flagging):
+  * Inline fetch/client logic that should reuse — or be promoted into — a
+    shared client (e.g. a company-switcher client) that already exists or that
+    the codebase clearly wants.
+  * A util/helper that already exists elsewhere being re-implemented inline.
+  * A symbol defined locally that is (or should be) exported from a shared
+    module — "are we not exporting this somewhere?"
+- Consistency:
+  * Cache-key / composite-key separators that disagree with the repo's
+    prevailing choice (e.g. `:` vs `::`). Grep existing key-building code to
+    find the prevailing pattern, then flag the deviation.
+  * Ad-hoc error throwing where the repo has an idiom (e.g. `throw new
+    HttpError('...', 403)` instead of a bare string / generic Error).
+  * Naming/casing that breaks the convention used by sibling files.
+
+MANDATORY SWEEP — do this FIRST, before forming any opinion:
+
+The axes above are symptom-driven: they only fire once you already suspect a
+duplication. That is how a re-implemented helper slips through — nobody thinks to
+look. So run these enumerations mechanically, whether or not anything looks wrong.
+
+1. **Sibling sweep for every file the diff ADDS.** For each added file, list its
+   directory and read the exports of its neighbours. A helper that solves the same
+   problem is usually sitting in the same folder.
+
+   ```bash
+   REVIEW_CONFIG="{{CONTEXT}}/worktree.json"
+   WORKTREE="$(jq -er '.worktreePath | select(type == "string" and length > 0)' "$REVIEW_CONFIG")"
+   BASE_REV="$(jq -er '(.mergeBase // .baseRef) | select(type == "string" and length > 0)' "$REVIEW_CONFIG")"
+   REPO_ROOT="$(jq -er '.repoRoot | select(type == "string" and length > 0)' "$REVIEW_CONFIG")"
+   SIBLING_ROOT="$(dirname "$REPO_ROOT")"
+
+   git -C "$WORKTREE" diff --name-status "$BASE_REV"...HEAD | awk '$1=="A"{print $2}' |
+     while IFS= read -r added_file; do
+       added_dir="$WORKTREE/$(dirname "$added_file")"
+       ls -la "$added_dir"                         # what already lives beside it
+       grep -rn "^export " "$added_dir"/*.ts "$added_dir"/*.tsx 2>/dev/null |
+         grep -v -F -- "$added_file"
+     done
+   grep -rn "^export " "$SIBLING_ROOT" --include='*.ts' --include='*.tsx' \
+     --exclude-dir=node_modules 2>/dev/null
+   ```
+
+   A new `foo/bar-thing.ts` next to an existing `foo/thing.ts` is a finding waiting
+   to happen. Read the neighbour, do not just note its name.
+
+2. **New-symbol sweep.** For every function/const the diff exports, search the repo
+   for something that already does that job, by BEHAVIOUR not just by name. Names
+   rarely match; behaviour does.
+
+   ```bash
+   git -C "$WORKTREE" diff --unified=0 "$BASE_REV"...HEAD | \
+     grep '^+' | grep -E 'export (function|const) '             # collect new symbols
+   # then for each, search by what it does, e.g. a locale normaliser:
+   grep -rln "toLowerCase()\|normalize\|isoCode\|split('-')" "$WORKTREE" \
+     --include='*.ts' --include='*.tsx'
+   ```
+
+   Pick 2 or 3 behavioural keywords from the new function's body and grep those.
+   Reviewing the diff alone cannot catch this.
+
+3. **State what you swept.** In your output, name the directories you listed and the
+   behavioural greps you ran, even when they found nothing. A sweep that is not
+   reported did not happen, and the next reviewer cannot tell "no duplication exists"
+   from "nobody looked".
+
+HARD RULES:
+- Only raise a finding when the better pattern PROVABLY ALREADY EXISTS. Cite it:
+  the file:line where the helper/type/convention lives, or the sibling file that
+  does it the idiomatic way. If you cannot find a concrete precedent, DROP the
+  finding — "this would be nicer as X" on taste alone is not allowed.
+- Every finding must still trace to a `+` line in the diff (the deviation must
+  be code this change added/changed). The supporting precedent may live outside the
+  diff; the deviation may not.
+- These are suggestions, not blockers. Do not inflate severity. Report each as
+  `file:line — <deviation> (precedent: <file:line of the existing pattern>)`.
+- ONE EXCEPTION to non-blocking: if the re-implementation DIVERGES in behaviour
+  from the helper it duplicates, that is not a style nit, it is two spellings of
+  the same value that disagree, and it belongs on lekker-quality's severity
+  scale rather than this lens's. Diff the two implementations before deciding:
+  same inputs, same outputs? If a real input produces different results, say so
+  explicitly and give the input.
+
+To find precedents, you may run:
+
+```bash
+grep -rn "<symbol or pattern>" "$WORKTREE" --include='*.ts' --include='*.tsx'
+find "$SIBLING_ROOT" \( -name "*.ts" -o -name "*.tsx" \) ! -path "*/node_modules/*" \
+  | xargs grep -l "<symbol>" 2>/dev/null | head
+```
+
+Always include *.tsx. Extension and frontend code lives in .tsx, so a search that
+omits it silently reports "no precedent exists" for whole directories.
+
+A mined record of what other bots (Greptile / Gemini / CodeRabbit) have
+commented on in this repo may be present under `{{CONTEXT}}`. Use it as a prior,
+not as a checklist: a high count means "frequently raised here", not "correct" —
+never raise a finding because a bot once said it, only because it is true here.
+
+Rules:
+- Report file:line — description with a precedent citation. No positive
+  observations. No taste-only suggestions.
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory — and give a concrete drop-in fix, or when the fix is
+  architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-implementation.md

@@ -0,0 +1,76 @@
+---
+description: correctness, scalability and integration issues — Teifi's GQL-1 hard rule included
+---
+## Lens: lekker-implementation
+
+Review the change for correctness, scalability, and integration issues.
+
+Axes to cover:
+- Business Logic / AC coverage: for each acceptance criterion available in
+  `{{CONTEXT}}` (a ticket's AC list, when present), mark met / partial / missing.
+  Scope creep is also worth flagging.
+  Decide each AC against the code that RUNS, not against the diff. Use the
+  worktree (`{{WORKDIR}}`) to follow the AC through its runtime path into files
+  the diff never touched, and specifically:
+  (a) Find what invokes the new code and on what trigger. New code that nothing
+      calls satisfies nothing, however correct its body is.
+  (b) For an AC with a timing, cadence or SLA component, name the trigger's real
+      frequency (the cron expression, the poll interval, the webhook) and compare
+      that number against the AC. A reaper on a daily cron cannot meet a two-hour
+      SLA.
+  (c) For an AC about a failure mode (crash, OOM, timeout, network loss), confirm
+      the handling is reachable under that failure. A killed process never reaches
+      a `finally` block, a shutdown hook, or the tail of a long-running function.
+  An AC can fail with every added line correct, because the defect is what the
+  diff left alone. That is a finding, not an absence of one.
+- Binding scoping decisions: when `{{CONTEXT}}` names a resolved flag from the
+  ticket's Dev Scoping Session, a diff that contradicts it is major (critical
+  when it changes external behaviour or data shape); quote the decision text.
+- Scalability: N+1 queries, missing pagination, unbounded in-memory
+  collections, missing rate-limit handling, cron jobs without overlap guard,
+  missing DB indexes for new query patterns.
+- Time/Space Complexity: O(n²) where linear exists, large payloads in memory,
+  sort/dedup on large arrays that could be done at DB level.
+- Integration Contracts: Shopify API misuse, BC API assumptions, webhook
+  idempotency, external API pagination not handled.
+- GraphQL pagination (GQL-1): for every GraphQL query in the diff that uses a
+  nodes connection (`nodes { ... }`):
+  (a) Check that `pageInfo { hasNextPage endCursor }` is present alongside nodes — if missing, critical.
+  (b) Check that all pages are fetched (a loop or recursion using endCursor) — a single-page fetch is a bug, critical.
+  (c) Check the page size: must be 250 (Shopify max). If any other size is used without a code comment explaining why, flag as major.
+  Title any critical finding under this axis `[GQL-1] ...`.
+- Feature-flag rollout (Reflag repos ONLY): first check the repo actually uses
+  Reflag — a `package.json` (any depth, excluding node_modules) depending on
+  `@reflag/node-sdk` or `@teifi-digital/reflag-client`. If it does not, SKIP this
+  axis entirely and raise nothing; a repo with no flag client cannot act on the
+  finding. Where it does apply, ask whether the change should ship behind a flag:
+  (a) a client should validate it before everyone sees it; (b) it changes data
+  shape or what gets written; (c) it touches orders, money, or fulfilment; (d) it
+  cannot be verified without real client data or volume. Do NOT raise it for pure
+  UI/copy with no data change, a bug fix that is strictly better and obviously
+  correct, internal/admin-only surfaces, or work fully covered by tests and
+  verifiable in staging. Tie-breaker: if you would not be comfortable fixing it
+  forward at 2am, it needs a flag. Name which of (a)-(d) applies.
+  Severity: major at most, usually minor — this is a rollout judgement call, not
+  a defect. NEVER title this with a bracketed hard-rule tag (that would force
+  critical and imply a policy violation). Never invent a concrete flag key as
+  though it exists: flag keys must be confirmed against Reflag, so say a flag is
+  needed without naming one.
+  Also raise as a structural concern (severity major) when a diff BOTH adds a
+  column/table AND changes what is read or written — the SOP requires splitting
+  that into expand / migrate / read-switch / contract PRs. Name the split.
+
+GQL-1's full rule text lives in `{{PROFILE}}` — read it there before applying it.
+
+Rules:
+- Every finding must trace to a `+` line in the diff, with one exception: an
+  unmet AC whose defect lives in code the diff did not touch. Anchor that one to
+  the unchanged file:line that had to change, and say in the description why the
+  unchanged line is the defect. That line may be an unchanged one — do not drop
+  an unmet AC for lack of a quotable added line.
+- Report file:line — description. No positive observations.
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory — and give a concrete drop-in fix, or when the fix is
+  architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead.

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

@@ -0,0 +1,87 @@
+---
+description: quality, security and data-integrity issues — Teifi's TS-1/TS-2 hard rules included
+---
+## Lens: lekker-quality
+
+Review the change for quality, security, and data-integrity issues.
+
+Axes to cover:
+- Data Integrity: missing transactions on multi-step writes, optimistic
+  concurrency without locking, partial-failure with no rollback, silent data
+  loss in batch loops.
+- Security: SQL/command injection, auth bypass, missing permission checks,
+  IDOR, secrets in logs, webhook signature not verified.
+  When the diff touches a controller, a route, or an auth decorator, do NOT hand-roll the
+  decorator grep. Use the `route-auth-map` skill, which already does exactly this and prints
+  method/path/controller/guards plus an explicit unguarded-endpoint section. If the Skill tool
+  is unavailable to you, read `~/.claude/skills/route-auth-map/SKILL.md` and follow its steps.
+  Compare the map before and after the diff: a route that gains a handler but no guard, or
+  loses `@Authenticated`/`@Permission`, is critical.
+- Error Handling: unhandled promise rejections, empty catch blocks, missing
+  retries on transient failures, no dead-letter for failed jobs.
+- Catch-block exit paths: when the diff adds or edits a branch inside a `catch`,
+  enumerate EVERY way control leaves that block - each early return, each
+  rethrow, and the fall-through - and say what the client sees on each. A new
+  branch that changes what gets logged or reported, while leaving a rethrow or
+  fall-through reachable for the same condition, is a finding: the error is now
+  silent AND still escapes. Do not accept "it reports correctly" as covering the
+  block; the report and the control flow are separate claims.
+- Schema/Migration: NOT NULL without default, rename without two-step,
+  pgtyped queries invalidated, Prisma client out of sync.
+- Naming/Typos: wrong casing convention, mixed conventions in same scope,
+  misspelled identifiers (these are bugs-in-waiting).
+- Derived-value consistency: when the diff introduces a transform of some input
+  (normalise, trim, lowercase, parse, clamp, default), grep EVERY other use of
+  that raw input in the same scope and check they all go through the transform.
+  Half-applied transforms are a classic near-miss: the value is normalised at the
+  call site but the raw one is still used in a React dependency array, a cache
+  key, a log line, an equality check, or a second call site. Two spellings of the
+  "same" value then disagree. Enumerate the uses; do not eyeball the hunk.
+
+  ```bash
+  grep -n "<rawIdentifier>" <file>     # every use, then confirm each is intended
+  ```
+
+- Env vars: dead vars, renamed without migration, wrong fallback operator
+  (?? vs ||), type mismatch, leaked in logs.
+- TypeScript type safety (TS-1): flag every type cast (`as X`, `<X>expr`)
+  and every use of `any`. Test files: only flag blatantly omitted types
+  (e.g. `any[]` on a clearly-typed list). All others: critical. Quote the
+  cast, explain the correct type, show the fix. Ask if they're Harry Potter.
+  Title the finding `[TS-1] ...`.
+- No JavaScript files (TS-2): if the diff adds any `.js` file to a non-Liquid
+  theme repo, flag as critical — must be `.ts`. Title the finding `[TS-2] ...`.
+- 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 major: 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 major. 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) A `package.json` dependency change with no matching lockfile change in the
+      same diff, or a lockfile change with no `package.json` change and no
+      explanation, is critical: the lockfile is what actually ships.
+  (d) A new direct dependency that duplicates something already in the stack is
+      major. Name the existing thing that already solves it.
+  Raise NO naming, comment, complexity, or TS-1 finding inside a lockfile or a
+  `node_modules` path.
+
+TS-1 and TS-2 are Teifi hard rules: their text is defined in full in `{{PROFILE}}`
+(read it there before applying either). A finding for one of them MUST have its
+title start with the bracketed tag, e.g. `[TS-1] ...` or `[TS-2] ...`, so the
+caller can recognize it as a policy violation rather than an ordinary finding.
+
+CI status, Sentry signals, and existing reviews may be present in `{{CONTEXT}}` —
+read what is there before forming an opinion, and skip anything that is absent
+rather than treating its absence as a finding.
+
+Rules:
+- Every finding must trace to a `+` line in the diff.
+- Report file:line — description. No positive observations.
+- Quote the verbatim offending line(s) from the diff — never paraphrased, never
+  reconstructed from memory — and give a concrete drop-in fix, or when the fix
+  is architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead of reporting it as a minor observation with no evidence.

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

@@ -0,0 +1,63 @@
+---
+description: over-engineering and DRY violations, plus Teifi's debug-artifact hygiene table
+---
+## Lens: lekker-simplification
+
+Review the change for over-engineering and DRY violations.
+
+Look for:
+- Copy-paste logic: identical blocks that differ only in a constant — flag
+  for extraction.
+- Parallel implementations: two functions doing the same thing — one should
+  call the other.
+- Unnecessary abstraction inversion: private helper called exactly once, adds
+  no reuse — should be inlined.
+- Over-engineered control flow: nested ternaries / promise chains that could
+  be plain if/else or async/await.
+- Config spread: same magic constant defined in multiple files.
+- Debug artifacts and hygiene: apply the fixed severity table in §3 of
+  `{{PROFILE}}` (the Teifi conventions section) — `debugger` and
+  `.only`/`fit`/`fdescribe` are critical, an added `console.log`/`console.debug`
+  in production code and a hardcoded URL are major, an unreferenced
+  TODO/FIXME and a >3-line commented-out block are minor. Those severities
+  are fixed: do not soften them, and only flag occurrences the diff ADDED.
+- Wrapper that adds nothing, factory for single implementation, layer-cake
+  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. If
+  the count is unchanged, the restructuring did not simplify anything, and the
+  finding is that a cheaper move was available (deleting a branch, a mode, or a
+  layer outright, rather than re-centralising the same logic). Major when
+  the change is sold as a cleanup or refactor, minor 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.
+  Minor, or major when the dead path is still reachable from production code.
+
+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.
+
+Rules:
+- Every finding must trace to a `+` line in the diff.
+- Report file:line — description. No positive observations.
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory — and give a concrete drop-in fix, or when the fix is
+  architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead.