@dreki-gg/pi-code-reviewer 0.1.0 → 0.1.1

package/README.md

@@ -50,8 +50,8 @@ Evaluates changes for correctness and adherence to project standards.
 - Does the change follow naming conventions?
 
 ## Tools
-- `bun run typecheck`
-- `bun run lint`
+- `npm run typecheck`
+- `npm run lint`
 
 ## Severity
 - blocker: Type errors, unresolved imports
@@ -67,8 +67,8 @@ The package ships with four example lenses:
 | --- | --- |
 | `code-quality` | Correctness, lint, types, dead code |
 | `maintainability` | Coupling, complexity, readability |
-| `product-vision` | Alignment with product direction |
-| `ux-design` | Accessibility, responsiveness, interaction quality |
+| `product-vision` | Traces changes back to their originating issue or design doc, checks goal alignment |
+| `accessibility` | Semantic HTML, keyboard navigation, ARIA, screen reader compatibility |
 
 Run `/review-init` to scaffold these (customized for your project's tools) into `.code-review/lenses/`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dreki-gg/pi-code-reviewer",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Multi-lens code review extension for pi — configurable review criteria per project",
   "keywords": [
     "pi-package"

package/skills/code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-review
-description: Multi-lens code review against working directory changes. Evaluates diffs through configurable criteria like code-quality, maintainability, product-vision, and ux-design. Use when user says "review my changes", "review this code", "check before committing", or "code review".
+description: Multi-lens code review against working directory changes. Evaluates diffs through configurable criteria like code-quality, maintainability, product-vision, and accessibility. Use when user says "review my changes", "review this code", "check before committing", or "code review".
 ---
 
 # Code Review
@@ -36,8 +36,8 @@ Description of what this lens evaluates.
 - Evaluation point 2
 
 ## Tools
-- `bun run typecheck`
-- `bun run codeql:fallow -- --changed-since HEAD`
+- `npm run typecheck`
+- `npm run lint`
 
 ## Severity
 - blocker: What constitutes a blocking issue

package/skills/code-review/lenses/accessibility.md

@@ -0,0 +1,20 @@
+# Accessibility
+
+Evaluates UI changes for accessibility compliance — semantic markup, keyboard support, screen reader compatibility, and inclusive design patterns.
+
+## Criteria
+- Are interactive elements accessible via keyboard (tab order, Enter/Space activation, Escape to dismiss)?
+- Do custom components use appropriate ARIA roles, states, and properties?
+- Are images and icons accompanied by meaningful alt text or aria-label?
+- Are form inputs associated with visible labels (not just placeholder text)?
+- Does the change use semantic HTML elements (button, nav, main, dialog) instead of generic divs with click handlers?
+- Is focus managed correctly after dynamic content changes (modals, route transitions, toast notifications)?
+- Are error and validation messages announced to screen readers (aria-live, role="alert")?
+- Does the color usage rely solely on color to convey meaning, or is there a secondary indicator (icon, text)?
+
+## Tools
+
+## Severity
+- blocker: Interactive elements unreachable by keyboard, missing labels on form inputs, click handlers on non-interactive elements without ARIA roles
+- warning: Missing alt text, placeholder-only labels, missing aria-live on dynamic content, focus not managed after modals
+- note: Semantic HTML improvements, ARIA attribute refinements, color contrast suggestions

package/skills/code-review/lenses/product-vision.md

@@ -1,19 +1,19 @@
 # Product Vision
 
-Evaluates whether changes align with the product direction and serve real user needs.
+Evaluates whether changes fulfill the intent behind the work — traces the diff back to its originating issue, PR description, or design doc and checks alignment.
 
 ## Criteria
-- Does this change serve existing users or is it speculative?
-- Does it introduce UI concepts or flows that don't exist elsewhere in the app?
-- Does it add unnecessary complexity to user-facing functionality?
-- Does it respect the established information architecture?
-- Is the feature discoverable and intuitive?
-- Does it follow the project's domain language (check CONTEXT.md if it exists)?
-- Are there simpler alternatives that would achieve the same user goal?
+- Is there a linked issue, PR description, or design document that explains why this change was requested?
+- Does the diff actually accomplish the stated goal, or does it drift into unrelated concerns?
+- Are there parts of the requirement left unaddressed by the change?
+- Does the change introduce scope creep beyond what was requested?
+- Does it follow the project's domain language (check CONTEXT.md, glossary, or naming conventions)?
+- Are user-facing strings consistent with the existing product vocabulary?
+- If the change modifies a public API or user flow, is that justified by the original request?
 
 ## Tools
 
 ## Severity
-- blocker: Changes that contradict the product direction or break existing user workflows
-- warning: Speculative features, unnecessary complexity, inconsistent UX patterns
-- note: Opportunities to better align with product vision
+- blocker: Change does not accomplish the stated goal, or contradicts the originating requirement
+- warning: Scope creep beyond the request, unaddressed requirements, inconsistent domain language
+- note: Opportunities to better align naming or structure with the stated intent

package/skills/code-review/lenses/ux-design.md

@@ -1,20 +0,0 @@
-# UX Design
-
-Evaluates the user experience quality of UI changes — accessibility, responsiveness, and interaction design.
-
-## Criteria
-- Are interactive elements accessible (keyboard navigation, ARIA labels, focus management)?
-- Are loading and error states handled visually?
-- Is the layout responsive or does it break at common viewport sizes?
-- Are animations purposeful and not distracting (100-200ms, no bouncy effects)?
-- Is text readable (minimum 12px body, sufficient contrast)?
-- Are form inputs properly labeled with clear validation feedback?
-- Does the change follow the project's existing component patterns?
-- Are click targets large enough for touch (minimum 44px)?
-
-## Tools
-
-## Severity
-- blocker: Missing keyboard accessibility on interactive elements, broken layout, no error states on data-fetching UI
-- warning: Missing ARIA labels, tiny text (<12px), missing loading states, non-responsive layout
-- note: Animation polish, spacing consistency, component reuse opportunities