@olegkoval/agent-skills 1.45.0 → 1.45.1

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

@@ -12,29 +12,29 @@ and lekker-deep review profiles. It concatenates the two files lekker-review its
 
 These rules are non-negotiable. Violations are always **Critical** findings regardless of depth or other filters. Apply them when developing a feature or bugfix, not only during review.
 
-### TS-1 — Type safety (TypeScript only)
+### TS-1 - Type safety (TypeScript only)
 
-- No type casting (`as X`, `<X>expr`) — ask them if they are Harry Potter for casting spells.
-- No `any` — except in test files where types are genuinely hard to express; even there, blatantly omitted types (e.g. `any[]` on a known shaped list) must be flagged.
+- No type casting (`as X`, `<X>expr`) - ask them if they are Harry Potter for casting spells.
+- No `any` - except in test files where types are genuinely hard to express; even there, blatantly omitted types (e.g. `any[]` on a known shaped list) must be flagged.
 - Every finding: quote the cast/`any`, explain the correct type, show the fix.
 
-### TS-2 — No JavaScript files
+### TS-2 - No JavaScript files
 
 - No `.js` files may be added to any Teifi integrations repo.
 - Exception: Liquid themes (Online Store 2.0 Shopify themes) may contain `.js`.
 - If the PR adds a `.js` file to a non-theme repo, flag it as Critical: must be converted to `.ts`.
 
-### GQL-1 — GraphQL NodesConnection pagination
+### GQL-1 - GraphQL NodesConnection pagination
 
 - Every query that uses a nodes connection (`nodes { ... }`) **must** include `pageInfo { hasNextPage endCursor }` alongside the nodes.
-- All remaining pages **must** be fetched — a single-page fetch with no loop/recursion is a bug.
+- All remaining pages **must** be fetched - a single-page fetch with no loop/recursion is a bug.
 - The page size **must** be `250` (Shopify max). If any other value is used, a code comment explaining why is required; if no comment exists, flag it.
 
-### PR-1 — PR title must be prefixed with Linear ticket(s)
+### PR-1 - PR title must be prefixed with Linear ticket(s)
 
 - PR title must start with `[GIC-123]` (or the relevant project prefix) in square brackets.
 - Go through the commit history: if merged PRs or commits reference Linear tickets in square brackets (`[GIC-123]`), all of them must appear comma-separated in the current PR title (e.g. `[GIC-123,GIC-124]`).
-- This is a **blocking** finding: display a prominent `⛔ CANNOT MERGE` warning and recommend the correct title prefix. Confidence score is not affected — this is a process rule, not a code quality signal.
+- This is a **blocking** finding: display a prominent `⛔ CANNOT MERGE` warning and recommend the correct title prefix. Confidence score is not affected - this is a process rule, not a code quality signal.
 
 ### 1g. Repo placement check (Teifi multi-repo projects only)
 
@@ -49,7 +49,7 @@ belongs in *this* repo and not a sibling repo.
 | `*-integrations` (e.g. `evi-integrations`; see the GIC exception below) | Backend ERP sync: cron jobs, orchestrator, BC/Sage/Jitterbit/ROI API clients |
 | `teifi-digital` / shared libs | Cross-project utilities, shared types |
 
-**Note:** `gic-integrations` has an `extensions/` folder containing legacy/reference extensions (e.g. `link-account-customer`), but **new customer account extensions for GIC should target `gic-live`** per project specs. Always check the Linear/Notion ticket for explicit repo path — don't infer from existing repo contents alone.
+**Note:** `gic-integrations` has an `extensions/` folder containing legacy/reference extensions (e.g. `link-account-customer`), but **new customer account extensions for GIC should target `gic-live`** per project specs. Always check the Linear/Notion ticket for explicit repo path - don't infer from existing repo contents alone.
 
 **Action:** If the diff adds a new Shopify extension and the PR targets `*-integrations`, check the Linear/Notion spec for the explicit target directory. If the spec names `*-live`, flag it as a **Critical** placement error (`## 🏠 Wrong Repo`).
 
@@ -64,12 +64,12 @@ Include: spec quote with correct path, which repo to target, and the risk (wrong
 | TS-1 | No type casts (`as X`), no `any` | Critical; test files lenient on genuine unknowns only |
 | TS-2 | No `.js` files in integrations repos | Critical; Liquid themes exempt |
 | GQL-1 | nodes connections need `pageInfo`, all pages fetched, size=250 | Critical if pageInfo/pagination missing; Important if size≠250 without comment |
-| PR-1 | PR title must start with `[TICKET-NNN]`; include all commit-referenced tickets | Blocking — ⛔ CANNOT MERGE warning |
+| PR-1 | PR title must start with `[TICKET-NNN]`; include all commit-referenced tickets | Blocking - ⛔ CANNOT MERGE warning |
 | FLAG-1 | Reflag repos only: risky change should ship behind a feature flag | Non-blocking; `important` at most, usually `observation`. Never a `rule:` tag |
 
-These apply equally when you are writing a feature or bugfix — not only in review.
+These apply equally when you are writing a feature or bugfix - not only in review.
 
-### FLAG-1 — Ship behind a feature flag (Reflag repos only)
+### FLAG-1 - Ship behind a feature flag (Reflag repos only)
 
 Applies ONLY where a `package.json` (any depth, excluding `node_modules`) depends on
 `@reflag/node-sdk` or `@teifi-digital/reflag-client`. Elsewhere there is no flag client,
@@ -90,7 +90,7 @@ Yes → ship it. No → flag it.
 
 Deliberately NOT blocking, unlike TS-1/GQL-1/PR-1: whether something needs a flag is a
 rollout judgement, not a correctness violation, and a blocking comment on every
-borderline diff trains people to ignore the signal. Never invent a concrete flag key —
+borderline diff trains people to ignore the signal. Never invent a concrete flag key -
 keys must be confirmed against Reflag, so say a flag is needed without naming one.
 
 Related: a diff that BOTH adds a column/table AND changes what is read or written must
@@ -121,20 +121,20 @@ only the message is wrong. Detail and the reporting format live in the
 - **Shopify:** REST Admin + GraphQL Admin, Webhooks, Shopify Functions, genql
 - **External APIs:** Business Central (OAuth2, rate-limited), Salesforce GraphQL, ROI
 - **Infra:** Docker Compose locally; environment-var–driven cron syncs via `orchestrator.ts`
-- **Type gen pipeline:** pgtyped (SQL→TS), genql (GraphQL→TS), json2ts (schemas→TS) —
+- **Type gen pipeline:** pgtyped (SQL→TS), genql (GraphQL→TS), json2ts (schemas→TS) -
   check that generated files are regenerated when their sources change
 - **MCPs available:** Linear, Slack, Notion, Shopify Dev docs, Harvest, Sentry
 
 ### Repo taxonomy (for Step 1g placement check)
 
-**Per-project repo structure varies — always verify before flagging.**
+**Per-project repo structure varies - always verify before flagging.**
 
 - For **EVI project**: `evi-integrations` = backend ERP sync only; `evi-live` = Shopify app (extensions, Polaris UI).
 - For **GIC project**: `gic-integrations` owns the ERP backend sync and retains
   legacy/reference Shopify extensions. New GIC customer account extensions belong
   in `gic-live`; do not treat the legacy `extensions/` folder as placement precedent.
 - For other projects (`rsl-*`, `elmt-*`, etc.): check the repo's `extensions/` folder
-  presence before assuming a split — do not assume the `*-integrations` pattern always
+  presence before assuming a split - do not assume the `*-integrations` pattern always
   means backend-only.
 
 **Step 1g action**: Before flagging a placement mismatch, run:
@@ -154,7 +154,7 @@ that alone is not precedent for new GIC extensions. Flag when the repo has no
 # Teifi soft conventions (styling, naming, comments, tests, hygiene)
 
 Companion to `teifi-rules.md`. Those are the four HARD rules (TS-1, TS-2,
-GQL-1, PR-1) — always Critical. This file is the house style the Teifi
+GQL-1, PR-1) - always Critical. This file is the house style the Teifi
 plugin skills enforce during development (`teifi-dev:code-review`,
 `rename-pass`, `comment-stripper`, `unit-test-best-practices`). A review that
 misses them lets the same nits come back from the human reviewer.
@@ -168,7 +168,7 @@ inflate a style deviation into Critical.
 ## 1. Naming matrix (source: `teifi-dev` rename-pass agent)
 
 Flag a name the diff INTRODUCES that breaks a row. Renaming is cheap in the
-diff, expensive later — but a rename is still a cost, so leave conforming
+diff, expensive later - but a rename is still a cost, so leave conforming
 names alone.
 
 ### Values
@@ -184,7 +184,7 @@ names alone.
 | count | `Count` suffix | `lineCount` |
 | casing | camelCase values · PascalCase types/components · `CONSTANT_CASE` constants | |
 
-### Verbs — one per job, chosen by cost + purity
+### Verbs - one per job, chosen by cost + purity
 
 `get` cheap/sync · `fetch` async I/O · `create` new persisted entity ·
 `build` assembles in memory (pure) · `derive` pure value from existing state ·
@@ -195,14 +195,14 @@ idempotently makes state hold.
 A `getX` that does network I/O is a finding (`fetchX`). A `createX` that
 mutates an existing row is a finding (`updateX`).
 
-### Effect affixes — put the surprise in the name
+### Effect affixes - put the surprise in the name
 
 `…OrThrow` · `…OrDefault` · `upsert` · `…ForUpdate` (row lock) ·
 `…SkipLocked` · `try…` (returns result, doesn't throw) · `with…`
 (acquire→run→release) · `…Sync` · `…Cached` · `unsafe…`.
 
 A function that takes a row lock, throws on miss, or returns a cached value
-without saying so in its name is a finding — that surprise is exactly what the
+without saying so in its name is a finding - that surprise is exactly what the
 next caller will miss.
 
 ### React & types
@@ -219,7 +219,7 @@ next caller will miss.
 `line`, `item`, `node`, `record`, `entry`, `group`, `row`, `value`, `key` are
 findings when the surrounding domain has two or more qualified variants in
 scope (arrival line vs receipt line; source node vs target node). Qualify with
-the domain role — variables, params, fields, type aliases, **type params**
+the domain role - variables, params, fields, type aliases, **type params**
 (`TLine` → `TReceiptLine`), and the functions built on the noun.
 
 ### NEVER flag a rename at a boundary
@@ -228,7 +228,7 @@ DB table/column names (and any `Row`/`Dto` mirroring them), GraphQL / oRPC /
 OpenAPI contract fields, enum string values, route strings, wire/JSON keys.
 Something outside the diff reads them. The app-layer alias may be renamed
 (`createdAt @map("created_at")`); the boundary name may not. A "rename this
-column" finding is a false positive — say the boundary name is bad and leave
+column" finding is a false positive - say the boundary name is bad and leave
 it to a human if it matters.
 
 ---
@@ -238,25 +238,25 @@ it to a human if it matters.
 **Default: a comment should not exist.** It earns its place only by saying
 something the code *cannot*, and then in as few words as possible. Flag each
 offending comment the diff ADDED as its own `idiomatic` finding with the
-deletion as the `fix` — never a vague "too many comments". Pre-existing
+deletion as the `fix` - never a vague "too many comments". Pre-existing
 comments are out of scope.
 
 Flag a comment that:
 
 - restates the next line (`// increment counter` over `counter += 1`);
 - narrates a step or captions a block ("first we fetch, then we map…");
-- **narrates a whole function or type** — JSDoc restating a well-named
+- **narrates a whole function or type** - JSDoc restating a well-named
   signature, its params, or its return shape. A doc comment earns its place
   only for a non-obvious *contract*;
 - explains obvious syntax or a well-known API;
 - repeats a rationale stated elsewhere in the diff (keep ONE canonical place);
-- is changelog/AI noise — ticket IDs (`EVI-123`), person names, multi-paragraph
+- is changelog/AI noise - ticket IDs (`EVI-123`), person names, multi-paragraph
   "why we chose X" essays. A single `@see EVI-123` JSDoc tag is fine;
-- **references what the reader cannot see** — a removed line or a prior
+- **references what the reader cannot see** - a removed line or a prior
   approach ("no longer using the old Y"). Source shows what the code *is*;
-- **documents invisible coupling** — "ordered this way because some other code
+- **documents invisible coupling** - "ordered this way because some other code
   does X". The fix is clearer structure, not a comment enshrining it;
-- **says what a name or type could say** — then the code should carry it (this
+- **says what a name or type could say** - then the code should carry it (this
   is a naming finding per §1, not a comment to keep).
 
 KEEP (do not flag): an external-system quirk, an ordering/concurrency
@@ -269,7 +269,7 @@ gotcha, is noise. Code is type-checked; prose is not.
 
 ---
 
-## 3. Hygiene & debug artifacts — severity is fixed, do not soften
+## 3. Hygiene & debug artifacts - severity is fixed, do not soften
 
 Scan `+` lines only (added by this diff; pre-existing occurrences are out of
 scope).
@@ -278,7 +278,7 @@ scope).
 |---|---|
 | `console.log(` / `console.debug(` added to non-CLI production code | important |
 | `debugger;` | critical |
-| `.only` on a test (`it.only`, `describe.only`, `fit(`, `fdescribe(`) — silently skips the rest of the suite | critical |
+| `.only` on a test (`it.only`, `describe.only`, `fit(`, `fdescribe(`) - silently skips the rest of the suite | critical |
 | new `TODO:` / `FIXME:` / `HACK:` / `XXX:` with no ticket reference | idiomatic |
 | commented-out code block > 3 lines | idiomatic |
 | hardcoded URL / endpoint that belongs in an env var | important |
@@ -286,7 +286,7 @@ scope).
 | unreachable code after `return`/`throw` | important |
 
 `console.error`/`console.warn` on a real error path is not a finding unless the
-repo has a logger idiom — then cite it.
+repo has a logger idiom - then cite it.
 
 ---
 
@@ -305,13 +305,13 @@ does. Each is an `idiomatic` finding with the corrected code as the `fix`.
 - **`afterEach(cleanup)`** in every RTL test file.
 - **`new QueryClient({ defaultOptions: { queries: { retry: false } } })`** in
   every hook/component test wrapper. Missing `retry: false` silently hangs the
-  test on a failing query — flag it as `important`, not idiomatic.
+  test on a failing query - flag it as `important`, not idiomatic.
 - **Query priority:** `getByRole` → `getByLabelText` → `getByText` →
   `getByTestId` (last resort only). A `getByTestId` where a role query works is
   a finding.
 - **Mock paths are RELATIVE, never the `@lib/common` alias.** The alias
   resolves only from `web/`; inside `common/` it is silently ignored and the
-  mock has no effect — the test then passes against the real module. Flag any
+  mock has no effect - the test then passes against the real module. Flag any
   `vi.mock('@lib/common/…')` inside `common/` as `important`.
 - **Mock at the module boundary,** not `vi.spyOn(mod, '_internal')`.
 - **Zod schemas:** test via `safeParse` and assert `result.success`, not
@@ -322,28 +322,28 @@ does. Each is an `idiomatic` finding with the corrected code as the `fix`.
   (`expect(matrix).toHaveLength(N * M * K)`). A hand-picked subset of a
   combinatorial space is a coverage-gap finding.
 - **Comment the non-obvious scenario:** a test capturing a past bug explains
-  *why* (this is a sanctioned comment — never flag it under §2).
+  *why* (this is a sanctioned comment - never flag it under §2).
 
 ---
 
 ## 5. Commit & PR hygiene
 
-Beyond PR-1 (hard rule). All `idiomatic` — a squash fixes them and they never
+Beyond PR-1 (hard rule). All `idiomatic` - a squash fixes them and they never
 block.
 
 - Conventional commits: `<type>(<scope>): <description>` with type in
   `feat|fix|refactor|test|docs|chore|style|perf|build|ci`; description
   lowercase, imperative, no trailing period.
-- Vague subjects (`fix`, `update`, `wip`, `changes`, `stuff`) — flag, recommend
+- Vague subjects (`fix`, `update`, `wip`, `changes`, `stuff`) - flag, recommend
   a rewrite.
-- Many WIP commits — recommend a squash before merge, in one line, once.
+- Many WIP commits - recommend a squash before merge, in one line, once.
 - Never mention Claude Code / the assistant in commit or PR text; a
   `Co-Authored-By: Claude` trailer or "Generated with Claude Code" footer in
   the commit log is a finding.
 
 ---
 
-## 6. Generated code — check the source, not the artifact
+## 6. Generated code - check the source, not the artifact
 
 The Teifi type-gen pipeline means several files must move together. When a
 source changes and its generated artifact does not (or vice-versa), that is an
@@ -356,10 +356,10 @@ source changes and its generated artifact does not (or vice-versa), that is an
 | `schemas/*.json` | `schemas/generated/` (json2ts) |
 | `prisma/schema.prisma` | a migration in `prisma/migrations/` + Prisma client |
 
-Never review the *content* of a generated file as if it were hand-written — no
+Never review the *content* of a generated file as if it were hand-written - no
 naming, comment, or complexity findings inside `generated/`. Review the source.
 
 Related hard convention (project CLAUDE.md): Shopify Admin API calls go through
-the genql client (`gql.<file>.<query>.run(graphql, vars)`) — a hand-rolled
+the genql client (`gql.<file>.<query>.run(graphql, vars)`) - a hand-rolled
 `fetch` to `/admin/api/…/graphql.json` is an `important` finding even for a
 one-off probe.

package/adapters/claude/olko-github-pr/skills/lekker-review/scripts/fixtures/house-rules.md

@@ -1,11 +1,11 @@
 # Fixture house rules
 
-### TS-1 — Type safety
+### TS-1 - Type safety
 
-### TS-2 — No JavaScript files
+### TS-2 - No JavaScript files
 
-### GQL-1 — Complete pagination
+### GQL-1 - Complete pagination
 
-### PR-1 — Ticket-prefixed titles
+### PR-1 - Ticket-prefixed titles
 
-### SEC-7 — Never log session tokens
+### SEC-7 - Never log session tokens

package/adapters/claude/olko-github-pr/skills/lekker-review/scripts/fixtures/revmux-report.json

@@ -11,7 +11,7 @@
       "body": "Two concurrent writers can both pass the guard and insert a fulfillment row.",
       "fix": "Take a row lock on the order before the check-then-insert.",
       "sources": ["quality+impl"],
-      "lenses": ["lekker-quality"],
+      "lenses": ["lekker-quality", "lekker-implementation"],
       "verdict": "confirmed"
     },
     {

package/adapters/claude/olko-github-pr/skills/lekker-review/scripts/revmux-engine.sh

@@ -143,6 +143,7 @@ REVMUX_OUT="$OUT"
 set +e
 revmux --task "$TASK" --run "$RUN" --profile "$PROFILE_NAME" \
     --workdir "$WORKDIR" --tasks-dir "$TASKS_DIR" --config-dir "$CONFIG_DIR" \
+    --tools=Read,Grep,Glob,WebFetch,WebSearch \
     --no-tui > "$REVMUX_OUT"
 CODE=$?
 set -e

package/package.json

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

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

@@ -1,43 +1,43 @@
 ---
-description: deviations from Teifi's own codebase conventions — the "strong teammate" non-blocking lens
+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
+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
+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
+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
+  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.
+  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
+  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.
+  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 —
+  * 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
@@ -50,12 +50,12 @@ Axes to cover:
   * 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
+  * 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?"
+    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
@@ -64,10 +64,10 @@ Axes to cover:
     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:
+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
+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
@@ -119,12 +119,12 @@ 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.
+  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>)`.
+  `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
@@ -145,14 +145,14 @@ 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" —
+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
+- 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
+- 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 —
+- A finding you cannot quote and cannot fix is a finding you have not proven -
   drop it instead.

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

@@ -1,5 +1,5 @@
 ---
-description: correctness, scalability and integration issues — Teifi's GQL-1 hard rule included
+description: correctness, scalability and integration issues - Teifi's GQL-1 hard rule included
 ---
 ## Lens: lekker-implementation
 
@@ -35,12 +35,12 @@ Axes to cover:
   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.
+  (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 - 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:
@@ -51,26 +51,26 @@ Axes to cover:
   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
+  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
+  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.
+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
+  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
+- 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 —
+- A finding you cannot quote and cannot fix is a finding you have not proven -
   drop it instead.

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

@@ -1,5 +1,5 @@
 ---
-description: quality, security and data-integrity issues — Teifi's TS-1/TS-2 hard rules included
+description: quality, security and data-integrity issues - Teifi's TS-1/TS-2 hard rules included
 ---
 ## Lens: lekker-quality
 
@@ -50,7 +50,7 @@ Axes to cover:
   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] ...`.
+  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
@@ -73,15 +73,15 @@ TS-1 and TS-2 are Teifi hard rules: their text is defined in full in `{{PROFILE}
 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}}` —
+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
+- 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 —
+- 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/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-simplification.md

@@ -6,17 +6,17 @@ description: over-engineering and DRY violations, plus Teifi's debug-artifact hy
 Review the change for over-engineering and DRY violations.
 
 Look for:
-- Copy-paste logic: identical blocks that differ only in a constant — flag
+- Copy-paste logic: identical blocks that differ only in a constant - flag
   for extraction.
-- Parallel implementations: two functions doing the same thing — one should
+- 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.
+  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
+  `{{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
@@ -42,7 +42,7 @@ Look for:
   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.
+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
@@ -55,9 +55,9 @@ 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
+- 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 —
+- A finding you cannot quote and cannot fix is a finding you have not proven -
   drop it instead.