@mrciphersmith/keryx 0.2.70 → 0.2.72

package/src/gdskills/bundled/skills/review/review-orchestrator/reviewer-finding.schema.json

@@ -44,6 +44,13 @@
           "id": {
             "type": "string"
           },
+          "global_id": {
+            "title": "The finding's identity, unique across every review package",
+            "description": "`id` is per-report and collides across packages; `global_id` (`<reviewId>#<id>`) is the join key. A reviewer MINTS nothing: it emits this only when re-reporting a finding it was handed in `prior_findings`, and then it must be carried verbatim, because a re-minted key breaks the round-to-round join it exists to provide. The `pattern` enforces the shape a carried key must still have: anything else joins to nothing while looking like a key. Kept identical to src/gdskills/contracts/review-finding.schema.json. NOTE the deliberate asymmetry: that schema also declares `disposition` and this one does not, because a reviewer states what is wrong and never states what became of it — the same separation that keeps the pipeline's `classification` out of the finding record.",
+            "type": "string",
+            "minLength": 1,
+            "pattern": "^[^#]+#[^#]+$"
+          },
           "severity": {
             "type": "string",
             "enum": [

package/src/gdskills/bundled/skills/review/review-orchestrator/verification-claim.schema.json

@@ -0,0 +1,78 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "verification-claim",
+  "title": "Verifier Result and Verification Claims",
+  "description": "What `review-verifier` returns. It lives beside `reviewer-finding.schema.json` for the same reason that one does: the contract belongs to the consumer that merges it, not to the agent that emits it. The defining property of this shape is what it CANNOT express — there is no `severity`, no `problem`, no `suggested_fix`, no way to add a finding. A verifier can only delete, so the wire format it writes on has no field capable of raising anything. `additionalProperties: false` on a claim is therefore load-bearing rather than tidiness: it is where 'can only delete' stops being an instruction. The merge in src/review/verification.ts enforces the same rule again in code, because a schema is not run by every caller.",
+  "type": "object",
+  "required": ["status", "verifier", "verifications"],
+  "properties": {
+    "status": {
+      "type": "string",
+      "enum": ["DONE", "NEEDS_CONTEXT", "BLOCKED"],
+      "description": "No DONE_WITH_CONCERNS: a verifier has no concerns of its own to report. It checked what it was given, or it could not."
+    },
+    "verifier": {
+      "type": "string",
+      "description": "The reviewer performing verification. Refused when it equals the `reviewer` of a finding it claims: a finding is never verified by the reviewer that raised it (AC9)."
+    },
+    "summary": { "type": "string" },
+    "verifications": {
+      "type": "array",
+      "description": "One claim per finding checked. A finding that was not checked simply has no claim; absence is not a verdict and never removes anything.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["finding", "verdict", "method", "evidence"],
+        "properties": {
+          "finding": {
+            "type": "string",
+            "minLength": 1,
+            "description": "The `global_id` of the finding being checked (`<reviewId>#<id>`). The display `id` is accepted when it is unambiguous within the round, and refused when it is not — `F-001` denotes six different findings in the recorded corpus."
+          },
+          "verdict": {
+            "type": "string",
+            "enum": ["confirmed", "refuted", "unverifiable"],
+            "description": "`unverifiable` is the honest answer whenever nothing could be run, and it is expected to be the majority verdict. Only `refuted` removes anything, and only under verification_mode: filter."
+          },
+          "method": {
+            "type": "string",
+            "enum": ["execution", "site-check", "reasoning"],
+            "description": "How the verdict was reached, strongest first. `execution`: a command or test was run that FAILS IF THE FINDING IS REAL. `site-check`: the class_scope sites were searched for and either exist or do not. `reasoning`: neither was possible."
+          },
+          "evidence": {
+            "type": "string",
+            "minLength": 1,
+            "description": "The command and its result, or the search and its hits. A verdict with nothing behind it is discarded and the finding stays as reported."
+          },
+          "verifier": {
+            "type": "string",
+            "minLength": 1,
+            "description": "Per-claim override of the top-level verifier, for a batch produced by more than one agent. Written onto the finding so the never-self-verify rule can be audited after the fact, not only enforced at write time."
+          }
+        },
+        "if": {
+          "required": ["method"],
+          "properties": { "method": { "const": "reasoning" } }
+        },
+        "then": {
+          "properties": { "verdict": { "const": "unverifiable" } }
+        }
+      }
+    },
+    "needs_context": {
+      "type": "array",
+      "items": { "type": "string" }
+    },
+    "stats": {
+      "type": "object",
+      "additionalProperties": false,
+      "properties": {
+        "confirmed": { "type": "integer", "minimum": 0 },
+        "refuted": { "type": "integer", "minimum": 0 },
+        "unverifiable": { "type": "integer", "minimum": 0 },
+        "not_checked": { "type": "integer", "minimum": 0 }
+      }
+    }
+  },
+  "additionalProperties": true
+}

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

@@ -1,5 +1,6 @@
 ---
 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"
@@ -12,8 +13,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: Performance (Code-Level Bottlenecks)
@@ -208,10 +209,32 @@ Detectable from query patterns in changed code (not from DB schema directly):
 
 ## Iron Laws
 
-1. **Only flag real performance issues, not premature optimization.** A pattern "that could be slow" without a concrete hot path or execution frequency is `info` only.
-2. **Every `blocker` or `major` finding MUST cite the specific hot path or frequency that makes it a real problem.** "Runs on every keystroke", "called per list item (N=potentially thousands)", "executes on every render of a high-frequency parent" — be specific.
-3. **"Might be slow" without evidence = INFO only, never blocker.** If you cannot articulate the execution frequency and expected data scale, do not escalate.
-4. **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.
+### 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.
+
+### Performance laws
+
+1. **Every `blocker` or `major` finding MUST cite the specific hot path or
+   frequency that makes it a real problem.** "Runs on every keystroke", "called
+   per list item (N = potentially thousands)", "executes on every render of a
+   high-frequency parent" — be specific. For this reviewer, the execution
+   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.
 
 ---
 
@@ -292,14 +315,21 @@ STATUS: DONE_WITH_CONCERNS
 [List categories with no findings, confirming they were checked]
 ```
 
-### Severity definitions
+### Where performance conditions land
 
-| Severity | Meaning |
-|----------|---------|
-| `blocker` | Demonstrable performance regression on a critical path; will noticeably degrade UX or server capacity under expected load |
-| `major` | High-likelihood bottleneck on a frequently executed path; strongly recommended before merge |
-| `minor` | Inefficiency worth fixing but not on a hot path; can ship, should be tracked |
-| `info` | Pattern worth noting; no clear hot path or measurable impact in current code |
+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 |
+|---|---|---|
+| A cost that takes the process or request down — OOM, timeout, capacity exhausted at a stated load | `blocker` | Crash |
+| Bottleneck on a path you can name, with the frequency or data scale that makes it a cost | `major` | Trigger and outcome are both named; slow is not one of the four shapes |
+| Inefficiency off any hot path you can name | `minor` | Correct today; the cost is to whoever tunes it next |
+| "Looks slow", no execution context | `info` | Shared law 1 — no reproducible path |
+
+A performance finding is `blocker` only when the degradation *is* an outage.
+"Noticeably degrades UX" is `major`: real, named, and not merge-blocking.
 
 ---
 
@@ -314,7 +344,7 @@ Stop and re-read these rules if you are thinking:
 | "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" | Iron Law 2: hot path is mandatory for blocker/major; omitting it means downgrading to info |
+| "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` |
 
 ---
 
@@ -338,7 +368,7 @@ If the file does not exist or is not provided, proceed normally — context is o
 
 ## 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.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/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

@@ -1,5 +1,6 @@
 ---
 name: review-pr-feedback
+model_tier: light
 description: |
   Use when: a developer has received PR review comments and wants to understand them,
   act on them, or extract patterns from them. Covers "analyze PR comments",
@@ -7,7 +8,6 @@ description: |
   or dispatched by review-orchestrator when a PR URL is provided.
   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.
-version: "1.0.0"
 triggers:
   - "analyze PR comments"
   - "review PR feedback"
@@ -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 — PR Feedback Analyzer
@@ -41,7 +41,7 @@ review-pr-feedback Progress:
 - [ ] Step 4: Group comments by author
 - [ ] Step 5: Classify comment types (blocker intent / suggestion / question / nitpick)
 - [ ] Step 6: Explain each comment + suggest concrete fix with code example
-- [ ] Step 7: Detect senior/boss reviewer comments — offer pattern extraction (with user consent)
+- [ ] Step 7: Comments from configured learning authors — offer a learning proposal (with user consent)
 - [ ] Step 8: Emit structured report with action items checklist
 ```
 
@@ -137,6 +137,12 @@ Organize all comments under each author, distinguishing line-specific from gener
 
 For each comment, classify intent before explaining:
 
+This maps the **intent of an incoming human comment**, which is not a code
+condition. It is not a second severity rubric: the levels themselves are defined
+once, in `review-orchestrator/SKILL.md` → **Severity (canonical)**, and a mapped
+value is a starting point that the canonical test overrides whenever the comment
+names a concrete trigger and outcome.
+
 | Intent class | Description | Default severity mapping |
 |---|---|---|
 | `blocker` | Reviewer explicitly blocks or says "must fix", "won't approve until..." | blocker |
@@ -177,20 +183,39 @@ If confidence is Low, state both interpretations and ask the user which one appl
 
 ---
 
-## Step 7: Senior / Boss Reviewer Handling
-
-**Detection**: if an author is identified as a senior or boss reviewer (by username, or by
-review authority markers such as "REQUEST_CHANGES from `boss`"), trigger this flow:
-
-1. Notify the user: "This PR has comments from a senior reviewer (`<login>`)."
-2. **NEVER update rules, CLAUDE.md, or any configuration without explicit user consent.**
-3. Ask: "Should I analyze `<login>`'s comments for patterns and suggest updates to review rules?"
-4. If the user agrees:
-   - Identify recurring patterns in that reviewer's feedback (not one-off edge cases)
-   - Propose specific additions to `.metaproject/rules/core/code-review-boss-profile.mdc` or the relevant rule file
-   - Present the proposed changes to the user for approval before writing anything
-   - After approval, update the rule file and note it in the output
-5. Extract generalizable patterns only — not personal phrasing or one-off opinions
+## Step 7: Feed the comments back into the project's learned skill
+
+**Detection is configuration, not judgement.** Which authors teach this project is
+declared in `.metaproject/review-learning.config.json`, alongside the local skill
+to teach and the repository to read. Do not decide that an author is senior,
+authoritative, or worth learning from — the file decides, and an author it does
+not name contributes nothing.
+
+If the file is absent, this project does not learn. Say nothing about it and skip
+this step; absence is a supported state, not a misconfiguration.
+
+If the file is present and names at least one author who commented on this PR:
+
+1. Notify the user: "This PR has comments from `<login>`, a configured learning
+   source for `<module>/<skill>`."
+2. **NEVER apply a proposal without explicit user consent.**
+3. Ask: "Should I turn those comments into a learning proposal for
+   `<module>/<skill>`?"
+4. If the user agrees, run the two commands. The first writes a proposal and
+   changes nothing; the second is the only writer:
+   ```bash
+   keryx review learn --pr <n>
+   keryx skills learn apply .metaproject/data/gdskills/proposals/<id>.json
+   ```
+5. Present the proposal's lessons before applying. `learn` reads the record
+   `keryx review comments collect` already wrote and never re-fetches, so the
+   proposal shows exactly what would be written.
+
+**The target is the project skill, never a rule file.** `.metaproject/rules/core/`
+holds shipped templates that `keryx update` overwrites with force, and
+`applyLearningProposal` refuses any target outside
+`.metaproject/project-skills/` — a lesson written anywhere else is lost on the
+next update, or refused outright.
 
 ---
 
@@ -312,7 +337,7 @@ If provided and the file exists, read it before fetching PR comments. If absent,
 
 | Rationalization | Why it is wrong |
 |----------------|-----------------|
-| "I'll update the rule file based on the boss's comments without asking" | NEVER auto-update rules; always ask first — rules affect all future reviews |
+| "I'll write these comments into a rule file without asking" | NEVER apply a learning proposal unsupervised, and never target a rule file — `keryx skills learn apply` refuses anything outside `.metaproject/project-skills/` |
 | "The reviewer's question is just curiosity, not a real concern" | Questions often hide concerns; classify carefully |
 | "I'll skip the 'praise' comments — they're not actionable" | Positive patterns help developers understand what to repeat |
 | "Confidence High for an ambiguous comment" | Low confidence is honest; false confidence leads to wrong fixes |
@@ -321,7 +346,7 @@ If provided and the file exists, read it before fetching PR comments. If absent,
 
 ## 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.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/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-regression/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: review-regression
+model_tier: deep
+description: |
+  Use when: reviewing the BLAST RADIUS of a change — the code a change can break,
+  as opposed to the change itself. Dispatched by review-orchestrator under scope B
+  of a deep round, over the set `keryx review blast-radius` computes.
+  NOT for: reviewing the diff (that is scope A and the ordinary reviewers), and
+  NOT for style, naming or architecture in code the change did not touch.
+triggers:
+  - "review regression"
+  - "does this change break anything"
+  - "blast radius review"
+  - "dispatched by review-orchestrator"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
+license: "MIT"
+---
+
+# Review: Regression
+
+You are reviewing **scope B** of a deep round. The files you are given are not
+under review. They are under **regression check**.
+
+## The one question
+
+> Does this change break an existing behaviour here?
+
+Not "is this code good". Not "would I have written it this way". The blast-radius
+set is code that already worked; your job is to find where the change stops it
+working.
+
+This is enforced, not requested. `keryx review ingest` runs
+`screenBlastRadiusFindings` over the findings this scope returns and refuses
+three shapes outright:
+
+- `outside-set` — anchored to a file that is in neither the computed set nor the
+  changed set. A file-less finding survives this only when its `class_scope.sites`
+  name something in the set.
+- `non-regression-severity` — below `major`. A break in existing behaviour names
+  a trigger and an outcome; `minor` and `info` state by definition that it does
+  not.
+- `no-link-to-change` — nothing in the finding names a changed file, module or
+  symbol. A regression claim asserts that THE CHANGE broke this site. **A
+  `blocker` is exempt from this rule; a `major` is not.** The rule is a substring
+  match over your prose — the only one of the three that can be wrong about a
+  true claim — and it may not be the thing that deletes a merge-blocking
+  regression. So: when you report a `major` about a **dependent**, name the
+  changed file, module or symbol whose behaviour moved. The anchor alone is not
+  enough, because every finding the first rule admits is anchored, most of them
+  at code the change never touched.
+
+The exemption is not a free pass, it is a recorded one. A `blocker` admitted
+without naming the change is listed in `scope.md` under **Admitted without being
+judged**, counted next to `accepted:`, and printed on the terminal — so the
+record never claims that rule 3 passed on a finding rule 3 never read.
+
+A refused finding does not reach `findings.json`. It is listed by id in the
+package's `scope.md` under `## Scope B rejections`, with the rule that refused it
+and why, and printed on the terminal by `keryx review ingest` — so a round spent
+on them is a round wasted, visibly, and an observation raised under the wrong
+scope survives to be filed where it belongs. What the completion gate never sees
+is a refused finding, deliberately: it is a claim this round has declined to
+make, and the gate blocking on it is the failure this screen exists to remove.
+
+Every rejection RULE judges the CLAIM. None of the three reads the reviewer's
+name: a reviewer whose usual question is "is this code good" can still notice a
+break, and it is accepted on its merits. What the name decides is **membership**
+— which findings the screen judges at all. `review-finding.schema.json` carries
+no `scope` property, so the reviewer name is the only surviving record of which
+question a finding was dispatched under, and `isBlastRadiusScopedFinding` reads
+it to tell scope B's findings from scope A's. Screening scope A by scope B's
+rules would reject every legitimate `minor` on a changed file. The distinction is
+the whole of it: the name selects the jury, never the verdict.
+
+If the round has no computed blast-radius record to screen against, the ingest is
+refused rather than recorded unscreened. The orchestrator supplies it with
+`keryx review ingest --blast-radius <file>` — the `--json` output it kept from
+Step 3b.
+
+## What you are given
+
+- the diff — what changed;
+- the blast-radius set, each entry with its dependency path back to the change,
+  computed from the code graph rather than chosen by a model;
+- the flow's frozen acceptance criteria;
+- the previous round's findings.
+
+The set is bounded by edge distance and a file cap, and **everything the cap
+dropped is recorded**. If the record says files were dropped, say so in your
+summary rather than implying the set was complete.
+
+## How to look
+
+Start from the dependency path, not from the file. The path tells you *how* the
+change reaches this code, and that is the shape of the break: a changed
+signature reaching a caller, a narrowed return type reaching a consumer, a
+removed branch reaching a case that relied on it, a changed default reaching
+something that never passed the argument.
+
+Read the caller before the callee. The break is almost always at the boundary,
+and the boundary is where the caller's assumption meets the change's new
+behaviour.
+
+## `class_scope` names the caller, not the changed line
+
+When you report, the site a human has to open is the code that **breaks**, not
+the code that changed. The changed line is already in the diff and already
+reviewed by scope A. Anchor the finding where the damage lands.
+
+## What is not a regression, however true
+
+- The code in the blast radius was already imperfect. Not yours.
+- The change makes an existing weakness easier to reach, but the weakness is
+  unreachable in this codebase. That is `info` under law 1.
+- A test in the set is thin. Say it under scope A if the change touched it;
+  otherwise it is not a regression.
+
+## What you cannot see, and must not pretend to
+
+The blast radius is a **code graph**. It does not carry runtime edges: a spawned
+process, a file handoff, a string-keyed registry lookup, a hook. It walks
+dependents only, so a narrowed contract that breaks something the change
+*depends on* is outside your set. And a change to a non-code file — a skill, a
+rule, a schema — has an empty radius, recorded as unresolved rather than clean.
+
+If the change is of that shape, say the radius could not answer the question.
+That is a useful result. Silence that reads as "nothing found" is not.
+
+## Class scope — required for `blocker` and `major`
+
+Every `blocker` and `major` finding must carry `class_scope`: **every** site that
+holds the shape you found, and **how you enumerated them** — the grep or query
+you ran, or the guard that derives the set.
+
+For a regression the sites are the **callers that break**, not the changed line.
+A finding anchored to one caller is a claim that exactly one caller breaks —
+and a change that breaks one consumer of an interface usually breaks its
+siblings. The blast-radius set is already the candidate list: enumerate over it.
+
+```yaml
+class_scope:
+  sites: ["src/session/store.ts:133", "src/flow/service.ts:412"]
+  enumeration_method: "every entry in the blast radius importing the changed symbol; 6 callers, 2 pass the removed argument"
+```
+
+"I checked the others" is not an enumeration method. A single-entry `sites` list
+is a claim that the class has exactly one member — make it deliberately, because
+`review-finding.schema.json` accepts it and the next round tests it.
+
+`minor` and `info` may omit it — though under scope B a finding below `major` is
+rejected anyway, so in practice every finding you report carries one.
+
+```markdown
+### [F-NNN] Title
+
+- **Severity**: blocker | major | minor | info
+- **File**: path/to/file.ts:line
+- **Problem**: what is wrong
+- **Why it matters**: impact (data corruption / crash / silent wrong result / spec gap)
+- **Fix**: concrete suggestion
+```
+
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no table of its own.
+
+### 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.

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

@@ -1,5 +1,6 @@
 ---
 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"
@@ -12,8 +13,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: Security Code (Code-Level Vulnerabilities)
@@ -211,10 +212,29 @@ Attack vector template: _"Attacker sends `filename=../../etc/passwd`, reading ar
 
 ## Iron Laws
 
-1. **Every security finding MUST state the attack vector explicitly.** Name the attacker action, the entry point, and the impact. No attack vector → no finding above INFO.
-2. **A finding without a reproducible code path is INFO, not blocker.** "Could theoretically..." = INFO. "Attacker sends X to endpoint Y, which executes Z" = blocker/major.
-3. **Never flag theoretical vulnerabilities.** The vulnerable code path must exist in the changed diff. Do not report hypothetical misuse of safe APIs.
-4. **Do not flag the same pattern twice.** If the same class of issue (e.g., missing `@UseGuards`) appears in five files, group them under one finding with all locations listed.
+### 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.
+
+### Security-specific law
+
+1. **Every security finding MUST state the attack vector explicitly.** Name the
+   attacker action, the entry point, and the impact. No attack vector → no finding
+   above `info`. This one does not generalise — a style reviewer has no attacker
+   — so it stays here and only here.
 
 ---
 
@@ -295,14 +315,24 @@ STATUS: DONE_WITH_CONCERNS
 [List categories with no findings, confirming they were checked]
 ```
 
-### Severity definitions
+### Where security conditions land
+
+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 |
+|---|---|---|
+| Exploitable vulnerability in the current code path, with the attack vector stated | `blocker` | Named shape 3 |
+| A real weakness whose exploitation needs a precondition the diff does not establish — an internal-only endpoint, an authenticated caller, a value not yet attacker-controlled | `major` | Trigger and outcome are named, but the path to exploitation is not complete |
+| Hardening or defence-in-depth on code that is not currently exploitable | `minor` | The code behaves correctly; the cost is to whoever hardens it later |
+| A pattern with no attack vector in the current code | `info` | Security-specific law, and shared law 1 |
 
-| Severity | Meaning |
-|----------|---------|
-| `blocker` | Exploitable vulnerability in the current code path; must fix before merge |
-| `major` | High-likelihood risk with a plausible attack scenario; strongly recommended before merge |
-| `minor` | Hardening improvement or defense-in-depth; can ship but should be tracked |
-| `info` | Pattern worth noting; no clear attack vector in current code |
+**"Plausible attack scenario" is not a severity.** A scenario you can state and
+reach is `blocker`; a scenario you can state but cannot reach is `major`; a
+scenario you cannot state is `info`. Being the security reviewer does not raise
+any of them — see the canonical rubric on severity being a property of the
+outcome, not of the domain.
 
 ---
 
@@ -317,7 +347,8 @@ Stop and re-read these rules if you are thinking:
 | "MD5 is used for caching keys, not passwords — it's fine" | State it as INFO, but do not silently skip it; it often drifts |
 | "I'll downgrade to minor to avoid friction" | Severity reflects real risk, not social dynamics |
 | "The code uses an ORM so SQL injection is not possible" | ORMs have raw-query escape hatches; verify parameterization |
-| "No attack vector found — I'll call it major anyway" | No attack vector = INFO only, per Iron Law 1 |
+| "No attack vector found — I'll call it major anyway" | No attack vector = `info` only, per the security-specific law |
+| "It's a security finding, so it's a blocker" | `blocker` is the four shapes in **Severity (canonical)**. An unreachable weakness is `major` however alarming its name |
 | "It's outside the diff but the pattern is clearly wrong" | Only flag changed code; flag legacy via INFO with note to track separately |
 
 ---
@@ -342,7 +373,7 @@ If the file does not exist or is not provided, proceed normally — context is o
 
 ## 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.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/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.
 
 ---