@fringetools/cli 0.0.0-stage → 0.1.1

package/dist/index.d.ts

@@ -0,0 +1,8 @@
+interface CliOpts {
+    log?: (s: string) => void;
+    cwd?: string;
+    err?: (s: string) => void;
+}
+declare function runCli(argv: string[], opts?: CliOpts): Promise<number>;
+
+export { type CliOpts, runCli };

package/dist/index.js

@@ -0,0 +1,6 @@
+import {
+  runCli
+} from "./chunk-W23H5MXS.js";
+export {
+  runCli
+};

package/package.json

@@ -1,6 +1,53 @@
 {
   "name": "@fringetools/cli",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.1",
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "fringe": "dist/bin.js"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "files": [
+    "dist",
+    "skill"
+  ],
+  "scripts": {
+    "build": "tsup src/index.ts src/bin.ts --format esm --dts --outDir dist --clean",
+    "test": "vitest run",
+    "prepublishOnly": "pnpm build && pnpm test"
+  },
+  "devDependencies": {
+    "@types/node": "^22.0.0",
+    "tsup": "^8.0.0",
+    "typescript": "^5.5.0",
+    "vitest": "^2.0.0"
+  },
+  "dependencies": {
+    "@babel/parser": "^7.29.9",
+    "parse5": "^7.3.0",
+    "postcss": "^8.5.31"
+  },
+  "description": "UX-quality checker for AI coding agents: accessibility, states, dark patterns, token drift, AI-look.",
+  "keywords": [
+    "accessibility",
+    "a11y",
+    "lint",
+    "ux",
+    "ai-agents",
+    "claude-code"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/skc-learn/fringe.git",
+    "directory": "packages/cli"
+  },
+  "homepage": "https://github.com/skc-learn/fringe#readme",
+  "bugs": {
+    "url": "https://github.com/skc-learn/fringe/issues"
+  }
+}

package/skill/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: fringe
+description: Use when writing or changing frontend code (JSX/TSX, HTML, CSS, Vue, Svelte). Runs the Fringe checker so accessibility, state handling, dark patterns, token drift and the generic "AI look" are measured, not guessed.
+---
+
+# Fringe
+
+Command: use `fringe` if it is on the PATH, otherwise `npx -y @fringetools/cli` in its place (e.g. `npx -y @fringetools/cli check --json .`).
+
+Ponytail trims your code. Fringe handles your edges. Work the ladder in order.
+
+1. **Flow (judged).** Before building, ask what the user can skip. Cut steps, screens or options nobody needs. Write each decision with its evidence to `.fringe/manifest.json`: `{"flows":[{"action":"cut"|"kept","what":"...","evidence":"..."}]}`. No evidence, no cut.
+2. **Edges (verified, gates).** After every edit the hook runs `fringe check --claude-hook` and feeds errors back to you. Fix every listed finding. If there is no hook, run `fringe check --hook` yourself from the project root and do not finish while `block` is `true`.
+3. **Polish (verified, never gates).** Run `fringe check` once before finishing. Fix `review` items you agree with. Fix `signal` items that are cheap. Say which you left and why.
+
+When done: `fringe check --record --manifest .fringe/manifest.json`. Report the health score as measured; never estimate it yourself.
+
+Rules of the road:
+- Never grade your own work where the checker can measure it.
+- Do not silence a rule with `ignore`/`disable` in `fringe.config.json` to get green. Fix the code, or tell the user why the rule is wrong.
+- A `// fringe-ignore FR-123` comment is allowed only for a real false positive. Say so in your final message with the rule and why; the run output counts suppressions (`N suppressed`) and a reviewer will see them.
+- If `fringe` is not installed, say so. Do not skip the check silently.
+- Hook wiring and the full rule table: `packages/cli/README.md`.

package/skill/audit.md

@@ -0,0 +1,19 @@
+---
+name: fringe-audit
+description: Use when the user wants a whole-repo UX/accessibility audit, a plan for an existing frontend with many problems, or to adopt Fringe on a messy repo ("audit this codebase", "where do we start", "adopt fringe"). Produces a prioritized plan and sets a baseline.
+---
+
+# Fringe audit
+
+Command: use `fringe` if it is on the PATH, otherwise `npx -y @fringetools/cli` in its place (e.g. `npx -y @fringetools/cli check --json .`).
+
+1. Run `fringe check --json .` and note the totals. Do not print every finding.
+2. Summarize as a plan:
+   - Totals by severity and the health score, plus files scanned and skipped.
+   - **Top rules** by count, and **top files** by error count (the 5 worst of each).
+   - For each top rule: what it means in one sentence, a typical fix, and whether it is likely mechanical (add `aria-label`, add `alt`) or needs design judgment.
+   - A suggested order: mechanical `error` fixes first, then `error`s needing judgment, then `review`, then `signal`.
+3. Offer the baseline: "`fringe check --update-baseline` records today's findings so only new problems gate; commit `fringe.baseline.json`." Run it only if the user agrees.
+4. Ask before changing code. If the user says go, fix one rule at a time, re-run `fringe check` after each, and re-baseline at the end so the file shrinks.
+
+Spot-check a few reported findings by reading the code before presenting them as certain; Fringe is static and can be wrong. Say which you checked.

package/skill/review.md

@@ -0,0 +1,18 @@
+---
+name: fringe-review
+description: Use when the user asks to review, check or critique a UI, page or component for accessibility and UX edges ("review this page", "what's wrong with this form", "is this accessible"). Runs Fringe and reports ranked findings with fixes, in plain English.
+---
+
+# Fringe review
+
+Command: use `fringe` if it is on the PATH, otherwise `npx -y @fringetools/cli` in its place (e.g. `npx -y @fringetools/cli check --json .`).
+
+1. Run `fringe check --json .` from the project root. Fringe takes directories, not single files, so if the user named one file or page, run on the folder and keep only the findings whose `loc.file` matches it.
+2. Report in plain English, no jargon left unexplained:
+   - **Must fix** — `error` findings. Group by rule. For each: where (`file:line`), what is wrong in one sentence, the exact fix, and who is hurt (for example "a screen reader says only 'button'"). Cite the `wcag` criterion when present.
+   - **Worth a look** — `review` findings. These are heuristics: say they need your judgment, and give your call on each.
+   - **Polish** — `signal` findings, only the top few. Never present them as bugs.
+3. End with the health score as measured, the count by severity, and one line on what was not checked (Fringe is static: it cannot judge contrast on images, real focus order, or whether copy is good).
+4. Change no code unless asked. If asked to fix, fix `error` items first and re-run to confirm.
+
+Do not invent findings the tool did not report, and do not call the score an estimate: it is measured.