@mrciphersmith/keryx 0.2.97 → 0.2.99

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"
@@ -207,7 +211,7 @@ 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/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 `.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.
 
 ---
 
@@ -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"
@@ -224,7 +224,7 @@ STATUS: DONE | NEEDS_CONTEXT | BLOCKED
 There is no `DONE_WITH_CONCERNS`: a verifier has no concerns of its own.
 
 Return one object conforming to
-`skills/review/review-orchestrator/verification-claim.schema.json`:
+`.metaproject/skills/gdskills/review/review-orchestrator/verification-claim.schema.json`:
 
 ````text
 ```json keryx:verifications

package/src/gdskills/bundled/rules/core/review-agent-profile.mdc

@@ -1,49 +0,0 @@
----
-description: "Baseline AI code review standards for correctness, architecture, safety, and maintainability."
-alwaysApply: false
----
-
-# AI Code Review Assistant
-
-## Purpose
-Provide strict, high-signal code reviews with actionable findings.
-
-## When To Apply
-Apply when performing AI-assisted code review; loaded automatically by the code-ai-review skill.
-
-## Verdict Labels
-
-All reviews must end with exactly one of the following verdict labels:
-
-| Verdict | Meaning |
-|---------|---------|
-| `APPROVE` | Changes accepted as-is; no outstanding issues. |
-| `APPROVE WITH SUGGESTIONS` | Accepted and can merge, but improvements are noted for follow-up. |
-| `REQUEST CHANGES` | Must fix identified issues before merge. |
-| `COMMENT` | Informational findings only; no blocking action required. |
-
-## Review Output Structure
-1. Verdict label (from the table above)
-2. Findings by severity and category
-3. Concrete fix proposals
-4. Residual risks and test gaps
-
-## Priority Categories
-- Correctness
-- Types and safety
-- Architecture and state boundaries
-- Performance
-- UX/A11y
-- Tests
-
-## Mandatory Rules
-- Prioritize correctness over style.
-- Do not request massive refactors unless user asks.
-- Flag unsafe casts and hidden complexity.
-- Align suggestions with existing project patterns.
-- Keep comments specific, respectful, and actionable.
-
-## Output Contract
-- Final review must be Markdown.
-- Code snippets/diffs must be fenced code blocks.
-- Response language follows user query language.

package/src/gdskills/bundled/rules/core/review-strict-profile.mdc

@@ -1,48 +0,0 @@
----
-description: "Strict review profile: direct, architecture-first feedback with concrete fixes."
-alwaysApply: false
----
-
-# Strict Review Profile
-
-## Purpose
-Apply a strict, architecture-first pass: name the defect, name where the logic
-belongs, and give the replacement.
-
-## When To Apply
-Apply when the caller explicitly asks for a strict review. For a checklist this
-project learned from its own pull-request comments, use
-`core/code-review-learned-profile.mdc` instead — that one carries no conventions
-of its own and reads them from the project.
-
-## Style Profile
-- Direct and concise.
-- Architecture-first.
-- Strongly against duct-tape fixes.
-- Focus on testability and single source of truth.
-
-## What To Flag
-- Business logic in UI instead of store/service.
-- Duplicate rule checks in multiple places.
-- Unsafe casts (`any`, disguised casts).
-- Mocks inheriting production classes.
-- Loading/no-data semantics confusion.
-- Magic numbers without rationale.
-- **Status/result mapping semantics**: Mapping "none" or absence-of-result to a semantic outcome (e.g. canceled, failed) without domain justification. Verify that source enum values (e.g. none, killed, cancelled) have distinct meanings and that the mapping preserves them; flag mappings that equate semantically different states (e.g. `none === canceled`, `killed === canceled` without explicit product rationale).
-- **Store method accessibility** — See `core/mobx-store-template.mdc` for definitive rules on public vs private store methods. Key violations to flag:
-  - Public `onChangeX` / `handleX` methods (must be private)
-  - Public `action.bound` that should be private callbacks
-
-## Response Format
-1. Verdict in one line — use the canonical verdict vocabulary (same set as `core/code-review-ai-assistant.mdc`):
-   - `APPROVE` — no blocking issues; changes accepted as-is
-   - `APPROVE WITH SUGGESTIONS` — accepted but improvements noted for follow-up
-   - `REQUEST CHANGES` — has issues that must be fixed before merge
-   - `COMMENT` — informational findings only; no blocking action required
-2. Top 1-3 blocking findings.
-3. Concrete replacement/fix path.
-
-## Guardrails
-- No personal attacks.
-- No empty nitpicks.
-- Keep recommendations lint-safe and scoped.

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.codex.md

@@ -1,353 +0,0 @@
----
-name: code-verifier
-model_tier: light
-description: "Use when running a full quality gate after implementation — lint, type-check, tests, and import validation. Mandatory step in job-orchestrator after task-implementer and after fix iterations. Use standalone when you need a structured verification report."
-triggers:
-  - "Run verification"
-  - "Quality gate"
-  - "Check code quality"
-  - "Run lint and tests"
-  - "Verify implementation"
-  - "Run checks"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "verification"
-  agent_worthy: true
-  compatible_harnesses: "cursor,codex,zed,opencode"
-license: "MIT"
----
-
-# Code Verifier
-
-## Purpose
-
-Runs the full quality gate for a project: lint, type-check, tests, and import validation. Provides a structured, parseable result that the orchestrator uses to decide whether to proceed or trigger a fix loop.
-
-**Distinct from `task-implementer` Phase 5:** task-implementer does inline self-verification during implementation. `code-verifier` is an independent gate that runs after all tasks in a wave are complete — giving a clean, consolidated view of the whole diff, not per-task.
-
-**Input:** Codebase path + worktree path + scope (changed files or full project)
-**Output:** `VERIFICATION_RESULT` structured report — gate status (pass/fail), per-check results, actionable findings
-
-## When to Use
-
-- Dispatched by `job-orchestrator` after each task-implementer wave (mandatory)
-- Dispatched by `job-orchestrator` after each fix iteration
-- Run standalone: "verify my code", "run quality gate", "/code-verifier"
-- Any time you need a reproducible, structured view of project health
-
-## Architecture: 4 Phases
-
-```
-Phase 1: DETECT   →  Auto-detect stack, tooling, commands
-Phase 2: RUN      →  Execute lint → type-check → tests → import-check
-Phase 3: ANALYZE  →  Parse outputs, classify findings by severity
-Phase 4: REPORT   →  Emit VERIFICATION_RESULT
-```
-
----
-
-## Workflow
-
-```
-Code Verifier Progress:
-- [ ] Phase 1: Detect stack and tooling
-- [ ] Phase 2: Run verification checks
-- [ ] Phase 3: Analyze and classify findings
-- [ ] Phase 4: Report results
-```
-
----
-
-### Phase 1: DETECT
-
-Auto-detect the project stack and available verification tools.
-
-**1.1 Package manager and runner:**
-
-```bash
-cd <codebase_path>
-
-if   [ -f bun.lock ] || [ -f bun.lockb ]; then PM=bun;    RUNNER="bun run"
-elif [ -f pnpm-lock.yaml ];    then PM=pnpm;   RUNNER="pnpm run"
-elif [ -f yarn.lock ];         then PM=yarn;   RUNNER="yarn"
-elif [ -f package-lock.json ]; then PM=npm;    RUNNER="npm run"
-elif [ -f pyproject.toml ] || [ -f requirements.txt ]; then PM=python; RUNNER=""
-elif [ -f go.mod ];            then PM=go;     RUNNER=""
-else PM=unknown; RUNNER=""
-fi
-```
-
-**1.2 Detect available check commands:**
-
-| Check | How to detect | Command |
-|---|---|---|
-| Lint | `package.json` has `"lint"` script | `$RUNNER lint` |
-| Lint (auto) | `eslint.config.*` or `.eslintrc*` present | `npx eslint . --max-warnings 0` |
-| Biome | `biome.json` present | `npx biome check .` |
-| Type-check | `package.json` has `"type-check"` or `"typecheck"` script | `$RUNNER type-check` |
-| Type-check (auto) | `tsconfig.json` present | `npx tsc --noEmit` |
-| Tests | `package.json` has `"test"` script | `$RUNNER test --run` (vitest) or `$RUNNER test` |
-| pytest | `pytest` in `pyproject.toml` or `requirements.txt` | `pytest --tb=short -q` |
-| Go tests | `go.mod` present | `go test ./...` |
-| Circular imports | `madge` in devDependencies | `npx madge --circular src/` |
-
-**1.3 Determine scope:**
-
-```
-IF scope = "changed" (default when dispatched by orchestrator):
-  FILES = git diff --name-only <base_branch>...HEAD
-  Run tests only for files related to changed code
-  Run lint only on changed files: npx eslint <changed_files>
-  Run type-check on full project (tsc doesn't support file-level scope)
-
-IF scope = "full":
-  Run all checks on full project
-```
-
-**Output of Phase 1:**
-```
-TOOLING:
-  pm: bun | pnpm | yarn | npm | python | go | unknown
-  runner: "bun run" | ...
-  checks_available: [lint, type-check, tests, circular-imports]
-  checks_skipped: [<reason>]
-  scope: changed | full
-  changed_files: [<paths>]
-```
-
----
-
-### Phase 2: RUN
-
-Execute each available check in order. Capture full output.
-
-**Execution order:** lint → type-check → tests → import-check
-
-**Do NOT abort early** — run all checks even if one fails. The orchestrator needs the complete picture.
-
-**2.1 Lint:**
-```bash
-# Changed files only (faster, more actionable)
-npx eslint <changed_files> --format=json --max-warnings 0
-# OR if lint script exists:
-$RUNNER lint
-```
-
-Capture:
-- Exit code (0 = pass, non-zero = fail)
-- Number of errors and warnings
-- Per-file error list (file path, line, column, rule, message)
-
-**2.2 Type-check:**
-```bash
-npx tsc --noEmit 2>&1
-# OR:
-$RUNNER type-check
-```
-
-Capture:
-- Exit code
-- Number of errors
-- Per-error: file, line, column, message, TS error code
-
-**2.3 Tests:**
-```bash
-$RUNNER test --run 2>&1        # vitest
-# OR: npx jest --ci 2>&1
-# OR: pytest --tb=short -q 2>&1
-# OR: go test ./... 2>&1
-```
-
-Capture:
-- Exit code
-- Tests passed / failed / skipped counts
-- Per-failure: test name, file, error message, stack (first 5 lines)
-
-**2.4 Circular import check (if madge available):**
-```bash
-npx madge --circular --extensions ts,tsx src/ 2>&1
-```
-
-Capture:
-- Exit code
-- List of circular chains (if any)
-
----
-
-### Phase 3: ANALYZE
-
-Parse raw outputs into structured findings. Classify by severity.
-
-**3.1 Severity classification:**
-
-| Finding | Severity |
-|---|---|
-| Type error | CRITICAL |
-| Test failure | CRITICAL |
-| ESLint error (not warning) | HIGH |
-| Circular import | HIGH |
-| ESLint warning | LOW |
-| Skipped test | INFO |
-
-**3.2 Gate decision:**
-
-```
-GATE = PASS
-IF any CRITICAL findings  → GATE = FAIL (blocks proceed)
-IF any HIGH findings      → GATE = FAIL (blocks proceed)
-IF only LOW/INFO findings → GATE = PASS_WITH_WARNINGS
-```
-
-**3.3 Actionable finding format:**
-
-Each finding must include enough context for `task-implementer` (fix mode) to resolve it without re-reading the full output:
-
-```
-{
-  severity: CRITICAL | HIGH | LOW | INFO,
-  check: lint | type-check | test | circular-import,
-  file: <path>,
-  line: <N> | null,
-  column: <N> | null,
-  rule: <ESLint rule or TS error code> | null,
-  message: <error text>,
-  suggestion: <optional fix hint>
-}
-```
-
----
-
-### Phase 4: REPORT
-
-Emit the structured `VERIFICATION_RESULT` as the final message.
-
-```
-VERIFICATION_RESULT:
-  gate: PASS | PASS_WITH_WARNINGS | FAIL
-  scope: changed | full
-  
-  checks:
-    lint:
-      status: pass | fail | skipped
-      errors: <N>
-      warnings: <N>
-      command_used: "<command>"
-    
-    type_check:
-      status: pass | fail | skipped
-      errors: <N>
-      command_used: "<command>"
-    
-    tests:
-      status: pass | fail | skipped
-      passed: <N>
-      failed: <N>
-      skipped: <N>
-      command_used: "<command>"
-    
-    circular_imports:
-      status: pass | fail | skipped
-      cycles: <N>
-  
-  findings:
-    - severity: CRITICAL
-      check: type-check
-      file: src/services/UserService.ts
-      line: 42
-      rule: TS2345
-      message: "Argument of type 'string' is not assignable to parameter of type 'number'"
-    - severity: HIGH
-      check: lint
-      file: src/components/Form.tsx
-      line: 18
-      rule: "no-unused-vars"
-      message: "'value' is defined but never used"
-  
-  summary: "<1-2 sentence human-readable summary>"
-```
-
-**STATUS reporting:**
-
-```
-STATUS: DONE          — gate PASS or PASS_WITH_WARNINGS, report follows
-STATUS: DONE_WITH_CONCERNS — PASS_WITH_WARNINGS with notable warnings
-STATUS: BLOCKED       — could not run checks (missing tooling, wrong directory)
-```
-
-> If `gate: FAIL` → STATUS is still `DONE` (the gate result, not the skill's execution). The orchestrator reads `gate: FAIL` and decides to trigger fix.
-
----
-
-## Integration with job-orchestrator
-
-The orchestrator dispatches `code-verifier` at two points:
-
-**After task-implementer wave (pre-review gate):**
-```
-code-verifier:
-  codebase_path: <worktree_path>
-  scope: changed
-  base_branch: <base_branch from JOB_STATE>
-→ If gate: FAIL → dispatch fix tasks → re-run code-verifier
-→ If gate: PASS → proceed to review
-```
-
-**After fix iterations (post-fix gate):**
-```
-code-verifier:
-  codebase_path: <worktree_path>
-  scope: changed
-→ If gate still FAIL after 2 iterations → report as BLOCKED, skip to report
-→ If gate: PASS → proceed to report
-```
-
-**The orchestrator's internal "checks" step (2.8) is replaced by `code-verifier` dispatch.**
-
----
-
-## Standalone Usage
-
-```bash
-# Run on current directory, changed files only
-/code-verifier
-
-# Run on specific project
-/code-verifier --path /path/to/project
-
-# Full project scan (not just changed files)
-/code-verifier --scope full
-```
-
----
-
-## Automation Settings
-
-| Setting | Default | Options | Description |
-|---------|---------|---------|-------------|
-| `scope` | `changed` | `changed` / `full` | Limit checks to changed files or run full project |
-| `fail_on_warnings` | `false` | true/false | Treat ESLint warnings as gate failures |
-| `include_circular` | `true` | true/false | Run circular import detection if madge available |
-| `max_findings_reported` | `20` | 1-100 | Cap findings in report to avoid overflow |
-
----
-
-## Error Handling
-
-| Error | Action |
-|---|---|
-| Check command not found | Mark check as `skipped`, continue others |
-| Wrong working directory | ABORT with `STATUS: BLOCKED` and directory hint |
-| Command times out (>120s) | Mark check as `skipped (timeout)`, continue |
-| Zero checks available | `STATUS: BLOCKED` — cannot verify without any tooling |
-| Circular import tool missing | Skip silently (not installed in all projects) |
-
----
-
-## Rules of Engagement
-
-1. **Run ALL checks** — never abort after first failure. The orchestrator needs the full picture.
-2. **Do NOT modify files** — this is read-only verification.
-3. **Scope to changed files** by default — full scans are slow and produce noise.
-4. **Be specific** in findings — include file, line, rule, message. Vague "lint failed" is not actionable.
-5. Return `VERIFICATION_RESULT` as the **final message** to the orchestrator.