@olegkoval/agent-skills 1.43.1 → 1.45.0

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.

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

@@ -0,0 +1,172 @@
+---
+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.
+
+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 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
+     thrown / a function returned truthy?
+   - Are assertions on the correct thing? (e.g. checking the return value vs
+     a side-effect that is the actual goal of the operation)
+   - Are there tautological assertions that are always true regardless of the
+     implementation? (e.g. `expect(true).toBe(true)`,
+     `expect(x).toBeDefined()` when x is always defined by construction)
+
+b) Condition coverage
+   - Is the happy path tested?
+   - Are failure / error paths tested? (invalid input, external API error,
+     empty collection, null/undefined, 0 or negative numbers, pagination edge
+     cases, missing env vars)
+   - For every new if/else or switch in the changed business logic, is each
+     branch exercised by at least one test case?
+
+c) Regression tests
+   - If the change fixes a bug (the ticket mentions a bug, or the diff
+     contains "fix" language), is there a regression test that would have
+     caught the original bug? Flag if absent.
+   - If the change adds a new feature, are the known edge cases of that feature
+     tested?
+
+d) Mutation-slip analysis (mental mutation testing)
+   For the most critical assertions in the test suite, ask: would a simple
+   mutation in the production code slip through undetected?
+
+   Consider these mutation classes:
+   - Off-by-one: `> N` changed to `>= N`
+   - Operator flip: `&&` to `||`, `===` to `!==`
+   - Missing null/undefined guard: remove a `?? default`
+   - Wrong variable: using `a` where `b` was intended
+   - Return-value swap: returning the wrong field from an object
+   - Early-return removed: a guard clause deleted
+
+   For each mutation class relevant to the changed business logic, determine
+   whether at least one test assertion would catch it. Summarize as a short
+   paragraph: "Mutations that would slip through: ..." or "No obvious
+   mutation-slip gaps found."
+
+e) Test isolation and reliability
+   - Do tests share mutable state across cases without resetting between runs
+     (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
+     axis (g).
+   - Are async tests properly awaited? (floating promises, missing `await` on
+     `expect().resolves`, unhandled rejections)
+
+f) Test-to-code ratio signal
+   If the diff adds > 50 lines of new business logic with zero new or modified
+   test files, flag it explicitly. Then check whether existing test files
+   already cover the new code paths:
+   ```bash
+   find <workdir> -name "*.test.ts" -o -name "*.spec.ts" | \
+     xargs grep -l "<key changed symbol>" 2>/dev/null | head -5
+   ```
+   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" —
+   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
+   into a pure function (functional core) and test that directly, leaving a thin
+   shell covered by a few real integration tests.
+
+   - Mocking IO just to reach logic: a GraphQL/fetch/DB client mocked only so a
+     test can read a computed value back. It couples to the query shape AND the
+     markup while barely testing the logic, and silently rots as the real
+     dependency drifts from the mock. This applies just as much on the backend
+     as in a component: mocking a service client (e.g. `vi.mocked(epicorClient)`
+     returning a canned async generator/array) just to reach a reassembly loop
+     or a multi-stream join is the same smell as mocking `fetch` in a component.
+     → Extract the computation into a pure function over plain data and test
+       that with literals (no mocks, no render, no mocked client). Cover
+       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
+       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`,
+     `toHaveBeenCalledTimes`, a `vi.fn()` used as a probe. Asserts *how* a
+     function was called, freezing batching/page-size/call-count in place even
+     when the output is identical.
+     → Assert the output, never the call log. If a boundary is genuinely
+       needed, inject a simple fake (a plain function returning canned data),
+       not a spy.
+   - Mocking a component to read its props back (re-emitting props as `data-*`
+     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
+       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
+     return shape.
+     → Keep the `queryFn` as IO (integration-tested); move the transform into a
+       pure function wired through React Query's `select` option, and unit-test
+       that pure function with plain data.
+   - Asserting implementation details: that a component is memoized, that a
+     specific child renders, that work happens through a fixed sequence of
+     calls.
+     → Delete the assertion; assert the user-visible behavior instead.
+
+   When a mock IS the right call, do NOT flag it: a real IO boundary that must
+   be exercised where a fake is impractical, non-determinism that must be pinned
+   (time, randomness, injected network failure), or a dependency that genuinely
+   cannot run in the test environment. The tell for a good mock: the behavior
+   under test only exists because the boundary did something (e.g. a retry
+   banner that appears only when the fetch rejects). Even then, prefer an
+   injected simple fake over a module-level spy, and assert what the user sees.
+
+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
+   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
+   exhaustiveness assertion whenever behaviour depends on 3+ independent inputs.
+   A `vi.mock('@lib/common/…')` inside `common/` is major, not style: the
+   alias resolves only from `web/`, so the mock silently does nothing and the
+   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.
+
+Report each per-line issue as:
+`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.
+
+Rules:
+- Every per-line finding must trace to test code in the diff, OR to business
+  logic added in the diff that has no test coverage at all.
+- 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
+  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.
+- A finding you cannot quote and cannot fix (outside the no-coverage case
+  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

@@ -0,0 +1,42 @@
+# Phase 4: revmux engine on real PRs
+
+One row per live `--engine revmux` run. Numbers come from revmux `stats` via
+`scripts/revmux-adapter.mjs`; USD is the `pricing.json` list-price placeholder
+(`verified: false`, output price applied to every token, synth+verify unpriced),
+and every run so far went through the Max subscription, so USD is a relative
+signal only. "Confirmed" means the main loop kept the finding after reading the
+worktree; "merged" means two revmux findings described one mechanism.
+
+| Date | PR | Depth | Wall | Tokens | USD est. | revmux findings | Kept | Re-severity | Hard-rule re-promotions | Merged | False positives |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| 2026-09-09 | evi-integrations #544 | medium (auto) | 15m40s | 12,604,506 | $169.53 | 4 | 3 (1 C / 2 I) + obs | 1 important → critical (lost role grants, watermark written before post-pass) | 0 | 0 | 0 |
+| 2026-09-09 | evi-integrations #537 | deep (auto, *.sql) | 11m08s | 11,245,064 | $141.61 | 4 | 3 (0 C / 2 I / 1 idiomatic) + obs | none | 0 | 1 (#1 reactivation + #4 guard removal → one Important) | 0 |
+
+## Notes per run
+
+### #544
+
+- revmux under-rated the watermark ordering bug as important; the main loop
+  raised it to Critical after tracing `executeSyncStrategy` writing the CUSTOMER
+  watermark before the role post-pass.
+- One finding referenced `getShopFlag`, which does not exist in this repo;
+  rewritten to an env toggle with Reflag as the policy target. Class: fix code
+  invented from another repo's helper. Worth a lens note.
+- Depth medium, so verify ran on Criticals only; revmux's own verify stage
+  covered all four.
+
+### #537
+
+- Two of four findings were the same mechanism seen from two lenses (bugs,
+  adversarial). Synthesis did not merge them; the main loop did.
+- All four confirmed against the worktree. The idiomatic one (comment
+  narrating deleted code) is exactly the teifi-conventions §2 class.
+- Reactivation and soft-delete files are outside the diff, so the main
+  finding could only be anchored on the sync-path signal it replaces.
+
+## 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.