@autono/create-open-pages 0.7.0 → 0.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli.js +2 -2
- package/package.json +1 -1
- package/template/.agents/skills/apply-comments/SKILL.md +1 -0
- package/template/.agents/skills/create-page/SKILL.md +5 -1
- package/template/.agents/skills/create-theme/SKILL.md +2 -0
- package/template/.agents/skills/page-authoring/SKILL.md +3 -0
- package/template/.agents/skills/web-design-guidelines/SKILL.md +41 -0
- package/template/AGENTS.md +1 -0
- package/template/tsconfig.json +0 -1
package/dist/cli.js
CHANGED
|
@@ -100,7 +100,7 @@ async function isDirNonEmpty(target) {
|
|
|
100
100
|
return (await readdir(target)).some((e) => !e.startsWith("."));
|
|
101
101
|
}
|
|
102
102
|
function coreVersionRange() {
|
|
103
|
-
return `^0.
|
|
103
|
+
return `^0.8.0`;
|
|
104
104
|
}
|
|
105
105
|
async function linkOrCopy(relSrc, dst) {
|
|
106
106
|
await rm(dst, {
|
|
@@ -341,7 +341,7 @@ async function runInit(dirArg, flags) {
|
|
|
341
341
|
if (!installed) next.push(`${pm} install`);
|
|
342
342
|
next.push(pm === "npm" ? "npm run dev" : `${pm} dev`);
|
|
343
343
|
p.note(next.map((line) => chalk.cyan(line)).join("\n"), "Next steps");
|
|
344
|
-
p.outro(`All set! ${chalk.dim("
|
|
344
|
+
p.outro(`All set! ${chalk.dim("Docs: https://docs.openpages.sh")}`);
|
|
345
345
|
}
|
|
346
346
|
async function run(argv) {
|
|
347
347
|
const version = await readVersion();
|
package/package.json
CHANGED
|
@@ -56,6 +56,7 @@ Your job: read those markers, perform the described edits, and delete the marker
|
|
|
56
56
|
- After all edits, re-read the file and confirm the only remaining markers are ones you reported as skipped.
|
|
57
57
|
- Confirm the edited JSX is well-formed (balanced tags, no dangling attributes) and that changed `className` strings are literal Tailwind utilities. If the project's `package.json` has typecheck/lint scripts, run them with the project's package manager; scaffolded projects ship neither TypeScript nor a linter — there, rely on the running dev server (or the `build` script) to surface compile errors. Fix any errors you introduced.
|
|
58
58
|
- For layout changes, mentally check the Mobile viewport (390px): did the edit introduce a fixed width or a grid with no stacking fallback?
|
|
59
|
+
- When a comment changed interactive elements, forms, motion, or layout, run the `web-design-guidelines` skill on the page and fix any regression it reports before you report.
|
|
59
60
|
|
|
60
61
|
7. **Report.**
|
|
61
62
|
- Summarise: `N applied, M skipped` plus a one-line description of each change (including the page id).
|
|
@@ -94,7 +94,11 @@ Read the **`page-authoring`** skill before writing — file contract, `@/ui/*` c
|
|
|
94
94
|
|
|
95
95
|
## Step 7 — Self-review
|
|
96
96
|
|
|
97
|
-
Run the checklist in `page-authoring` ("Self-review before finishing"): every button/input/card/dialog/tab is a `@/ui` component, colors are tokens, nothing under `ui/` changed. Check all three viewports.
|
|
97
|
+
Run the checklist in `page-authoring` ("Self-review before finishing"): every button/input/card/dialog/tab is a `@/ui` component, colors are tokens, nothing under `ui/` changed. Check all three viewports. Pay particular attention to the CTA and motion items: one label per intent, no wrapped button text at desktop, every animation answers "what does this communicate?".
|
|
98
|
+
|
|
99
|
+
## Step 7b — Guidelines review
|
|
100
|
+
|
|
101
|
+
Run the `web-design-guidelines` skill on `pages/<id>/` (it fetches Vercel's current Web Interface Guidelines and reports `file:line` findings). Fix what it finds in the page files, re-run until clean or until only findings you can justify remain, and mention any you left in the hand-off.
|
|
98
102
|
|
|
99
103
|
## Step 8 — Hand off to the user
|
|
100
104
|
|
|
@@ -25,6 +25,7 @@ A theme can be derived from any combination of:
|
|
|
25
25
|
- **Image references / brand guidelines** — paths or URLs to screenshots, mood boards, logo files, a brand PDF. You will translate them into OKLCH tokens.
|
|
26
26
|
- **Free-text description** — prose describing the desired palette, weight, feel.
|
|
27
27
|
- **An existing page** — `pages/<id>/index.tsx` whose look should become reusable.
|
|
28
|
+
- **A `DESIGN.md`** — a design-system document in the Google-spec shape (YAML frontmatter, then Overview, Colors, Typography, Layout, Elevation, Shapes, Components, Do's and Don'ts). [designmd.supply](https://designmd.supply) generates one from any public domain, so "match our brand" is: run the site through it, drop the file at `themes/<id>.design.md` (or paste the path), and ask for a theme.
|
|
28
29
|
|
|
29
30
|
If the user's original message already specifies the inputs unambiguously, skip the question and proceed. Otherwise call `AskUserQuestion` (multi-select) so they can pick one or more sources, and ask follow-ups (paths, preset code, page id, prose) only as needed.
|
|
30
31
|
|
|
@@ -34,6 +35,7 @@ If the user's original message already specifies the inputs unambiguously, skip
|
|
|
34
35
|
- **Images**: read each path with the `Read` tool (it accepts images). Note dominant colors (write them as hex, then convert to OKLCH), type family feel, corner radius, surface treatment (flat vs. cards vs. borders), light or dark default, and chrome (nav style, footer).
|
|
35
36
|
- **Text**: extract explicit values (hex codes, font names, "rounded", "sharp", "dense") and resolve vague language into concrete decisions before writing.
|
|
36
37
|
- **Existing page**: read `pages/<id>/index.tsx` (and `components/`) and pull any raw palette classes or hex values into token roles (the page's `bg-[#0b0b10]` root → `--background`; its CTA fill → `--primary`; its card border → `--border`), plus fonts and radius.
|
|
38
|
+
- **`DESIGN.md`**: read it and map sections onto tokens — **Colors** gives `--background`/`--foreground`, `--primary`, `--secondary`, `--accent`, `--muted`, `--destructive` (primary = the brand's main action color, not its logo color, when they differ); **Typography** gives `--font-sans` / `--font-heading` and the type-scale feel; **Shapes** gives `--radius`; **Elevation** decides flat vs. card-with-shadow treatment in the component notes; **Layout** informs container widths and density in the demo; **Components** and **Do's and Don'ts** become the "Components in this theme" guidance. Colors may arrive as hex, `rgb()`, `hsl()`, `oklch()`, or CSS named colors — parse each by its own syntax, then convert to OKLCH. A single light palette is normal; derive the `.dark` block from it (invert lightness, keep hue and chroma) and say so in the `.md`.
|
|
37
39
|
|
|
38
40
|
Every color ends up as `oklch(L C H)` — the same format as `styles/globals.css`. When inputs disagree (images use blue but the description says green), ask the user which to honor.
|
|
39
41
|
|
|
@@ -187,7 +187,10 @@ A theme is `themes/<id>.md` (direction and component notes) + `themes/<id>.css`
|
|
|
187
187
|
- [ ] One coherent type scale across the page; contrast holds on dark sections.
|
|
188
188
|
- [ ] Designed repeats are explicit component instances; data lists are a `.map` over a typed const.
|
|
189
189
|
- [ ] No `window`/`document` access at module top level; effects clean up.
|
|
190
|
+
- [ ] One label per CTA intent across the page ("Get started" in the nav, hero, and footer — not "Get started" / "Sign up free" / "Try it"), and no primary button label wraps at desktop width.
|
|
191
|
+
- [ ] Every animation is motivated: it shows hierarchy, sequence, feedback, or a state change. If you cannot say which in one sentence, remove it. `motion-safe:` / `motion-reduce:` variants respect the user's preference.
|
|
190
192
|
- [ ] Nothing outside `pages/<id>/` was edited.
|
|
193
|
+
- [ ] Ran the `web-design-guidelines` skill on the page and resolved or justified its findings.
|
|
191
194
|
|
|
192
195
|
## Anti-patterns
|
|
193
196
|
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: web-design-guidelines
|
|
3
|
+
description: Review page code against Vercel's Web Interface Guidelines — accessibility, focus and keyboard handling, forms, motion, layout, typography, and performance. Use when asked to "review my page", "check accessibility", "audit the design", "review UX", or as the review pass at the end of `create-page` and `apply-comments`.
|
|
4
|
+
metadata:
|
|
5
|
+
author: vercel
|
|
6
|
+
version: "1.0.0"
|
|
7
|
+
argument-hint: <page-id or file-or-pattern>
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Web Interface Guidelines
|
|
11
|
+
|
|
12
|
+
Review page files for compliance with Vercel's [Web Interface Guidelines](https://github.com/vercel-labs/web-interface-guidelines) (MIT). Vendored from the [vercel-labs/agent-skills](https://github.com/vercel-labs/agent-skills) `web-design-guidelines` skill and scoped to an open-pages workspace.
|
|
13
|
+
|
|
14
|
+
## How it works
|
|
15
|
+
|
|
16
|
+
1. Fetch the latest guidelines from the source URL below.
|
|
17
|
+
2. Read the files to review.
|
|
18
|
+
3. Check them against every rule in the fetched guidelines.
|
|
19
|
+
4. Report findings in the terse `file:line` format the guidelines specify.
|
|
20
|
+
|
|
21
|
+
## Guidelines source
|
|
22
|
+
|
|
23
|
+
Fetch fresh guidelines before each review:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and the output format. If the fetch fails (offline, blocked), say so and fall back to the self-review checklist in the `page-authoring` skill instead of guessing at rules.
|
|
30
|
+
|
|
31
|
+
## What to review
|
|
32
|
+
|
|
33
|
+
- Given a page id, review the page's entry (`pages/<id>/index.tsx` or `pages/<id>/index.html`), everything under `pages/<id>/components/`, and any `styles.css`, `style.css`, or `main.js` beside the entry.
|
|
34
|
+
- Given a file or glob, review those files.
|
|
35
|
+
- Given nothing, resolve the current page with the `current-page` skill; if that yields nothing, ask which page to review.
|
|
36
|
+
|
|
37
|
+
Never review or report on files under `ui/`, `lib/`, `hooks/`, or `styles/`. Those are the shared shadcn set and are not edited for one page; a finding there is a `create-theme` or upstream matter, not a page fix.
|
|
38
|
+
|
|
39
|
+
## Applying findings
|
|
40
|
+
|
|
41
|
+
Report first. When the user asks you to fix, or the review runs inside `create-page` or `apply-comments`, apply the fixes to the page files only, following the `page-authoring` skill: keep `@/ui/*` components, keep semantic tokens, keep the type scale. Do not add dependencies to satisfy a rule.
|
package/template/AGENTS.md
CHANGED
|
@@ -18,6 +18,7 @@ You are authoring **web pages** in this repo. Every page is a React component re
|
|
|
18
18
|
- **Applying inspector comments** (`@page-comment` markers in a page) — use the `apply-comments` skill.
|
|
19
19
|
- **Creating or extracting a theme** — use the `create-theme` skill. A theme is `themes/<id>.md` plus `themes/<id>.css` (shadcn token overrides) and a `<id>.demo.tsx` preview; `create-page` reads it before authoring and a page opts in with `meta.theme`.
|
|
20
20
|
- **shadcn CLI, registries, presets, component docs** — the bundled `shadcn` skill (the official one) covers `npx shadcn@latest search / view / docs / add / apply`.
|
|
21
|
+
- **Reviewing a page for accessibility and interaction quality** — the bundled `web-design-guidelines` skill (Vercel's, vendored) checks a page against the current Web Interface Guidelines. `create-page` runs it before hand-off; run it on its own when asked to "review my page" or "check accessibility".
|
|
21
22
|
- **Resolving "this page" / "this element"** — when the user references the current page or selection without naming it, consult the `current-page` skill. It reads the dev server's `node_modules/.open-pages/current.json` to find which page and inspector-picked element they mean.
|
|
22
23
|
- **Any other page edit** — read the `page-authoring` skill before writing. It is the technical reference for everything inside `pages/<id>/`: file contract, styling with Tailwind, layout and responsiveness, interactivity, assets and fonts, self-review checklist. `create-page` and `apply-comments` both defer to it for the *how*.
|
|
23
24
|
|