@olegkoval/agent-skills 1.45.0 → 1.45.1

package/adapters/claude/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/adapters/claude/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/adapters/claude/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/adapters/claude/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.

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

@@ -1,18 +1,18 @@
 ---
-description: whether tests actually catch bugs — mutation-slip analysis, mock smell, Teifi test conventions
+description: whether tests actually catch bugs - mutation-slip analysis, mock smell, Teifi test conventions
 ---
 ## Lens: lekker-test-quality
 
 Review the change with a strict focus on test quality. This is NOT about
-coverage numbers — it is about whether the tests actually catch bugs.
+coverage numbers - it is about whether the tests actually catch bugs.
 
-Step 1 — Inventory the tests. Read the diff at `{{SCOPE}}`. List every test
+Step 1 - Inventory the tests. Read the diff at `{{SCOPE}}`. List every test
 file/spec added or modified. If no test files are in the diff, note that and
 continue to axis (f) below.
 
-Step 2 — For each changed test file, read the full file from `{{WORKDIR}}`.
+Step 2 - For each changed test file, read the full file from `{{WORKDIR}}`.
 
-Step 3 — Evaluate each of these axes:
+Step 3 - Evaluate each of these axes:
 
 a) Meaningful assertions vs. smoke tests
    - Does the test verify a specific outcome, or just that no exception was
@@ -60,7 +60,7 @@ e) Test isolation and reliability
      (a beforeEach that does not clean up)?
    - Are there tests that depend on execution order or global singletons?
    - Could a test make a real network/DB call in CI (flaky)? The fix is a
-     simple injected fake at the boundary, not blanket module mocking — see
+     simple injected fake at the boundary, not blanket module mocking - see
      axis (g).
    - Are async tests properly awaited? (floating promises, missing `await` on
      `expect().resolves`, unhandled rejections)
@@ -75,12 +75,12 @@ f) Test-to-code ratio signal
    ```
    Report whether existing coverage closes the gap or not.
 
-g) Mock smell — test the behavior, not the way it's built
-   (House standard: Notion "To mock or not to mock" —
+g) Mock smell - test the behavior, not the way it's built
+   (House standard: Notion "To mock or not to mock" -
    https://app.notion.com/p/teifi/To-mock-or-not-to-mock-36ff8ed0f7db80f09495d174e3b86cd6)
    Flag tests coupled to *how* the code is built rather than *what* it does for
    the user. For each smell, do NOT just criticize: give the concrete no-mock
-   refactor. The default fix is almost always the same shape — pull the logic
+   refactor. The default fix is almost always the same shape - pull the logic
    into a pure function (functional core) and test that directly, leaving a thin
    shell covered by a few real integration tests.
 
@@ -96,7 +96,7 @@ g) Mock smell — test the behavior, not the way it's built
        fetch-and-wire once with a real integration test. For streaming/paging
        code specifically: a shared `collect()`/reassembly helper should be a
        pure function of `AsyncGenerator<T[]> → Promise<T[]>` (or similar) fed a
-       plain fake generator in its own test — never a mocked client — and any
+       plain fake generator in its own test - never a mocked client - and any
        call-site logic that combines multiple streams (parallel joins, chunked
        batching) should be its own pure function tested the same way.
    - Spying on calls / asserting call shape: `toHaveBeenCalledWith`,
@@ -110,7 +110,7 @@ g) Mock smell — test the behavior, not the way it's built
      attributes, then asserting on them): the assertions are about the mock, and
      break on a component swap or prop rename that changes nothing a user sees.
      → Pull the logic (pagination, display state) into a pure function over
-       plain values — e.g. `paginate(items, page, pageSize)` — and assert the
+       plain values - e.g. `paginate(items, page, pageSize)` - and assert the
        value it returns.
    - Mocking a query hook (`useQuery` / a `use-X` hook) to hand a component
      canned data: re-tests React Query's own plumbing and couples to the hook's
@@ -135,7 +135,7 @@ h) Teifi test conventions
    Read `{{PROFILE}}` and apply its §4 (test conventions) to every test file in
    the diff: `__tests__/` placement beside the source, `.test.ts` vs
    `.test.tsx`, English-sentence test names, `describe` nesting <= 2,
-   `afterEach(cleanup)`, `retry: false` on the test QueryClient (major — its
+   `afterEach(cleanup)`, `retry: false` on the test QueryClient (major - its
    absence hangs the suite on a failing query), the getByRole → getByLabelText
    → getByText → getByTestId priority, module-boundary mocking, `safeParse` for
    Zod schemas, and the typed `it.each` matrix with AC tags plus the
@@ -145,17 +145,17 @@ h) Teifi test conventions
    test passes against the real module. Quote the line, give the relative path
    as the fix.
    A comment explaining WHY a test exists (a captured past bug, a subtle
-   contract) is sanctioned — never flag it as over-commenting.
+   contract) is sanctioned - never flag it as over-commenting.
 
 Report each per-line issue as:
-`test-file:line — <concise description of the gap or weakness>`
+`test-file:line - <concise description of the gap or weakness>`
 
 For every mock-smell finding from axis (g), append the no-mock fix on the next
 line as `→ Fix: <pure-function / simple-fake refactor in one line>`. A
 criticism without a fix is incomplete.
 
 Report the mutation-slip analysis as a single paragraph under a
-"**Mutation-slip risk:**" heading — not as line items.
+"**Mutation-slip risk:**" heading - not as line items.
 
 Rules:
 - Every per-line finding must trace to test code in the diff, OR to business
@@ -163,10 +163,10 @@ Rules:
 - Report problems only. No praise for tests that meet the bar.
 - If no test files are changed AND no existing tests cover the new code paths,
   report: "No test coverage for new code paths."
-- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+- Quote the verbatim offending line(s) - never paraphrased, never reconstructed
   from memory. When the finding IS the absence of a test, there is no test line
   to quote: quote the untested production line(s) from the diff instead, and
   give the test that should exist as the fix. Never drop a "no coverage"
-  finding just because nothing bad is written down — absence is the finding.
+  finding just because nothing bad is written down - absence is the finding.
 - A finding you cannot quote and cannot fix (outside the no-coverage case
-  above) is a finding you have not proven — drop it instead.
+  above) is a finding you have not proven - drop it instead.

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

@@ -37,6 +37,4 @@ worktree; "merged" means two revmux findings described one mechanism.
 ## Still open
 
 - Same PRs through the default `workflow` engine for a side-by-side (Oleg-driven).
-- Read-only enforcement: revmux default `--tools` includes Bash; prompt-enforced
-  only. `--tools=Read,Grep,Glob,WebFetch,WebSearch` override not yet applied.
 - Adapter: price synth + verify once revmux reports a per-model split.