@mrciphersmith/keryx 0.2.98 → 0.2.99

package/src/gdskills/bundled/skills/review/review-core-boundaries/SKILL.md

@@ -6,10 +6,14 @@ description: |
   direction, feature-boundary leakage, abstraction stability, composition,
   and blast-radius risks. Dispatched by review-orchestrator for
   --core-boundaries, --project-conventions, --all, or src/core/** changes.
+  NOT for: logic correctness in code that happens to live in core (review-logic),
+  naming and readability (review-style), or SOLID and layering inside a feature
+  module (review-architecture).
 triggers:
+  - "core review"
+  - "shared boundary"
+  - "public surface"
   - "review core boundaries"
-  - "review --core-boundaries"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
@@ -127,3 +131,33 @@ conditions land under that rubric.
 
 "Broad blast radius" is not by itself a `blocker`. Name the consumer that breaks.
 
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "It is generic enough to live in core." | Generic enough is not shared. Name the second consumer that needs it today; one feature's helper parked in core is exactly the leak this lane exists to catch, whatever the file is called. |
+| "Core has broad blast radius, so this is a `blocker`." | Blast radius is a property of the module, not of the change. Name the consumer that breaks and what breaks in it, or it is `info` under shared law 1. |
+| "It is only a type import, so core does not really depend on the feature." | The import is in the source and in the build graph. Delete the feature module and core stops compiling — direction is decided by what core names, not by what survives type erasure. |
+| "The new export has one consumer today, so the surface is still stable." | A public core export is a contract with every module that installs it. One consumer is the argument for keeping the helper internal, not for exporting it. |
+| "I cannot enumerate every consumer of a core symbol, so I will anchor the finding at the file the diff touched." | Consumers of a core export are precisely what a search enumerates. A `class_scope` with no `enumeration_method` is the one-site fix that leaves the siblings for the next round. |
+| "The move into core is temporary — it gets extracted properly later." | Nothing downstream records that intent, and a core import is load-bearing the moment it ships. Rate the code in the diff, not the plan described beside it. |
+
+---
+
+## Verification
+
+Report done only once all of these hold:
+
+- Every finding names `file:line` and the evidence that settles it — the import,
+  the export, or the consumer — quoted from the tree rather than described.
+- Every `blocker` and `major` carries `class_scope` with `sites` and an
+  `enumeration_method` naming the search that produced them.
+- No finding invents a severity: each lands under **Severity (canonical)** in
+  `review-orchestrator/SKILL.md`.
+- Every blast-radius claim names the consumer that breaks. Unnamed ones are
+  `info`, and say what would settle them.
+- The reply is the `REVIEW_RESULT` the Orchestrated Review Contract asks for, or
+  `NEEDS_CONTEXT` naming the context that was missing — never a guess in its place.
+

package/src/gdskills/bundled/skills/review/review-flow-graph/SKILL.md

@@ -7,10 +7,13 @@ description: |
   boundaries, selection lifecycle, and large-graph performance. Dispatched by
   review-orchestrator for --flow-graph, --project-conventions, --all, or
   src/core/flow/** / graph abstraction changes.
+  NOT for: React and MobX component structure outside the graph surface
+  (review-frontend), render cost elsewhere in the app (review-performance), or
+  the domain rules a graph happens to display (review-logic).
 triggers:
-  - "review flow graph"
-  - "review --flow-graph"
-  - dispatched by review-orchestrator
+  - "flow graph review"
+  - "graph ui review"
+  - "reactflow review"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
@@ -152,3 +155,34 @@ conditions land under that rubric.
 | Internal helper reaching across a boundary with no observable consequence | `minor` | Correct today; the cost is to the next editor |
 | Surface concern with no named caller | `info` | Shared law 1 |
 
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "The domain module imports the internal shell directly, but it renders fine." | Rendering is not the contract. The public graph surface is what the next refactor of the shell is allowed to change; a consumer reaching past it is the break waiting to happen, and it is reportable today. |
+| "Only one consumer needs this helper, so exporting it from the graph surface is harmless." | An export is a promise to every future consumer. The rule in the checklist is two consumers, and one is the argument for leaving the helper internal. |
+| "This graph felt slow when I read the code." | A performance claim here is a claim about a node and edge count. Name the count at which it degrades, or the finding is `info` under shared law 1. |
+| "Deep observation on the nodes array is fine — the library is fast." | The cost is proxying every node on every write, and it scales with the array, not with the library. If you are rating it, state the array size the diff can produce. |
+| "The subclass sets up its own reactivity first; base initialisation order is an implementation detail." | The base store's state is what the base selection, click and reset behaviour reads. Initialising after it is the documented lifecycle, not a style preference. |
+| "The layout ran, so the lifecycle is intact." | Selection, expand/collapse and reset each have their own lifecycle. A layout that completes says nothing about whether a domain side effect swallowed the base selection reset. |
+
+---
+
+## Verification
+
+Report done only once all of these hold:
+
+- Every finding names `file:line` and the evidence that settles it — the import,
+  the export, the subclass member, or the measured count.
+- Every `blocker` and `major` carries `class_scope` with `sites` and an
+  `enumeration_method` naming the search that produced them — for a surface
+  finding, every consumer of the symbol, not only the one in the diff.
+- Every performance finding states the node/edge count at which the cost applies;
+  without one it is `info`.
+- No finding invents a severity: each lands under **Severity (canonical)** in
+  `review-orchestrator/SKILL.md`.
+- The reply is the `REVIEW_RESULT` the Orchestrated Review Contract asks for, or
+  `NEEDS_CONTEXT` naming the context that was missing — never a guess in its place.
+

package/src/gdskills/bundled/skills/review/review-frontend/SKILL.md

@@ -3,13 +3,11 @@ name: review-frontend
 model_tier: standard
 description: "Use when a frontend review is requested, checking React component patterns, MobX state management (observer, actions, computed, reactions, lifecycle), View-Store boundaries, and TypeScript safety in changed frontend code. NOT for backend patterns, security vulnerabilities, performance bottlenecks, or cross-layer architecture."
 triggers:
-  - "review frontend"
   - "frontend review"
+  - "component review"
+  - "ui review"
   - "review React"
-  - "review MobX"
-  - "review store"
   - "review components"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.1.0"

package/src/gdskills/bundled/skills/review/review-frontend-conventions/SKILL.md

@@ -8,10 +8,14 @@ description: |
   styling tokens, Storybook expectations, and local tooling rules. Dispatched
   by review-orchestrator for --frontend-conventions, --project-conventions,
   --all, or frontend src/**/*.ts(x) changes when local convention docs exist.
+  NOT for: generic React and MobX correctness with no local rule behind it
+  (review-frontend), what the CSS actually renders (review-layout), or naming and
+  readability as a matter of taste (review-style).
 triggers:
+  - "frontend conventions"
+  - "local frontend rules"
+  - "CLAUDE frontend"
   - "review frontend conventions"
-  - "review --frontend-conventions"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
@@ -177,3 +181,33 @@ conditions land under that rubric.
 | Naming, story coverage, file placement | `minor` | Correct today; the cost is to the next editor |
 | A convention preference with no named consequence | `info` | Shared laws 1 and 2 |
 
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "There is no project guide here, but I know what good React looks like." | Then you are running the neutral baseline, and you must say so in the report. A preference with no local rule and no named consequence is `info`, not a convention violation — this lane's authority comes from the project's own documents. |
+| "The guide says one thing but the newer files all do another, so that is the convention." | A pattern repeated in code is a candidate convention, not a decision. Cite the guide and name the divergence; let the team choose which one moves. |
+| "The linter already fails on this, so it is at least `major`." | The machine catches it before merge. A reviewer restating a lint error spends a merge gate on something no human can ship past, which is why the rubric above puts it at `minor`. |
+| "It is one direct `localStorage` call — the wrapper is overkill here." | The wrapper exists because the raw API throws on quota and is absent in some environments. One unguarded call is the class; enumerate the others before deciding it is small. |
+| "This component does not read observables, so it does not need the reactive wrapper." | Check what it reads through props and through the store getters it calls. Lost reactivity is silent, which is why it is rated the same here as in `review-frontend`. |
+| "The inline `style` is dynamic, so the token rule does not reach it." | Only the computed part is dynamic. Colours and spacing inside it still come from the local tokens, and mixing the two is how a theme change stops applying to one surface. |
+
+---
+
+## Verification
+
+Report done only once all of these hold:
+
+- The report names which local convention documents were found and read, or
+  states plainly that none exist and only the neutral baseline ran.
+- Every finding cites the local rule it rests on — the guide, the lint config, or
+  the baseline section above — and names `file:line`.
+- Every `blocker` and `major` carries `class_scope` with `sites` and an
+  `enumeration_method` naming the search that produced them.
+- No finding invents a severity: each lands under **Severity (canonical)** in
+  `review-orchestrator/SKILL.md`.
+- The reply is the `REVIEW_RESULT` the Orchestrated Review Contract asks for, or
+  `NEEDS_CONTEXT` naming the context that was missing — never a guess in its place.
+

package/src/gdskills/bundled/skills/review/review-highload/SKILL.md

@@ -11,13 +11,11 @@ description: |
   (review-performance), clean code style (review-clean-code), or NestJS module structure
   (review-architecture).
 triggers:
-  - "review highload"
-  - "review scalability"
   - "highload review"
-  - "review concurrency"
+  - "concurrency review"
+  - "race condition"
+  - "review scalability"
   - "review distributed"
-  - "review --highload"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"

package/src/gdskills/bundled/skills/review/review-layout/SKILL.md

@@ -12,10 +12,9 @@ description: |
   naming and readability (review-style), re-render cost (review-performance), React or
   MobX structure (review-frontend).
 triggers:
-  - "review layout"
   - "layout review"
+  - "review layout"
   - "does this render correctly"
-  - "dispatched by review-orchestrator"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
@@ -215,3 +214,25 @@ a claim that the class has exactly one member — make it deliberately.
 | "The class names look fine." | This lane does not review class names. That is `review-frontend-conventions`. |
 | "I could not run the visual tier, so I reasoned it out." | Then it is `info`, marked unverified. Reasoning does not become measurement by being careful. |
 | "RTL is handled, the component uses logical properties." | Check the gradients, shadows and transforms too. Those are the ones that do not flip. |
+
+---
+
+## Verification
+
+Report done only once all of these hold:
+
+- Every finding carries a **measurement**: the host width, the element width or
+  the offset in pixels, and the command or probe that produced it. An unmeasured
+  observation is filed as `info`, marked unverified, and says what would settle it.
+- The measurement was taken at the worst real case — the longest translation in
+  the catalog, the narrowest supported host, the state where the sibling is
+  absent — not at the convenient one.
+- Every finding names `file:line` on the component that renders the box.
+- Every `blocker` and `major` carries `class_scope` with `sites` and an
+  `enumeration_method` naming the search that derived the set of elements sharing
+  the sizing shape.
+- No finding invents a severity: each lands under **Severity (canonical)** in
+  `review-orchestrator/SKILL.md`.
+- The reply is the `REVIEW_RESULT` the Orchestrated Review Contract asks for, with
+  finding ids prefixed `LY-`, or `NEEDS_CONTEXT` naming the context that was
+  missing — never a guess in its place.

package/src/gdskills/bundled/skills/review/review-logic/SKILL.md

@@ -9,12 +9,12 @@ description: |
   NOT for: security vulnerabilities, performance profiling, style/naming preferences,
   or architectural pattern concerns — those belong in their respective specialized reviewers.
 triggers:
-  - "review logic"
+  - "logic review"
+  - "bug review"
+  - "correctness"
   - "check correctness"
   - "are there any bugs"
   - "check this for bugs"
-  - "logic review"
-  - "dispatched by review-orchestrator"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"

package/src/gdskills/bundled/skills/review/review-orchestrator/SKILL.md

@@ -1,36 +1,16 @@
 ---
 name: review-orchestrator
-description: |
-  Use when: a code review is requested and the user does not explicitly name a specialized reviewer.
-  Handles "review", "code review", "review PR", "review --frontend", "review --backend",
-  "review --architecture", "review --security", "review --performance", "review --style",
-  "review --verify", "review --project-conventions", "review --legacy-profiles", "review --all". Routes to specialized reviewers in parallel and
-  consolidates findings into one unified report.
-  NOT for: running a single specialized reviewer — invoke it directly by name instead.
+description: 'Use when: a code review is requested and the user does not name a specialized reviewer — "review", "code review", "review this PR", "review --all". Dispatches the relevant specialized reviewers in parallel and consolidates their findings into one unified report, and owns the fan-out flags "--all", "--project-conventions" and "--legacy-profiles". NOT for: running a single specialized reviewer — invoke it directly by name instead, which is also how a flag that names one domain reaches its reviewer.'
 triggers:
   - "review"
-  - "code review"
+  - "ревью"
+  - "review code"
+  - "full review"
+  - "review changes"
   - "review PR"
-  - "review --frontend"
-  - "review --backend"
-  - "review --architecture"
-  - "review --security"
-  - "review --performance"
-  - "review --style"
-  - "review --verify"
   - "review --all"
-  - "review --clean-code"
-  - "review --highload"
   - "review --project-conventions"
-  - "review --frontend-conventions"
-  - "review --testing-practices"
-  - "review --core-boundaries"
-  - "review --flow-graph"
   - "review --legacy-profiles"
-  - "review --code-ai"
-  - "review --learned"
-  - "review --code-style"
-  - "review --mobx-store"
 metadata:
   author: "MrCipherSmith"
   version: "1.9.0"
@@ -1163,10 +1143,10 @@ Skipped reviewers:
 | `--verify` | `review-verifier`, AFTER all others; checks the consolidated findings by running something. Delete-only. |
 | (auto) | detected from diff file extensions — see Auto-detection table |
 
-Multiple flags may be combined. Example: `review --backend --security` dispatches
-`review-logic` + `review-backend` + `review-architecture` + `review-security-code`.
-Example: `review --frontend --frontend-conventions` dispatches the generic frontend set plus the
-local frontend conventions reviewer.
+Multiple flags may be combined: `review --backend --security` dispatches `review-logic` + `review-backend` + `review-architecture` + `review-security-code`; `review --frontend --frontend-conventions` dispatches the generic frontend set plus the local frontend conventions reviewer.
+
+This table applies once this skill is running; reaching it is a separate question. The router strips `--`, so `review --style` is the same phrase as `review-style`'s own `style review` trigger and goes straight there — the same destination this table names, and likewise for `--architecture`, `--security` and `--performance`. Only `--all`, `--project-conventions` and `--legacy-profiles` name this orchestrator, which is why they are its triggers.
+`--frontend` and `--backend` are the exception: this table fans each out to three reviewers, but a bare `review --frontend` reaches `review-frontend` alone, because `review frontend` and `frontend review` are one phrase to the router and that phrase is the specialist's — two skills may not share a trigger token set (`src/gdskills/catalog-single-source.test.ts`). Ask by name, or use `review --all`, when you want the three-reviewer fan-out; `docs/skills/rejected-skill-changes.md` records the alternatives that were measured and rejected.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-performance/SKILL.md

@@ -3,12 +3,12 @@ name: review-performance
 model_tier: standard
 description: "Use when a performance review is requested, checking for N+1 queries, unnecessary re-renders, memory leaks, missing indexes, large bundle imports, and synchronous blocking in changed code. NOT for security, logic correctness, style, or architecture."
 triggers:
-  - "review performance"
   - "performance review"
+  - "perf check"
+  - "slow"
   - "check for perf issues"
   - "perf review"
   - "check N+1"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
@@ -235,6 +235,12 @@ boundary is the trigger-and-outcome test.
    frequency *is* the trigger shared law 1 asks for.
 2. **Do not flag patterns outside the diff.** Review only changed code. Legacy
    issues outside the diff are `info` at most, with a note to track separately.
+3. **An optimisation with no before/after is an unmeasured claim, and a neutral
+   one is a finding.** Ask what was measured and on what workload. No pair at all
+   is `minor` — unjustified, not wrong. A neutral pair is `major`, and the fix it
+   suggests is a revert: what counts as neutral under noise, and what the attempt
+   owes the journal, are `perf-check`'s Rules, not restated here. Writing that
+   entry is the author's job, not yours; a revert with no entry is its own `minor`.
 
 ---
 
@@ -340,11 +346,9 @@ Stop and re-read these rules if you are thinking:
 | Rationalization | Why it's wrong |
 |---|---|
 | "This loop iterates over user data, so N+1 is obviously a problem" | State the expected N and query cost; "user data" is not self-evidently large |
-| "I'll flag this as major because it looks slow" | Looking slow is not a hot path; cite the execution context |
 | "Missing useMemo here is a performance issue" | useMemo has overhead; only flag when the computation is measurably expensive or the component re-renders at high frequency |
-| "I'll add a minor finding for every lodash default import" | Correct — but only flag if the library is large and the import is demonstrably not tree-shaken |
 | "The dataset could grow large, so I'll call it a blocker" | "Could grow" = minor or info; known to be large = major or blocker |
-| "Skipping the hot-path citation to keep the finding concise" | Performance law 1: the hot path is mandatory for blocker/major; omitting it means downgrading to `info` |
+| "The optimisation measures neutral, but it does no harm — no reason to hold the diff" | The complexity it bought with no measured gain *is* the harm, and it passes review precisely because nothing in it is wrong. Neutral is `revert`, per performance law 3 |
 
 ---
 
@@ -365,10 +369,6 @@ If provided and the file exists, read the context document before starting the r
 
 If the file does not exist or is not provided, proceed normally — context is optional and non-blocking.
 
-
 ## Orchestrated Review Contract
 
 When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `.metaproject/skills/gdskills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
-
----
-

package/src/gdskills/bundled/skills/review/review-pr-feedback/SKILL.md

@@ -9,13 +9,14 @@ description: |
   NOT for: reviewing code directly — this skill reads human or bot PR feedback and
   makes it actionable. To review code, use the domain review skills.
 triggers:
-  - "analyze PR comments"
   - "review PR feedback"
+  - "analyze PR comments"
+  - "review comments"
+  - "fix PR comments"
   - "what did reviewers say"
   - "parse PR #N"
   - "explain PR comments"
   - "PR feedback"
-  - "fix PR comments"
   - "review-pr-feedback --fix"
 metadata:
   author: "MrCipherSmith"

package/src/gdskills/bundled/skills/review/review-regression/SKILL.md

@@ -10,8 +10,7 @@ description: |
 triggers:
   - "review regression"
   - "does this change break anything"
-  - "blast radius review"
-  - "dispatched by review-orchestrator"
+  - "blast radius"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
@@ -183,3 +182,35 @@ Severity levels are defined once, in `review-orchestrator/SKILL.md` →
 **Severity (canonical)**. This reviewer does not restate them: `blocker` is the
 four merge-blocking shapes named there and nothing else, and the `major`/`minor`
 boundary is the trigger-and-outcome test.
+
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "This code in the blast radius is badly written, so I will say so." | Scope B asks one question, and it is not that one. The screen rejects it as `outside-set` or as `non-regression-severity`, and the round is spent on a finding nobody reads. |
+| "The caller might break." | Might is not a regression. Name the argument that is no longer passed, the type that narrowed, the branch that went away — or file nothing. Below `major` the screen rejects it by construction. |
+| "I will anchor the finding at the changed line, since that is the cause." | Scope A already reviewed that line. Anchor where the damage lands: the caller a human has to open is the one that breaks. |
+| "The blast radius came back empty, so the change breaks nothing." | An empty radius for a non-code change is recorded as unresolved, not clean. Say the radius could not answer the question — silence that reads as "nothing found" is the failure this lane was built to stop. |
+| "It is a `major` about a dependent and the anchor names the file, so the link to the change is obvious." | `no-link-to-change` is a substring match over your prose, and only a `blocker` is exempt from it. Name the changed file, module or symbol in the finding text or it is dropped before it reaches `findings.json`. |
+| "The set was capped, but I covered the important ones." | The cap is recorded. If files were dropped, say so in the summary; a report that implies a complete sweep over a truncated set is a false claim about coverage. |
+| "The change is only reached through a spawned process / a string-keyed lookup, so the graph must have missed it — I will report it anyway." | Report it, and say the graph could not see the edge. What you must not do is present a runtime path as if the computed set produced it. |
+
+---
+
+## Verification
+
+Report done only once all of these hold:
+
+- Every finding is anchored inside the computed set or the changed set, at the
+  code that **breaks** rather than the code that changed.
+- Every finding is `major` or above, and every `major` names the changed file,
+  module or symbol whose behaviour moved — the anchor alone does not carry it.
+- Every finding carries `class_scope` whose `sites` are the callers that break and
+  whose `enumeration_method` is the walk over the blast-radius set that produced
+  them.
+- The summary states whether the cap dropped files, and whether the radius could
+  answer the question at all for the shape of this change.
+- Nothing that is merely an observation about pre-existing code is filed here; it
+  is either raised under scope A or not at all.

package/src/gdskills/bundled/skills/review/review-security-code/SKILL.md

@@ -3,12 +3,14 @@ name: review-security-code
 model_tier: standard
 description: "Use when a code-level security review is requested, checking for injection vulnerabilities, auth gaps, insecure cryptography, secrets, and OWASP Top 10 patterns in changed code. NOT for infrastructure, deployment, or dependency audits."
 triggers:
-  - "review security"
   - "security review"
+  - "проверь безопасность"
+  - "безопасность кода"
+  - "secure code"
+  - "vulnerability"
   - "check for vulnerabilities"
   - "security check"
   - "OWASP review"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"

package/src/gdskills/bundled/skills/review/review-style/SKILL.md

@@ -8,11 +8,11 @@ description: |
   NOT for: logic bugs, architectural violations, security vulnerabilities, performance
   anti-patterns, or any finding that could cause a functional regression.
 triggers:
-  - "review style"
   - "style review"
+  - "readability"
+  - "clean up"
   - "check naming"
   - "check readability"
-  - "review --style"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"

package/src/gdskills/bundled/skills/review/review-testing-practices/SKILL.md

@@ -10,11 +10,15 @@ description: |
   cannot fail is found by executing it rather than by reading it.
   Dispatched by review-orchestrator for --testing-practices,
   --project-conventions, --all, or changed test/e2e/story files.
+  NOT for: the correctness of the production code a suite covers (review-logic),
+  or naming and readability inside a test with no effect on what it pins
+  (review-style).
 triggers:
+  - "test review"
+  - "testing practices"
+  - "coverage quality"
   - "review tests"
   - "review testing practices"
-  - "review --testing-practices"
-  - dispatched by review-orchestrator
 metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
@@ -279,3 +283,37 @@ the unpinned code do the wrong thing**, that is a separate finding at the severi
 its own outcome earns — usually `major`. The coverage gap and the defect are two
 findings, not one, and conflating them loses whichever the adjudicator disbelieves.
 
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "The suite is green, so the tests pin the behaviour." | Green is the state before the mutation pass, not its result. Delete the gate, run the nearest suite, and report what happened — that is the one question this reviewer exists to answer. |
+| "I could not run the suite, so I worked out what the mutation would do." | A predicted mutation is `info` at best and this lane has no use for one. Say which command you ran, what stopped it, and skip the pass — do not report a result you did not observe. |
+| "I only published the mutations that survived; the rest were noise." | The reds are what makes the greens mean something. A table of survivors alone reads as cherry-picking and will be discounted whole. |
+| "The fixture is named `drift-only`, so it covers the drift case." | The name is the claim under review. Open the producer and compare every field, not only the one the test pins; a fixture that carries another scenario's shape is coverage that lies. |
+| "Mocking the API module is simpler than standing up the network boundary." | It also deletes the layer where the bug lives — serialisation, status handling, the error path. Simpler is the reason the convention exists to overrule. |
+| "This test is flaky, that is a `blocker`." | Flake wastes time; it does not ship a defect. `major`. The one `blocker` in this lane is a test that cannot fail while the behaviour it names is broken. |
+| "I mutated more gates than my budget allowed, but I got through most of them." | Say how many you did not reach. A stated cap is a result; silence reads as a complete sweep and the next round inherits the gap without knowing it. |
+
+---
+
+## Verification
+
+Report done only once all of these hold:
+
+- The mutation table is published in full, survivors and casualties both, or the
+  report says which command failed and that the pass was skipped.
+- The report states the cap: how many added or previously-requested gates were
+  mutated and how many were not reached.
+- Every finding names `file:line` and the evidence that settles it — the mutation
+  and its result, the producer line, or the selector that names the branch.
+- Every `blocker` and `major` carries `class_scope` with `sites` and an
+  `enumeration_method` naming the search that produced them.
+- No finding invents a severity: each lands under **Severity (canonical)** in
+  `review-orchestrator/SKILL.md`, and a coverage gap is filed separately from any
+  defect it exposes.
+- The reply is the `REVIEW_RESULT` the Orchestrated Review Contract asks for, or
+  `NEEDS_CONTEXT` naming the context that was missing — never a guess in its place.
+

package/src/gdskills/bundled/skills/review/review-verifier/SKILL.md

@@ -12,8 +12,8 @@ description: |
 triggers:
   - "verify findings"
   - "review --verify"
-  - "check these findings"
   - "verification pass"
+  - "check these findings"
 metadata:
   author: "MrCipherSmith"
   version: "1.1.0"