@noir-ai/skills 1.16.0 → 1.17.0

package/evals/{noir-code-hygiene → noir-codebase-audit}/evals.json

@@ -1,5 +1,5 @@
 {
-  "skill_name": "noir-code-hygiene",
+  "skill_name": "noir-codebase-audit",
   "evals": [
     {
       "id": "no-machine-preamble",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noir-ai/skills",
-  "version": "1.16.0",
+  "version": "1.17.0",
   "description": "Noir skills — the builtin noir-* skill pack, the integrations pack (ClickUp first), and a copy-and-validate compiler.",
   "license": "MIT",
   "author": "agaaaptr",
@@ -48,7 +48,7 @@
   "dependencies": {
     "yaml": "^2.5.0",
     "zod": "^4.2.0",
-    "@noir-ai/core": "1.16.0"
+    "@noir-ai/core": "1.17.0"
   },
   "devDependencies": {
     "@types/node": "^22.17.0"

package/builtin/noir-frontend/SKILL.md

@@ -1,40 +0,0 @@
----
-name: noir-frontend
-description: Use when building or modifying frontend code — distinctive visual design, typography, component patterns, and responsive layouts. Do NOT use for pure backend logic.
-metadata:
-  category: domain
-  version: 1.0.0
-license: MIT
-compatibility: claude · agents-md · gemini · cursor · opencode
-references:
-  - ui-patterns.md
----
-
-# noir-frontend
-
-Frontend design and implementation guide — visual design, component architecture, responsive patterns, and interaction behavior. Use when the user is building or reshaping UI.
-
-## When to use
-
-- Building or modifying a UI component, page, or layout.
-- The user says "design this", "style this", "make it look good."
-- A component needs consistent visual language (colors, spacing, typography, dark/light theme).
-
-## Procedure
-
-1. **Establish the design system.** Colors, spacing, typography, breakpoints — before any component. If the project has a design system (Tailwind config, theme tokens, CSS variables), use it; if not, suggest one.
-2. **Component-first thinking.** Break the UI into independent, composable components. One component = one file = one responsibility.
-3. **Responsive by default.** Start with mobile layout, add breakpoints for wider viewports. `max-width: 100%` on images; horizontal-scroll containers for wide tables.
-4. **Accessibility.** Semantic HTML, keyboard navigation, color contrast, screen-reader labels. An inaccessible UI is an unfinished UI.
-5. **On Claude Code**, use `AskUserQuestion` for design choices (color palette, layout preference). On other hosts, ask plainly.
-
-## Reference
-
-For design tokens, component structure, responsive, and accessibility patterns, see [ui-patterns.md](references/ui-patterns.md).
-
-## When done → next skill
-
-→ `noir-verifying` to confirm the UI meets the spec. Or `noir-test-driven-development` to add tests.
-
-## Notes
-- This skill is a playbook — the host decides which tools to use. On Claude Code, prefer `AskUserQuestion` for choices; on other hosts, ask in text.

package/builtin/noir-frontend/references/ui-patterns.md

@@ -1,48 +0,0 @@
-# UI patterns — design system, components, accessibility
-
-Deep reference for `noir-frontend`. Practical patterns for building and reshaping UI that reads as one coherent system.
-
-## Establish the design tokens first
-
-A UI is coherent when it draws from ONE set of tokens. Before styling a component, confirm or propose:
-
-- **Color** — a small palette: background, surface, text-primary, text-muted, accent, error. Light + dark variants. Never 20 ad-hoc hex values.
-- **Spacing** — a scale (e.g. 4/8/12/16/24/32). Use the scale, not arbitrary pixels.
-- **Typography** — font stack, size scale (e.g. xs/sm/base/lg/xl/2xl), line-height, weight for headings vs body.
-- **Radius/shadow** — a consistent corner radius and elevation system.
-- **Breakpoints** — the widths where layout changes (e.g. 640/768/1024/1280).
-
-Where the project already has tokens (Tailwind config, CSS variables, a theme file), USE THEM — do not invent a parallel system.
-
-## Component-first structure
-
-- One component = one file = one responsibility. A `Button`, a `Card`, a `TableRow` — each standalone.
-- Components are composable: small pieces assemble into screens.
-- Props/inputs are explicit; a component never reaches into global state it wasn't given.
-
-## Responsive by default
-
-- **Mobile-first** — build the narrow layout first, add breakpoints for wider views.
-- `max-width: 100%` on images and media — never overflow.
-- Wide tables and code blocks scroll inside their OWN container (`overflow-x: auto`) — the page body never scrolls horizontally.
-- Touch targets ≥ 44px on interactive elements.
-
-## Accessibility (non-negotiable)
-
-- **Semantic HTML** — use `<button>`, `<a>`, `<nav>`, `<label>`, not `<div onClick>`.
-- **Keyboard** — every interactive element reachable + operable by keyboard (focus, Enter/Space).
-- **Focus** — a visible focus indicator; never `outline: none` without a replacement.
-- **Contrast** — text meets WCAG AA contrast against its background (both themes).
-- **Labels** — every input has a `<label>` or `aria-label`; images have alt text.
-- **Reduced motion** — respect `prefers-reduced-motion`.
-
-## Interaction behavior
-
-- **State** — every interactive element has hover / focus / active / disabled / loading states.
-- **Feedback** — actions give feedback (a spinner, a toast, a state change). Silent failure confuses users.
-- **Optimistic updates** with rollback on error feel faster than blocking on every request.
-
-## Good / bad
-
-Good: a component uses the spacing scale, tokens, semantic markup, and has all states.
-Bad: a hard-coded `padding: 17px`, an inline `#f3f2ef` that exists nowhere in tokens, a `<div onClick>` for a button, no focus style, an image with no alt.