webcraft-skills 0.1.1

package/skills/webcraft-skills/references/presets/cinematic-minimal.md

@@ -0,0 +1,48 @@
+# cinematic-minimal
+
+A restrained cinematic minimal web UI preset for personal sites, product pages, portfolios, quiet landing pages, and lightweight SaaS pages.
+
+## Goals
+
+- Calm visual hierarchy.
+- Stable spacing, typography, radius, borders, and states.
+- Less AI-template smell and decorative noise.
+- More realistic product feel.
+
+## Principles
+
+- Every visual element must serve information, action, or atmosphere.
+- Make the page readable, usable, and credible before styling it.
+- The hero must have one primary focal point; title, product visual, and background should not all compete.
+- Components need complete states, not only a static screenshot.
+- Mobile is not a scaled-down desktop layout.
+
+## Visual Rules
+
+- Use warm dark, graphite, and deep muted neutral backgrounds. Avoid pure black.
+- Use low-saturation amber, gold, or warm yellow accents in small areas only.
+- Avoid neon, cyberpunk, rainbow gradients, glowing buttons, heavy glassmorphism, and decorative light blobs.
+- Background texture, noise, or edge light must stay quiet and secondary.
+
+## Typography And Copy
+
+- Headings should be clear and confident, not poster-like or slogan-heavy.
+- Body copy should be specific, restrained, and credible.
+- Avoid empty marketing phrases such as "redefine", "next generation", "revolutionary", and "unlock limitless potential".
+- Keep font size, weight, and line-height scales limited and stable.
+
+## Layout And Components
+
+- Each section should communicate one core idea.
+- Keep max widths restrained; avoid empty wide screens and cramped small screens.
+- Use fewer cards than common templates. Do not wrap every content block in a floating panel.
+- Buttons, links, forms, menus, and modals need hover, active, focus-visible, disabled, and loading states where relevant.
+- Lists and data areas need loading, empty, error, and success states where relevant.
+- Radius, border, shadow, and background opacity should form a coherent system.
+
+## Responsive
+
+- Check 375px, 768px, and 1280px viewports.
+- Avoid horizontal scroll, edge-touching text, tiny buttons, distorted images, and sticky elements that hide content.
+- Mobile navigation and modals must be truly usable.
+

package/skills/webcraft-skills/references/presets/cinematic-minimal.zh.md

@@ -0,0 +1,53 @@
+# cinematic-minimal
+
+电影感极简网页规则，用于生成、重构或润色个人品牌页、产品页、作品集、轻量 SaaS 官网和安静的工具型页面。
+
+## 适用目标
+
+- 更克制的视觉层级
+- 更稳定的 spacing、typography、圆角、边框和状态
+- 更少 AI 模板感、营销感和装饰噪音
+- 更像真实产品，而不是概念海报
+
+## 核心原则
+
+- 每个视觉元素都必须服务信息、操作或氛围。
+- 页面先保证可读、可用、可信，再追求风格。
+- 首屏只能有一个主视觉焦点，标题、产品视觉、背景不要同时抢注意力。
+- 组件要有完整状态，不能只做静态截图。
+- 移动端不是桌面端缩小版，必须重新检查导航、按钮、标题、图片和弹窗。
+
+## 视觉规则
+
+- 背景使用暖黑、石墨灰、深棕灰等低饱和暗色，避免纯黑。
+- 强调色小面积使用低饱和暖黄、琥珀、金棕，避免高饱和蓝紫、霓虹和彩虹渐变。
+- 背景可以有轻微空气感、柔和暗部变化、低透明噪点或边缘光，但不能成为主视觉。
+- 避免大面积炫光、科技网格、玻璃拟态、发光按钮、装饰性光球。
+
+## 字体与文案
+
+- 标题清楚、有力量，但不要海报化或口号化。
+- 中文标题自然断句，英文标题不要把短词逐个拆行。
+- 正文具体、可信、克制，避免“重新定义”“下一代”“革命性”“释放无限潜能”等空泛营销词。
+- 字号、字重、行高层级要少而稳定。
+
+## 布局
+
+- section 只表达一个核心信息。
+- 页面最大宽度保持克制，大屏不要空散，小屏不要拥挤。
+- 卡片数量少于常规模板，不要把每个内容块都包成浮层卡片。
+- hero 建议包含清晰标题、简短说明、1 到 2 个 CTA，以及一个安静的产品视觉或氛围视觉。
+
+## 组件与状态
+
+- 按钮、链接、表单、菜单、弹窗必须具备 hover、active、focus-visible、disabled；涉及异步时补 loading。
+- 数据、列表或用户动作必须考虑 loading、empty、error、success。
+- 边框、圆角、阴影、背景透明度要形成体系，避免组件拼贴感。
+- hover 不应导致布局位移，避免夸张放大、弹跳、强阴影。
+
+## 响应式
+
+- 检查 375px、768px、1280px 三档视口。
+- 禁止横向滚动、文字贴边、按钮过小、图片变形、sticky 遮挡内容。
+- 移动端导航必须真实可用，弹窗必须可关闭且内容不溢出。
+

package/skills/webcraft-skills/references/workflows/audit-ui.md

@@ -0,0 +1,272 @@
+# UI Audit Workflow
+
+Use this workflow to inspect the UI quality of a page, component, screenshot, local app, or whole site. `audit-ui` defines the execution process; the `ui-audit` rubric defines the judging criteria.
+
+The goal is to find issues, collect evidence, and recommend fix order. Do not redesign or edit code during audit unless the user explicitly asks to audit and fix.
+
+## Responsibility Boundary
+
+- This workflow defines how to run the audit: choose depth, collect context, verify viewports, capture evidence, structure findings, and decide whether to hand off to fixing.
+- For what counts as an issue, severity definitions, page-type differences, and dimension-specific criteria, read `references/checklists/ui-audit.md`.
+- Do not mechanically dump every rubric category into the report. Report only issues with evidence, impact, and a worthwhile fix.
+- Do not read both English and Chinese references unless the task is translation, bilingual comparison, localization, or consistency checking.
+
+## 1. Choose Audit Mode
+
+Choose depth from the user's request:
+
+- `Quick Audit`: for "quick look" or "any big issues". Report only Critical and obvious Major issues.
+- `Standard Audit`: default. Report Critical, Major, and a small number of valuable Minor findings.
+- `Deep Audit`: for "thorough audit", "strict audit", "pre-launch", or "find details". Use the full rubric, scoring model, content stress testing, and extra viewports.
+
+Use `Standard Audit` when the user does not specify.
+
+## 2. Collect Context
+
+Before judging, confirm or infer:
+
+- Scope: single page, component, screenshot, whole site, code directory, or localhost.
+- Page type: landing page, dashboard, app screen, portfolio, docs, form, checkout, admin, etc.
+- Core task: read, sign up, buy, search, filter, manage, create, contact, download, book, etc.
+- Audience: general users, developers, enterprise buyers, creators, internal operators, managers, etc.
+- Tech constraints: component library, Tailwind, shadcn, custom CSS, design tokens, routes, breakpoints.
+- Verification level: browser-tested, static code review, screenshot review, or mixed.
+
+If information is missing, infer from structure and content, but label it as inferred.
+
+## 3. Identify Existing Visual System
+
+First identify the product's current visual system:
+
+- Color: brand, background, text, status, and accent usage.
+- Typography: type scale, weight, line-height, heading/body rhythm.
+- Spacing: containers, section spacing, component padding, grid gaps.
+- Radius, border, shadow: shared rules across buttons, cards, inputs, dialogs, menus.
+- Component style: buttons, forms, navigation, cards, tables, dialogs, toasts.
+- Product tone: marketing, tool, content, admin, personal brand, etc.
+
+Unless the user asks for a new direction, judge recommendations within the existing visual system. Do not impose a preset as the default taste standard.
+
+## 4. Read Audit Rubric
+
+At runtime, read `references/checklists/ui-audit.md`. Apply:
+
+- Audit boundaries
+- Deduplication and priority
+- Device matrix
+- Evidence standards
+- Page-type differences
+- Scoring model
+- Layout / Typography / Color / Border Radius Shadow / Components / Navigation / Forms / Modals / Responsive / Motion / Accessibility / Content Stress / AI Template Smell
+
+## 5. Choose Inspection Method
+
+### Code Project
+
+- Inspect project structure, page entry points, global styles, components, and routes first.
+- Judge risks from component implementation, style rules, breakpoints, and state logic.
+- If the app can run, verify key viewports and interactions in the browser.
+
+### Localhost / Runnable Page
+
+- Prefer browser inspection for real layout, scrolling, click, focus, dialogs, dropdowns, inputs, and responsive behavior.
+- Record actual viewport and page region.
+- Do not make final claims from source alone when the page is runnable.
+
+### Screenshot
+
+- Audit only visible visual, layout, hierarchy, copy, and obvious states.
+- Do not assert hover, focus, keyboard paths, dialog closing, dropdown styling, loading states, or other behavior not visible in the screenshot.
+- Put interaction questions under `Open Questions`.
+
+### Single Component
+
+- Focus on size, states, long content, variants, accessible names, and relationship to surrounding components.
+- Do not audit a single component using whole-page landing-page standards.
+
+### Whole Site
+
+- Sample core paths; do not enumerate every page.
+- Cover at least homepage, primary conversion page, core product/function page, and state-heavy pages such as forms, auth, or settings.
+- Report systemic issues and Top Findings instead of piling up page-by-page minor problems.
+
+## 6. Inspect Project Structure
+
+For code audits, locate:
+
+- Page entries: `app/`, `pages/`, `src/routes/`, `src/pages/`, `index.html`, etc.
+- Global styles: `globals.css`, `app.css`, `tailwind.config.*`, design tokens.
+- Components: button, card, input, modal, nav, table, list, toast.
+- Routes and page types: home, pricing, dashboard, settings, docs, auth, checkout.
+- UI system: shadcn, Radix, MUI, custom components, Tailwind utilities.
+
+Do not give broad visual advice before understanding the project structure.
+
+## 7. Run Viewport Checks
+
+If the project can run, prefer browser verification. Check at least:
+
+- 375px mobile
+- 768px tablet
+- 1280px desktop
+
+For Deep Audit, add:
+
+- 360px
+- 390px or 430px
+- 834px
+- 1440px
+- 1920px
+
+If the page cannot run, infer from CSS, layout code, breakpoints, and component structure. State which viewports and interactions were not verified.
+
+## 8. Capture Evidence
+
+Capture evidence according to inspection method:
+
+- Browser evidence: viewport width, page region, interaction state, scroll position, visible symptom.
+- Code evidence: file path, component name, CSS class, breakpoint, state branch, style token.
+- Screenshot evidence: visible region, element relationship, clipping, overlap, hierarchy.
+- Inferred evidence: risks based on code or screenshot must be labeled as untested or needs verification.
+
+Evidence should support judgment; do not list irrelevant implementation details.
+
+## 9. Audit Order
+
+Check in this order:
+
+1. Critical usability: overflow, overlap, unclickable controls, unreadable content, broken nav/dialog/form.
+2. Responsive: mobile, tablet, large desktop, fixed/sticky elements, images, tables.
+3. Information hierarchy: first-screen priority, page type, core task clarity.
+4. Components and states: hover, active, focus-visible, disabled, loading, empty, error, success.
+5. Visual system: spacing, typography, color, radius, border, shadow.
+6. Content stress: long text, mixed languages, varied counts, varied image ratios.
+7. AI template smell: vague slogans, excessive badges, bento grids, gradient glows, fake data.
+8. Minor polish: alignment, rhythm, motion, copy details.
+
+## 10. Control Finding Count
+
+- `Quick Audit`: up to 5 findings, only Critical and obvious Major.
+- `Standard Audit`: usually 8 to 12 findings, prioritized as Top Findings.
+- `Deep Audit`: may include more, but start with Top Findings before category detail.
+- If Critical/Major findings already explain the main risk, do not keep digging for low-value Minor items.
+- Do not pad the report to look complete.
+
+## 11. Report Format
+
+Use this structure:
+
+```markdown
+## Context
+
+- Scope:
+- Audit mode:
+- Page type:
+- Core task:
+- Viewports checked:
+- Verification level:
+- Constraints:
+
+## Top Findings
+
+- The 3 to 5 highest-risk issues, sorted by impact.
+
+## Critical
+
+### 1. Finding title
+Location:
+Evidence:
+Impact:
+Fix:
+
+## Major
+
+...
+
+## Minor
+
+...
+
+## Open Questions
+
+- Questions that need user confirmation or runtime verification.
+
+## Pass Notes
+
+- 1 to 3 high-value notes about areas with no obvious issue.
+
+## Fix Order
+
+1.
+2.
+3.
+
+## Score
+
+- Usability:
+- Clarity:
+- Consistency:
+- Responsiveness:
+- Interaction States:
+- Visual Maturity:
+- AI Template Smell:
+- Overall:
+```
+
+Rules:
+
+- `Quick Audit` may omit Score and Minor.
+- `Standard Audit` may omit Score unless requested.
+- `Deep Audit` should usually include Score.
+- Every finding needs concrete evidence.
+- Critical and Major findings must be locatable and fixable.
+- Omit categories with no findings.
+- `Open Questions` is only for questions, not advice.
+- `Pass Notes` should be short and high-value.
+
+## 12. Deduplicate And Group
+
+- Report one root cause once.
+- Keep blocking usability issues as separate Critical findings.
+- Group systemic visual issues, such as mixed radius/border/shadow systems, into one Major finding.
+- Do not force coverage of every rubric category.
+- If a question needs product judgment, put it under `Open Questions`.
+
+## 13. Handoff To Fix
+
+If the user asks to continue fixing, enter the `fix-ui` workflow.
+
+Before fixing, confirm or infer:
+
+- Whether the user asked for direct code changes.
+- Whether only Critical/Major issues should be fixed.
+- Whether visual tokens may be adjusted.
+- Whether existing visual style and content must be preserved.
+
+Fix order:
+
+1. Critical: unusable, unreadable, unclickable, unclosable issues.
+2. Major: responsive behavior, hierarchy, component states, visual tokens.
+3. Content Stress: long copy, real data, varied counts and media ratios.
+4. AI Template Smell: remove template noise and add real information structure.
+5. Minor: alignment, motion, copy, visual polish.
+
+Do not make broad code changes during audit unless the user explicitly asks to audit and fix.
+
+## 14. Stop Conditions
+
+- If you find a blocking Critical issue, stop digging for Minor polish and report risk plus fix order.
+- In Standard Audit, stop when Top Findings cover the meaningful risks.
+- In Deep Audit, prioritize systemic issues over scattered details.
+- If evidence is insufficient, stop inferring and mark it as `Open Questions` or needs verification.
+
+## 15. Prohibited
+
+- Do not fabricate browser verification.
+- Do not report issues without location, evidence, and fix direction.
+- Do not package personal taste as a defect.
+- Do not recommend unrelated technical refactors.
+- Do not turn every page into the same style.
+- Do not force a preset when the user did not choose one.
+- Do not remove necessary business information for the sake of visual consistency.
+- Do not state unverified issues as fact.

package/skills/webcraft-skills/references/workflows/audit-ui.zh.md

@@ -0,0 +1,299 @@
+# UI Audit Workflow
+
+用于严格、系统地排查网页、页面、组件、截图或整站 UI 质量。`audit-ui` 负责执行流程，`ui-audit` rubric 负责判断标准。
+
+审查的目标是发现问题、给出证据和修复顺序，不是直接重写设计。只有当用户明确要求修复时，才进入修复流程。
+
+## 职责边界
+
+- 本 workflow 只定义如何执行 audit：选择模式、收集上下文、验证视口、采集证据、组织报告、决定是否转入修复。
+- 具体什么算问题、如何分级、各页面类型和 UI 维度的判断标准，读取 `references/checklists/ui-audit.zh.md`。
+- 不要把 rubric 逐条复制进报告；只输出有证据、有影响、有修复价值的问题。
+- 不要同时读取英文和中文 reference，除非任务是翻译、双语对齐或一致性检查。
+
+## 1. 选择审查模式
+
+根据用户请求选择审查深度：
+
+- `Quick Audit`：用户说“快速看看”“有没有大问题”。只报告 Critical 和明显 Major。
+- `Standard Audit`：默认模式。报告 Critical、Major 和少量有价值 Minor。
+- `Deep Audit`：用户说“全面排查”“严格 audit”“准备上线”“找细节问题”。使用完整 Rubric、评分模型、Content Stress Test 和更多视口。
+
+如果用户没有指定，使用 `Standard Audit`。
+
+## 2. 收集上下文
+
+正式审查前，先确认或推断：
+
+- Scope：单页、组件、截图、整站、代码目录或 localhost。
+- Page type：landing page、dashboard、app screen、portfolio、docs、form、checkout、admin 等。
+- Core task：阅读、注册、购买、搜索、筛选、管理、创作、联系、下载、预约等。
+- Audience：普通用户、开发者、企业客户、创作者、内部运营、管理者等。
+- Tech constraints：已有组件库、Tailwind、shadcn、自定义 CSS、设计 token、路由和断点。
+- Verification level：已运行浏览器、代码静态审查、截图审查，或混合审查。
+
+缺少信息时可以根据项目结构和页面内容推断，但要标明“推断”。
+
+如果用户使用中文提问，报告默认使用中文；必要的字段名和模式名可以保留英文，方便和命令、文档、自动化输出保持一致。
+
+## 3. 识别现有视觉体系
+
+审查必须先识别当前网站或产品已有的视觉体系，包括：
+
+- 颜色：品牌色、背景色、文字色、状态色、强调色使用方式。
+- 字体：字号层级、字重、行高、标题和正文节奏。
+- spacing：页面容器、section 间距、组件内边距、grid gap。
+- 圆角、边框、阴影：按钮、卡片、输入框、弹窗和菜单的共同规律。
+- 组件风格：按钮、表单、导航、卡片、表格、弹窗、toast 的既有样式。
+- 页面语气：营销型、工具型、内容型、后台型、个人品牌型等。
+
+除非用户明确要求重设风格，否则所有审查建议都必须在现有视觉体系内判断。不要把某个 preset 当作默认审美标准。Preset 只有在用户明确指定，或当前项目没有明确视觉方向时，才作为参考。
+
+## 4. 读取审查标准
+
+运行时读取 `references/checklists/ui-audit.zh.md`。重点应用其中：
+
+- 审查边界
+- 去重与优先级
+- 设备检查矩阵
+- 证据标准
+- 页面类型差异
+- 评分模型
+- Layout / Typography / Color / Border Radius Shadow / Components / Navigation / Forms / Modals / Responsive / Motion / Accessibility / Content Stress / AI Template Smell
+
+不要逐条机械输出所有分类。只报告有证据、有影响、有修复价值的问题。
+
+## 5. 根据输入类型选择审查方式
+
+### 代码项目
+
+- 先读项目结构、页面入口、全局样式、组件和路由。
+- 基于组件实现、样式规则、断点和状态逻辑判断风险。
+- 如果能运行，再用浏览器验证关键视口和交互。
+
+### localhost / 可运行页面
+
+- 优先用浏览器检查真实布局、滚动、点击、focus、弹窗和响应式。
+- 记录实际视口和页面区域。
+- 不要只看源码就下最终结论。
+
+### 截图
+
+- 只能审查可见的视觉、布局、层级、文案和明显状态。
+- 不要断言 hover、focus、键盘路径、弹窗关闭、loading 等无法从截图验证的行为。
+- 需要交互判断时，列入 `Open Questions`。
+
+### 单组件
+
+- 重点检查尺寸、状态、长内容、组合变体、可访问名称和与周边组件的关系。
+- 不要按整页 landing page 标准审查一个组件。
+
+### 整站
+
+- 先抽样核心路径，不要逐页穷举。
+- 至少覆盖首页、核心转化页、核心功能页、表单/登录/设置等状态密集页面。
+- 输出系统性问题和 Top Findings，而不是把每一页的小问题堆在一起。
+
+## 6. 检查项目结构
+
+如果审查的是代码项目，先找到：
+
+- 页面入口：`app/`、`pages/`、`src/routes/`、`src/pages/`、`index.html` 等。
+- 全局样式：`globals.css`、`app.css`、`tailwind.config.*`、design tokens。
+- 组件：button、card、input、select、combobox、dropdown、checkbox、radio、modal、nav、table、list、toast。
+- 路由和页面类型：home、pricing、dashboard、settings、docs、auth、checkout。
+- 已有 UI 系统：shadcn、Radix、MUI、自定义组件、Tailwind utility 体系。
+
+不要在不了解项目结构时直接给大范围设计建议。
+
+### 自定义控件一致性检查
+
+代码审查时必须主动检查项目是否已有自定义基础控件，并反查页面是否仍混用原生控件：
+
+- 先找已有组件：`Select`、`Combobox`、`Dropdown`、`MultiSelect`、`Checkbox`、`RadioGroup`、`Input`、`Textarea`、`Button` 等。
+- 再找原生用法：`<select>`、`<option>`、`<input type="checkbox">`、`<input type="radio">`、未封装的 `<input>` / `<textarea>`，以及只靠浏览器默认样式的控件。
+- 如果项目已有对应自定义控件，但某个页面仍使用突兀原生控件，必须作为 `Components And States` 或 `Forms` finding 评估，不要只放进 `Content Stress` 或 `Pass Notes`。
+- 如果项目没有对应自定义控件，但原生控件明显不符合当前网站风格，也要报告；修复方向是建立或封装与现有视觉体系一致的基础控件，而不是只调整单个页面。
+- 如果原生控件只是视觉略不协调且不影响操作，通常是 `Minor`；如果出现在筛选、批量操作、编辑表单等核心后台流程，并明显破坏视觉系统或操作信心，通常是 `Major`。
+
+## 7. 运行与视口检查
+
+如果项目可运行，优先用浏览器验证真实布局和交互，并可用截图记录证据。默认至少检查：
+
+- 375px mobile
+- 768px tablet
+- 1280px desktop
+
+Deep Audit 增加：
+
+- 360px
+- 390px 或 430px
+- 834px
+- 1440px
+- 1920px
+
+如果无法运行页面：
+
+- 基于 CSS、布局代码、断点和组件结构做静态推断。
+- 明确写出未验证的视口和交互。
+- 不要虚构“已看到”的浏览器结果。
+
+## 8. 证据采集
+
+根据审查方式记录证据：
+
+- 浏览器证据：视口宽度、页面区域、交互状态、滚动位置、可见现象。
+- 代码证据：文件路径、组件名、CSS 类、断点、状态分支、样式 token。
+- 截图证据：截图区域、可见元素、层级关系、裁切或遮挡现象。
+- 推断证据：基于代码或截图推断的风险，必须标明“未实测”或“需要验证”。
+
+证据要服务判断，不要为了显得详细而罗列无关实现。
+
+## 9. 审查顺序
+
+按这个顺序检查，避免一开始陷入审美细节：
+
+1. Critical usability：overflow、遮挡、不可点击、不可读、导航/弹窗/表单不可用。
+2. Responsive：移动端、平板、大屏、fixed/sticky、图片和表格溢出。
+3. Information hierarchy：首屏主次、页面类型是否清楚、核心任务是否明确。
+4. Components and states：hover、active、focus-visible、disabled、loading、empty、error、success。
+5. Form/control consistency：输入、选择、下拉、多选、菜单、批量操作是否沿用项目已有组件体系。
+6. Visual system：spacing、typography、color、radius、border、shadow。
+7. Content stress：长文案、中英文混排、不同数据数量、不同图片比例。
+8. AI template smell：空泛口号、过度 badge、bento grid、渐变光斑、虚假数据。
+9. Minor polish：对齐、节奏、动效、文案细节。
+
+## 10. Findings 数量控制
+
+- `Quick Audit`：最多 5 条，只报告 Critical 和明显 Major。
+- `Standard Audit`：建议 8 到 12 条，优先 Top Findings。
+- `Deep Audit`：可以更多，但先输出 Top Findings，再按分类展开。
+- 如果 Critical/Major 已经足够说明主要风险，不继续挖低价值 Minor。
+- 不要为了让报告看起来完整而凑数量。
+
+## 11. 输出报告
+
+使用这个结构：
+
+```markdown
+## Context
+
+- Scope:
+- Audit mode:
+- Page type:
+- Core task:
+- Viewports checked:
+- Verification level:
+- Constraints:
+
+## Top Findings
+
+- 最重要的 3 到 5 个问题，按风险排序。
+
+## Critical
+
+### 1. 问题标题
+Location:
+Evidence:
+Impact:
+Fix:
+
+## Major
+
+...
+
+## Minor
+
+...
+
+## Open Questions
+
+- 需要用户确认或需要运行页面才能判断的问题。
+
+## Pass Notes
+
+- 简短说明没有发现明显问题的关键方面。
+
+## Fix Order
+
+1.
+2.
+3.
+
+## Score
+
+- Usability:
+- Clarity:
+- Consistency:
+- Responsiveness:
+- Interaction States:
+- Visual Maturity:
+- AI Template Smell:
+- Overall:
+```
+
+规则：
+
+- `Quick Audit` 可以省略 Score 和 Minor。
+- `Standard Audit` 可省略 Score，除非用户要求。
+- `Deep Audit` 建议保留 Score。
+- `Top Findings` 用于让用户先看到最重要风险；如果问题很少，可以省略。
+- 每个 finding 必须有具体证据。
+- Critical 和 Major 必须可定位、可修复。
+- 没有发现的问题分类不要输出。
+- `Open Questions` 只放需要确认的问题，不放建议。
+- `Pass Notes` 不要逐项列通过，只保留 1 到 3 条高价值说明。
+
+## 12. 去重与分组
+
+- 同一根因只报告一次。
+- 阻断使用的问题单独列为 Critical，不要合并进系统性问题。
+- 系统性视觉问题可以合并，例如 radius、border、shadow 混乱可以作为一个 Major。
+- 不要为了覆盖所有分类而凑问题。
+- 如果问题需要产品决策，放到 `Open Questions`，不要假装是确定缺陷。
+
+## 13. 修复衔接
+
+如果用户要求继续修复，进入 `fix-ui` workflow。
+
+修复前先确认：
+
+- 用户是否要求直接改代码。
+- 是否只修 Critical/Major。
+- 是否允许调整视觉 token。
+- 是否需要保持现有视觉风格和内容不变。
+
+修复顺序：
+
+1. Critical：先修不可用、不可读、不可点击、不可关闭。
+2. Major：再修响应式、信息层级、组件状态、视觉 token。
+3. Content Stress：再修长文案、真实数据和变体内容。
+4. AI Template Smell：删除模板噪音，补真实信息结构。
+5. Minor：最后做对齐、动效、文案和视觉 polish。
+
+不要在 audit 阶段直接大改代码，除非用户明确要求“审查并修复”。
+
+修复后必须复检对应问题：
+
+- 修 overflow 的，复检对应视口。
+- 修状态的，复检 hover、focus-visible、disabled、loading、error。
+- 修弹窗的，复检关闭、滚动和 focus。
+- 修视觉 token 的，复检同类组件是否一致。
+
+## 14. 停止条件
+
+- 已经找到会阻断使用的 Critical 时，先停止深挖 Minor，优先输出风险和修复顺序。
+- Standard Audit 中，如果 Top Findings 已覆盖主要风险，不继续列低价值 polish。
+- Deep Audit 中，可以继续展开，但要把系统性问题优先于零散细节。
+- 如果证据不足，不继续推断；把问题放入 `Open Questions` 或标注需要验证。
+
+## 15. 禁止事项
+
+- 不要虚构浏览器验证结果。
+- 不要输出没有位置、没有证据、没有修复建议的问题。
+- 不要把纯审美偏好包装成缺陷。
+- 不要建议无关技术重构。
+- 不要把所有页面都改成同一种风格。
+- 不要在用户未指定 preset 时强行套用 preset 风格。
+- 不要因为统一视觉而删除必要业务信息。
+- 不要把没有验证的问题写成确定事实。

package/skills/webcraft-skills/references/workflows/build-ui.md

@@ -0,0 +1,12 @@
+# UI Build Workflow
+
+Use this workflow to create a new page or site.
+
+1. Identify the page type, subject, audience, core content, tech stack, and constraints.
+2. If the user does not specify a style, choose the closest preset based on product context; do not force cinematic-minimal.
+3. Plan the information structure before visual styling.
+4. Generate a complete runnable page or implementation, including responsive behavior and relevant hover, active, focus-visible, disabled, loading, empty, error, and success states.
+5. Run the UI Audit Checklist against the result and fix obvious issues.
+
+Output the implementation result, key design decisions, and verification performed. Do not stop at abstract design advice.
+