@mrciphersmith/keryx 0.2.69 → 0.2.71

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

package/src/gdskills/bundled/skills/review/code-mobx-store-review/SKILL.codex.md

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 ---

package/src/gdskills/bundled/skills/review/code-mobx-store-review/SKILL.cursor.md

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 ---

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

@@ -9,8 +9,9 @@ metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
+  stack_requires: "mobx"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 ---

package/src/gdskills/bundled/skills/review/code-mobx-store-review/SKILL.opencode.md

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 ---

package/src/gdskills/bundled/skills/review/code-mobx-store-review/SKILL.zed.md

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 ---

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

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

@@ -9,8 +9,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode"
 ---
 
 

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

@@ -1,5 +1,6 @@
 ---
 name: review-architecture
+model_tier: deep
 description: |
   Use when: reviewing code for architectural violations — layer violations, dependency direction
   mistakes, module boundary coupling, SOLID principle breaches, NestJS module/provider structure,
@@ -7,7 +8,6 @@ description: |
   Triggered by: "review architecture", "check architecture", "architectural review",
   or dispatched by review-orchestrator with --architecture or --backend.
   NOT for: style/naming preferences, logic correctness bugs, or security vulnerabilities.
-version: "1.0.0"
 triggers:
   - "review architecture"
   - "check architecture"
@@ -19,8 +19,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review Architecture
@@ -257,16 +257,43 @@ observation is theatre, not rigour.
   ```
 ```
 
-Severity guide for this reviewer:
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no table of its own; what follows is where its recurring
+conditions land under that rubric, not a second rubric.
 
-| Severity | When to use |
-|----------|------------|
-| `blocker` | Circular dependency causing runtime failure; NestJS module scope mismatch causing incorrect behavior; domain importing infrastructure breaking testability entirely |
-| `major` | Clear layer violation (API call in component, business logic in controller); broken DIP; cross-module boundary coupling that will cause maintainability failures |
-| `minor` | SRP smell with clear separation path; ISP violation; component using multiple raw observables instead of computed |
-| `info` | Architectural opinion without clear violation; pattern that could be improved but works correctly |
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| Circular dependency that fails at runtime (an import resolves to `undefined` on a path the change reaches) | `blocker` | Crash |
+| Module scope mismatch that produces wrong data across requests | `blocker` | Data corruption |
+| Layer violation — API/IO call in a component, business logic in a controller, domain importing infrastructure | `major` | A named trigger and a named outcome, but structural: not a crash, data loss, vulnerability, or missing acceptance criterion. Identical to `review-frontend`'s rule for the same condition |
+| Broken DIP; cross-module coupling with a named consequence | `major` | Same |
+| SRP smell with a clear separation path; ISP violation; a component reading several raw observables instead of a computed | `minor` | The code is correct; the cost is to whoever restructures it next |
+| Architectural opinion with no named violation | `info` | Shared laws 1 and 2 |
+
+A circular import that resolves cleanly is not a `blocker` — it is `minor`, and
+if the concern is purely readability it belongs to `review-style`.
+
+## Iron Laws
+
+### Shared laws (every reviewer)
+
+1. **A claim of runtime harm with no reproducible path is `info`.** If you cannot
+   name the input, call, or condition that reaches the code, you have an
+   observation, not a finding. Report it as `info` and say what would settle it.
+2. **Never flag the theoretical.** The path you describe must exist in the code
+   under review. Do not report a safe API because it could be misused, or a
+   pattern because it is often wrong elsewhere.
+3. **One finding per class, not one per occurrence.** When the same shape appears
+   at several sites, report it once and list every site. Ten findings that are one
+   finding hide the other nine problems.
+
+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.
+
+### Architecture laws
 
-Iron laws:
 - Only flag actual violations found **in the diff**, not pre-existing issues untouched by the change.
 - Every finding MUST cite a specific `file:line` from the diff.
 - Architecture opinions without a clear, named violation (layer, SOLID principle, pattern misuse) are `info` only — never `blocker` or `major`.

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

@@ -1,5 +1,6 @@
 ---
 name: review-backend
+model_tier: standard
 description: |
   Use when: reviewing NestJS backend changes — API design, service layer, DTO validation,
   database patterns, and TypeScript correctness. Covers "review backend", "backend review",
@@ -7,7 +8,6 @@ description: |
   NOT for: frontend patterns, MobX, React components, general security vulnerabilities
   (use review-security-code for XSS/injection/auth-bypass), or performance profiling
   (use review-performance).
-version: "1.0.0"
 triggers:
   - "review backend"
   - "backend review"
@@ -18,8 +18,9 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
+  stack_requires: "nestjs,prisma"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review — Backend (NestJS / API / DB)
@@ -175,22 +176,55 @@ Only review files changed in scope. Do not comment on legacy code outside the di
 - No `as any` or unsafe casts (`as unknown as T`) without a comment explaining why
 - `@ts-ignore` / `@ts-expect-error` without explanation comment — flag as `minor`
 
+  **This is the one severity for this condition, repo-wide.** It was previously
+  `minor` here and `major` in `review-strict`, which is deleted. `minor` is what
+  the canonical rubric returns: a suppressed compiler error names no trigger and
+  no observable wrong outcome — the code does exactly what it did before the
+  comment was added. What it costs is the next reader, who cannot tell what was
+  suppressed or whether it is still needed. That is the definition of `minor`.
+  It becomes `major` only when you can name the input the suppressed error was
+  hiding and the wrong value it produces — at which point the finding is about
+  that bug, not about the comment.
+
 ---
 
 ## Iron Laws
 
-| Condition | Severity |
-|-----------|----------|
-| Missing DTO validation on an endpoint accepting user input | **blocker** |
-| `REQUEST`-scoped provider injected into `Singleton` | **blocker** |
-| Leaking stack trace / raw ORM error to API response | **blocker** |
-| Unhandled promise rejection in controller method | **blocker** |
-| String interpolation in raw SQL query | **blocker** |
-| N+1 query (relation loaded in a loop) | **major** (minimum) |
-| Missing transaction on multi-step atomic mutation | **major** |
-| Business logic in controller | **major** |
-| Missing pagination on unbounded list endpoint | **major** |
-| `NOT NULL` column added without default to populated table (migration) | **blocker** |
+### Shared laws (every reviewer)
+
+1. **A claim of runtime harm with no reproducible path is `info`.** If you cannot
+   name the input, call, or condition that reaches the code, you have an
+   observation, not a finding. Report it as `info` and say what would settle it.
+2. **Never flag the theoretical.** The path you describe must exist in the code
+   under review. Do not report a safe API because it could be misused, or a
+   pattern because it is often wrong elsewhere.
+3. **One finding per class, not one per occurrence.** When the same shape appears
+   at several sites, report it once and list every site. Ten findings that are one
+   finding hide the other nine problems.
+
+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.
+
+### Backend conditions
+
+Where this reviewer's recurring conditions land under the canonical rubric. Not a
+second rubric — each `blocker` names which of the four merge-blocking shapes it
+is, and a condition that cannot name one is not a `blocker`.
+
+| Condition | Severity | Shape |
+|---|---|---|
+| Missing DTO validation on an endpoint accepting user input | `blocker` | Exploitable vulnerability |
+| String interpolation in raw SQL query | `blocker` | Exploitable vulnerability |
+| Leaking stack trace / raw ORM error to API response | `blocker` | Exploitable vulnerability (information disclosure) |
+| `REQUEST`-scoped provider injected into a `Singleton` | `blocker` | Data corruption — one request's state is served to another |
+| Unhandled promise rejection in a controller method | `blocker` | Crash |
+| `NOT NULL` column added without a default to a populated table | `blocker` | Data loss — the migration fails or truncates |
+| N+1 query (relation loaded in a loop) | `major` (minimum) | Named trigger and outcome; degradation, not an outage. Same rating as `review-highload` |
+| Missing transaction on a multi-step atomic mutation | `major` — `blocker` where a partial write corrupts persisted state | The outcome decides |
+| Business logic in a controller | `major` | Layer violation. Same rating as `review-architecture` |
+| Missing pagination on an unbounded list endpoint | `major` — `blocker` where an attacker-reachable request exhausts memory | Degradation vs. crash/DoS |
 
 ---
 

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

@@ -1,5 +1,6 @@
 ---
 name: review-clean-code
+model_tier: standard
 description: |
   Use when: reviewing code against Clean Code principles (Uncle Bob) and SOLID at the
   function/class level — meaningful names, small functions, single level of abstraction,
@@ -9,7 +10,6 @@ description: |
   "review --clean-code", or dispatched by review-orchestrator.
   NOT for: architectural layer violations (review-architecture), naming convention formatting
   (review-style), logic correctness bugs (review-logic), or security (review-security-code).
-version: "1.0.0"
 triggers:
   - "review clean code"
   - "check clean code"
@@ -21,8 +21,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review: Clean Code + SOLID
@@ -84,9 +84,35 @@ worsens them.
 
 ## Iron Laws
 
+### Shared laws (every reviewer)
+
+1. **A claim of runtime harm with no reproducible path is `info`.** If you cannot
+   name the input, call, or condition that reaches the code, you have an
+   observation, not a finding. Report it as `info` and say what would settle it.
+2. **Never flag the theoretical.** The path you describe must exist in the code
+   under review. Do not report a safe API because it could be misused, or a
+   pattern because it is often wrong elsewhere.
+3. **One finding per class, not one per occurrence.** When the same shape appears
+   at several sites, report it once and list every site. Ten findings that are one
+   finding hide the other nine problems.
+
+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.
+
+### Clean Code laws
+
 1. **Findings without a specific `file:line` from the diff are not valid findings.** Never cite general observations about the codebase.
-2. **Max severity for a naming issue is `major`.** Pure naming never rises to `blocker` — reserved for issues that break correctness.
-3. **DRY violations require at least 3 repetitions before becoming `major`.** Two occurrences can be accidental; three is a pattern.
+2. **A naming issue is `minor`.** It reaches `major` only when the name has
+   already produced an observable wrong outcome at a call site you can name — a
+   caller misusing the API because of what it is called. "A future reader might
+   misread it" is the maintenance cost that makes it `minor`, not a trigger.
+   Naming is never a `blocker`. (`review-style` carries the identical rule.)
+3. **DRY violations need at least 3 repetitions before they are worth reporting,
+   and they are `minor`.** Two occurrences can be accidental; three is a pattern.
+   Duplication is a cost to whoever edits it next, which is `minor` by the
+   canonical test — report it once, listing every site, per shared law 3.
 4. **SOLID opinions without a named principle and a concrete violation description are `info` only.** State the principle (e.g., SRP), the two responsibilities, and the impact.
 5. **Do not flag language idioms or framework conventions as Clean Code violations.** If it is the standard way to do something in TypeScript / NestJS / React, it is not a violation.
 
@@ -387,14 +413,25 @@ observation is theatre, not rigour.
   ```
 ```
 
-Severity guide for this reviewer:
-
-| Severity | When to use |
-|----------|------------|
-| `blocker` | Swallowed exception (silent failure); constructor performing I/O that prevents testing; LSP violation breaking substitutability at runtime |
-| `major` | Function >40 lines; ≥4 parameters without options object; boolean flag arg; class with two distinct responsibilities; `new ConcreteService()` bypassing DI |
-| `minor` | Poor naming; redundant comment; magic number; 20–40 line function; minor OCP/ISP smell; log+rethrow |
-| `info` | Stylistic opinion; potential future issue with no current concrete violation |
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no table of its own; what follows is where its recurring
+conditions land under that rubric, not a second rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| Swallowed exception hiding a failed operation | `major` — `blocker` only if the caller then persists or returns wrong data | Same wording as `review-logic`, deliberately. Silent failure is wrong behaviour; corruption is a different shape |
+| LSP violation that produces a wrong result or a crash at a named call site | `major`, or `blocker` on the crash/corruption outcome | The outcome decides, not the principle's name |
+| Constructor performing I/O | `major` | Named trigger (constructing it) and named outcome (the I/O runs); untestable is not one of the four shapes |
+| Function > 40 lines; ≥ 4 parameters without an options object; boolean flag argument; class with two distinct responsibilities; `new ConcreteService()` bypassing DI | `minor` | The code is correct. The cost is to whoever reads or edits it next — that is exactly `minor` |
+| Poor naming; redundant comment; magic number; 20–40 line function; OCP/ISP smell; log-and-rethrow | `minor` | Same |
+| Stylistic opinion; a future issue with no current violation | `info` | Neither trigger nor a named maintenance cost |
+
+**Clean Code findings are `minor` by default.** A long function with a named
+responsibility split is a maintenance cost, not observable wrong behaviour, and
+`major` is reserved for findings that name a trigger and an outcome. This
+reviewer previously called a 41-line function `major` and thereby forced
+`REQUEST_CHANGES` on it; that is the exact mis-ranking the canonical rubric
+exists to stop.
 
 ---
 

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

@@ -1,5 +1,6 @@
 ---
 name: review-core-boundaries
+model_tier: deep
 description: |
   Use when reviewing shared core/infrastructure module changes for dependency
   direction, feature-boundary leakage, abstraction stability, composition,
@@ -45,6 +46,27 @@ If a more specific module reviewer also applies, run both.
 
 ---
 
+## Iron Laws
+
+### Shared laws (every reviewer)
+
+1. **A claim of runtime harm with no reproducible path is `info`.** If you cannot
+   name the input, call, or condition that reaches the code, you have an
+   observation, not a finding. Report it as `info` and say what would settle it.
+2. **Never flag the theoretical.** The path you describe must exist in the code
+   under review. Do not report a safe API because it could be misused, or a
+   pattern because it is often wrong elsewhere.
+3. **One finding per class, not one per occurrence.** When the same shape appears
+   at several sites, report it once and list every site. Ten findings that are one
+   finding hide the other nine problems.
+
+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.
+
+---
+
 ## Orchestrated Review Contract
 
 When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/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.
@@ -88,6 +110,16 @@ observation is theatre, not rigour.
 - **Fix**: move to domain module, invert dependency, or extract a truly shared abstraction
 ```
 
-Severity guidance: importing feature code into core or adding feature-specific public API is
-usually `major`; broad shared API breakage can be `blocker`.
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no rubric of its own; what follows is where its recurring
+conditions land under that rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| A core API change that breaks a named consumer at runtime | `blocker` | Crash at a named call site |
+| Importing feature code into core; adding feature-specific public API to core; inverted dependency | `major` | Named trigger (the import) and named outcome (the cycle or the leak), but structural — not one of the four shapes |
+| A generic helper whose names or types lean on one feature's language | `minor` | Works today; the cost is to the next module that needs it |
+| A blast-radius concern with no named consumer | `info` | Shared law 1 |
+
+"Broad blast radius" is not by itself a `blocker`. Name the consumer that breaks.
 

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

@@ -1,5 +1,6 @@
 ---
 name: review-flow-graph
+model_tier: standard
 description: |
   Use when reviewing generic ReactFlow or graph-surface abstraction changes:
   public graph surface, store subclassing, layout lifecycle, internal helper
@@ -71,6 +72,27 @@ baseline.
 
 ---
 
+## Iron Laws
+
+### Shared laws (every reviewer)
+
+1. **A claim of runtime harm with no reproducible path is `info`.** If you cannot
+   name the input, call, or condition that reaches the code, you have an
+   observation, not a finding. Report it as `info` and say what would settle it.
+2. **Never flag the theoretical.** The path you describe must exist in the code
+   under review. Do not report a safe API because it could be misused, or a
+   pattern because it is often wrong elsewhere.
+3. **One finding per class, not one per occurrence.** When the same shape appears
+   at several sites, report it once and list every site. Ten findings that are one
+   finding hide the other nine problems.
+
+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.
+
+---
+
 ## Orchestrated Review Contract
 
 When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/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.
@@ -114,6 +136,15 @@ observation is theatre, not rigour.
 - **Fix**: concrete change aligned with the shared graph surface
 ```
 
-Severity guidance: breaking the public surface or bypassing base selection/layout lifecycle is
-usually `major`; performance regressions on large graphs can be `major` or `blocker`.
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no rubric of its own; what follows is where its recurring
+conditions land under that rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| A graph operation that hangs or exhausts memory at a stated node/edge count | `blocker` | Crash |
+| Breaking the public graph surface; bypassing base selection or layout lifecycle | `major` | Named trigger and outcome; a broken contract is not one of the four shapes |
+| A performance regression on large graphs, with the size that makes it a cost | `major` | Degradation, not an outage — see `review-performance` for the same boundary |
+| 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 |