[codex] Refine BetterGPT skill routing

skills/BetterGPT/BetterFrontend/SKILL.md

@@ -1,67 +1,55 @@
 ---
 name: better-frontend
-description: Use when generating, revising, polishing, or reviewing frontend UI, landing pages, dashboards, app screens, marketing pages, or other presentation-layer output that should look like a production-ready product instead of a demo, draft, wireframe, showcase, or developer-facing mockup. Especially use when the request mentions removing AI-like UI, avoiding demo feel, preventing TODO or note text, hiding reasoning or design commentary from users, eliminating placeholder explanations, or making the final interface feel shippable, real, and user-facing.
+description: Use for frontend cleanup, dashboards, app screens, or presentation review. Remove TODOs/placeholders/dev reasoning with small diffs; preserve UI language; avoid decorative rewrites.
 ---
 
 # Better Frontend
 
-## Overview
+## Scope
 
-把所有前端展示层任务默认当作正式可交付成品处理。
-优先保证用户可见结果可直接落地，而不是像原型、草稿、演示稿或开发中间态。
+Use this skill for user-visible UI work: pages, dashboards, admin/workbench surfaces, app screens, landing pages, and frontend copy.
 
-## Trigger Signals
-
-当请求或上下文出现以下信号时，应优先使用本 skill：
-
-- 用户要求做前端页面、落地页、仪表盘、控制台、工作台、营销页、应用界面
-- 用户强调“像正式产品”“能上线”“不要 demo 感”“不要 AI 味”
-- 用户要求删除用户可见界面中的开发者备注、思路说明、设计评论、占位解释
-- 用户提到“不准把 TODO / NOTE / mock / placeholder / reasoning 放到页面里”
-- 用户要求“润色 UI”“收敛视觉输出”“把页面改得更像真实产品”
-- 当前方案明显更像原型、概念稿、样板页、作品集展示，而不是正式成品
-
-## When Not to Use
-
-- 用户明确要求 wireframe、低保真草图、教学示例页、组件演示页
-- 任务只是在写技术文档、设计说明、评审备注，而不是在生成用户可见前端
-- 任务只涉及后端接口、数据库、脚本或 CLI，不涉及展示层输出
+Goal: make the visible product usable and production-ready without turning small cleanup into a redesign.
 
 ## Hard Constraints
 
-- 禁止把面向开发者的备注、思维过程、设计评论、实现说明、占位解释输出到用户可见界面。
-- 禁止把“材质感、光影、动效、视觉工艺”的解说型文案写进用户可见副标题、说明文案、卡片描述。
-- 默认按正式产品界面开发，不按 demo、wireframe、概念稿、展示稿思路产出。
-- 优先交付真实用户可理解、可操作、可上线的前端结果。
-- 非用户显式要求时，不向界面中加入“开发中”“示例数据”“后续接接口”“这里可扩展”等说明性文本。
-- 不与当前项目内的 `.trellis/spec/frontend/*` 长期维持两套平行前端规范。
+- Never expose developer notes, TODOs, placeholder explanations, mock/demo labels, implementation plans, design commentary, or reasoning in user-visible UI.
+- Preserve the current visible language and product shape unless the user explicitly asks to translate or redesign.
+- For an existing page, inspect the current structure and line count before editing. Default to a local diff; do not replace the whole file for copy/demo cleanup.
+- For cleanup/productization of a small existing page, keep the result within `max(original_lines + 80, original_lines * 2)` unless the user explicitly asks for a redesign. If that limit is insufficient, explain why before broadening scope.
+- Do not use web search for local UI cleanup unless the user asks for external competitors, assets, or current information.
+- Dashboard/admin/ops surfaces should be restrained, dense, and scannable; do not use marketing heroes, decorative gradients, glass blur, glow, or large-radius styling as the default way to look polished.
+- Cards and panels default to `border-radius <= 8px` unless the project design system already uses larger radii.
+- If the project has `.trellis/spec/frontend/`, treat it as the primary frontend rule source; references here are fallback guidance.
 
 ## Default Working Rules
 
-1. 先判断哪些内容属于用户可见展示层，哪些内容只应留在代码、注释或对话中。
-2. 对展示层文案做一次泄漏检查，删掉所有开发者视角文本。
-3. 对页面结构做一次产品化检查，确认它像正式成品，而不是演示模板。
-4. 优先收敛界面信息密度、视觉层级、组件用途和文案意图，避免为了“解释设计”而污染界面。
-5. 副标题、说明文案、卡片描述默认必须服务用户任务：解释状态、结果、风险、收益、下一步动作；如果主要是在描述界面怎么好看、材质怎么真实、动效怎么细腻，就不应进入展示层。
-6. 如果页面类型是功能页、工具页、数据页、控制台、工作台，默认禁止把营销页式氛围描写、设计旁白、展示稿话术带入副标题。
-5. 如果当前项目存在 `.trellis/spec/frontend/`，前端规范优先参考该目录；本 skill 自带 references 只做补充，不单独形成第二套平行规范。
+1. Identify the visible UI and the exact request type: cleanup, polish, redesign, or new build.
+2. For existing pages, record `wc -l` and make the smallest patch that can satisfy the request.
+3. Clean visible copy: remove TODO/FIXME/NOTE, placeholder/mock/demo language, future-backend text, sample disclaimers, and developer-facing explanations.
+4. Productize within the current layout first: labels, statuses, actions, spacing, borders, and only the structure needed for the user task.
+5. Before final, run narrow checks:
+   - `wc -l <file>` and compare against the cleanup line-count budget.
+   - `rg -n 'TODO|FIXME|NOTE:|placeholder|mock|demo|sample|future backend|developer|reasoning' <file>`.
+   - For HTML, strip tags and scan visible text when class names cause false positives.
+   - For dashboard/admin pages, scan CSS for `radial-gradient`, `backdrop-filter`, `filter: blur`, heavy `box-shadow`, or `border-radius` above `8px`.
+6. Final report should state the result, checks run, and residual risk only; do not add a generic optional follow-up after a narrow cleanup.
 
 ## Read References When Needed
 
-- 需要判断哪些内容绝不能进入展示层时，读 `references/banned-content.md`
-- 需要判断默认成品化标准时，读 `references/production-defaults.md`
-- 需要判断前端视觉输出约束时，读 `references/visual-rules.md`
-- 需要做 dashboard、admin、workbench 等后台页面时，读 `references/page-rules-dashboard.md`
-- 需要做 landing page、营销页、品牌展示页时，读 `references/page-rules-landing.md`
-- 需要交付前做最终自检时，读 `references/pre-delivery-checklist.md`
+- Read `references/banned-content.md` for content that must not appear in visible UI.
+- Read `references/production-defaults.md` for default production-readiness standards.
+- Read `references/visual-rules.md` for visual output constraints.
+- Read `references/page-rules-dashboard.md` for dashboard, admin, and workbench pages.
+- Read `references/page-rules-landing.md` for landing pages and brand/product pages.
+- Read `references/pre-delivery-checklist.md` before final delivery.
 
 ## Red Flags
 
-出现以下任一情况时，先停下并回退：
+Stop and revise if any of these appear:
 
-- 页面上出现 TODO、NOTE、placeholder explanation、mock 提示、设计备注
-- 用户可见文案在解释“这个模块是干什么的给开发者看”
-- 用户可见副标题或描述文案在解释玻璃、高光、折射、渐变、漂浮、镜面、雾面、霓虹、层叠、虚化等视觉工艺
-- 页面文案读起来像作品集、设计稿旁白、展示稿解说，而不是产品界面语言
-- 页面更像模板站、演示稿、AI 样例，而不像真实产品
-- 为了说明思路，把实现过程、评审说明或设计讨论直接写进 UI
+- Visible TODO, NOTE, placeholder explanation, mock/demo label, design note, or implementation plan.
+- Visible copy explains the UI to a developer instead of helping the end user act.
+- A small cleanup expands into a template rewrite or exceeds the line-count budget without explicit user approval.
+- The visible UI language changes without user request.
+- Dashboard/admin/ops pages gain a hero, decorative chart, decorative KPI row, right rail, gradient/glass/glow treatment, or many rounded pills just to look busy.

skills/BetterGPT/BetterFrontend/references/banned-content.md

@@ -1,78 +1,28 @@
-# Banned Content in User-Visible UI
+# Banned Content In Visible UI
 
-以下内容默认不得进入前端展示层：
+Visible UI must serve the end user, not the developer, reviewer, or design process.
 
-## 1. 面向开发者的备注
+## Ban
 
-- TODO
-- FIXME
-- NOTE:
-- 这里后续接接口
-- 这里替换成真实数据
-- 开发阶段先这样
-- 该区域可继续扩展
+- `TODO`, `FIXME`, `NOTE:`
+- `mock`, `placeholder`, "sample", "demo"
+- "connect backend later"
+- "replace with real data"
+- "this section demonstrates..."
+- "this component shows..."
+- "temporary implementation"
+- explanations of design decisions or implementation choices
+- copy that describes the UI material itself, such as glass, glow, refraction, blur, floating layers, shimmer, or gradient richness
 
-## 2. 思维过程或设计评论
+## Rule
 
-- 我这里这样设计是因为……
-- 为了演示这个能力……
-- 此处用于说明某个技术点……
-- 这个模块展示了……
-- 这里先用一个简单实现……
+If the sentence explains how the interface was built, why it looks good, or what it is demonstrating, keep it out of the visible product surface.
 
-## 2.1 伪产品化的设计旁白
+## Allowed Direction
 
-以下内容即使不出现“TODO / NOTE”，默认也不应进入用户可见界面：
+Replace developer/design commentary with user-facing state, outcome, risk, or action.
 
-- 阳光以柔顺渐变铺满界面
-- 卡片表面的镜面高光会随着鼠标移动产生真实折射
-- 冷色玻璃与雨滴动画同步起伏
-- 玻璃表层偏雾面
-- 霓虹反射、层叠、沉浸、质感更强、层次丰富
-- 在描述高光、渐变、折射、镜面、玻璃、虚化、漂浮、扫光、流动时，主语是“界面 / 卡片 / 画面 / 动效”而不是用户任务
+Examples:
 
-判定原则：
-
-- 如果一句话主要是在解释界面怎么好看、材质怎么真实、动效怎么细腻  
-  → 它属于设计旁白，不属于产品文案
-- 即使这句话写得很像营销文案，只要它不服务用户状态、任务、结果、风险、收益  
-  → 也不应进入展示层
-
-## 3. 面向评审者或开发者的解释性文本
-
-- 点击这里查看组件效果
-- 这是一个示例卡片
-- 下方用于演示布局能力
-- 这段文案仅用于占位
-- 当前使用 mock 数据
-
-## 4. 不应直接暴露给终端用户的工程状态
-
-- 开发中
-- 待实现
-- 暂未接入后端
-- 未来支持更多功能
-- 可对接 API
-
-## 处理原则
-
-- 用户看得到的地方，只保留服务用户任务的内容。
-- 开发者信息应留在注释、提交说明、对话解释、设计文档或工单里。
-- 如果一句话主要是在向开发者或评审解释实现过程，就不应进入展示层。
-- 如果一句话主要是在向用户“展示这个界面有多会做设计”，也不应进入展示层。
-
-## 错误文案 vs 正确文案
-
-### 错误
-
-- 阳光以柔顺渐变铺满界面
-- 镜面高光会随着鼠标移动产生真实折射
-- 冷色玻璃与雨滴动画同步起伏
-- 玻璃表层偏雾面，雪片在近景和远景之间切换
-
-### 正确
-
-- 阳光充足，紫外线较强，适合短时户外活动
-- 阵风明显，体感偏低，外出建议增加防风层
-- 降雨持续，能见度下降，通勤请预留更多时间
-- 气温持续低于零度，出行请注意保暖和地面湿滑
+- Instead of visual-material commentary, show weather, finance, workflow, or domain state.
+- Instead of "mock data", either wire real data, label a real empty state, or keep the note in code/docs rather than UI.

skills/BetterGPT/BetterFrontend/references/page-rules-dashboard.md

@@ -1,57 +1,32 @@
-# Dashboard / Admin / Workbench Rules
+# Dashboard / Admin / Workbench Pages
 
-## Scope
+Use for dashboard, admin, console, workspace, workbench, internal tool, and data-heavy operation pages.
 
-适用于以下页面类型：
+## Goal
 
-- dashboard
-- admin
-- console
-- workspace
-- workbench
-- internal tool
-- data-heavy operation page
+Make the page efficient, stable, and maintainable. It should support repeated work, not perform like a marketing hero.
 
-## Core Goal
+## Prefer
 
-让后台、控制台、工作台看起来像长期可维护的真实产品，而不是营销站首屏、AI 样板后台或为了展示设计能力拼出来的面板墙。
+- Direct sidebar/content or filter/table/list/detail structures.
+- First-screen access to the main operation, state, result, or queue.
+- Charts only for real trend, comparison, or distribution questions.
+- Cards only for meaningful grouping.
+- Functional copy for filters, forms, tables, statuses, and feedback.
+- In-place cleanup for existing dashboard files: improve copy, spacing, borders, and labels before adding new regions.
 
-## Positive Rules
+## Avoid
 
-- 先围绕真实任务路径组织页面，再决定布局
-- 首屏优先展示最重要的操作、状态、列表、过滤、表单或工作结果
-- 信息架构保持直接、稳定、可预期
-- 卡片只在确实需要信息分组时使用
-- 图表只在真实存在趋势、对比、分布需求时使用
-- 页面标题直接表达当前页面职责，不写空泛口号
+- hero sections in admin pages
+- KPI-card rows as the default first response
+- charts, progress rings, or trend arrows without real data purpose
+- command-center or cockpit language for ordinary workflows
+- decorative right rails added only to make the page look busy
+- repeated oversized rounded cards and pills across every surface
+- rewriting a small existing page into a large dashboard template when the user mainly asked to remove demo/placeholder leakage
 
-## Hard No
+## Check
 
-- 不要在后台首页放 hero section
-- 不要默认做 KPI 卡片横排作为第一反应
-- 不要没有真实业务需求就塞图表、环图、进度条、趋势箭头
-- 不要把后台页面写成“控制中心”“作战台”“指挥舱”式自嗨视觉稿
-- 不要用大段文案解释这个后台多么高效、多么清晰、多么强大
-- 不要在侧边栏、面板、表格、统计卡上重复同一种夸张圆角和装饰风格
-- 不要做左右双 rail + 中间内容的“信息很多但没有任务主线”布局
+The user should quickly see what they can do, where to click, and what state needs attention.
 
-## Common Smells
-
-- 顶部一整块大横幅 + slogan + 副文案
-- 首屏 4 个以上统计卡，但没有明确主任务入口
-- 没有真实数据结构却硬塞多种图表
-- 右侧做一个“今日安排 / 最近动态 / 系统状态”装饰栏，只是为了显得页面充实
-- 每个模块都像展示组件，而不像用户真正会用的工作区域
-
-## Default Layout Bias
-
-- 优先正常 sidebar + content，或 filter + table / list / detail 的成熟结构
-- 优先直接暴露任务入口，不先演一段视觉概念
-- 优先让用户一眼看清：我能做什么、我该点哪里、当前状态是什么
-
-## Copy Bias
-
-- 标题写页面目的，不写设计口号
-- 副文案只在能减少理解成本时保留
-- 表格、表单、筛选、状态反馈都用直接、真实、功能性语言
-- 不向用户解释“这个模块展示了什么能力”
+For cleanup of an existing page, compare the final line count with the original. If it exceeds `max(original_lines + 80, original_lines * 2)`, treat that as a redesign and require explicit user intent or a clear explanation.

skills/BetterGPT/BetterFrontend/references/page-rules-landing.md

@@ -1,54 +1,27 @@
-# Landing / Marketing Page Rules
+# Landing / Marketing Pages
 
-## Scope
+Use for landing, marketing, brand, product intro, or feature showcase pages.
 
-适用于以下页面类型：
+## Goal
 
-- landing page
-- marketing page
-- brand page
-- product intro page
-- feature showcase page
+Build a page with clear value, audience, evidence, and action. Visual style may be stronger than an admin tool, but every section must support the story or conversion.
 
-## Core Goal
+## Prefer
 
-让营销页或品牌展示页看起来像真实产品团队打磨过的正式页面，而不是 AI 批量生成的“高级感网页模板”。
+- Hero that quickly says what this is, who it is for, and why it matters.
+- Specific benefits, proof, scenarios, and differentiators.
+- CTA copy that names the action.
+- Trust support near conversion points.
+- Concrete product language over abstract slogans.
 
-## Positive Rules
+## Avoid
 
-- 先明确价值主张、受众、转化动作，再决定视觉表达
-- 页面节奏围绕信息递进、信任建立、行动转化展开
-- 主标题、副标题、证明信息、CTA 各司其职
-- 视觉可以更强，但每个模块都必须服务叙事和转化
-- 文案要具体、有对象、有结果，不说空泛漂亮话
+- generic slogans such as "redefine the future" or "unlock potential"
+- a full page of feature cards without a clear product claim
+- glass, neon, gradient, glow, badge, pill, or floating-panel excess
+- dashboard KPI blocks inserted only for decoration
+- abstract buzzwords replacing actual user value
 
-## Hard No
+## Check
 
-- 不要靠玻璃拟态、夸张渐变、科技蓝紫光污染来冒充高级感
-- 不要堆一页“功能卡片”但说不清产品到底解决什么问题
-- 不要写空泛口号，例如“重新定义未来”“释放无限潜力”“打造下一代体验”
-- 不要把后台式 KPI 模块硬塞进营销页
-- 不要用过多 badge、pill、装饰性 icon、悬浮面板制造设计感
-- 不要用大量抽象词替代真实卖点、证据和使用场景
-
-## Common Smells
-
-- 页面第一屏只有漂亮标题和抽象文案，没有真实价值信息
-- 每个 section 看起来都像 Dribbble 样板
-- 为了显得专业，塞大量渐变块、发光边框、柔和阴影、浮层卡片
-- CTA 附近没有清晰的利益点和信任支撑
-- 用户看完页面，只知道“挺好看”，但不知道产品是什么、适合谁、该不该点
-
-## Default Structure Bias
-
-- hero 只负责快速讲清楚：这是什么、给谁用、为什么值得继续看
-- 中段优先放证据、能力、场景、差异，而不是连续堆视觉样式
-- CTA 前优先补强信任，而不是继续装饰
-- 页面结构要像有销售逻辑，而不是像 UI 样板合集
-
-## Copy Bias
-
-- 标题说人话，不说生成式品牌黑话
-- 副标题优先讲收益、对象、使用结果
-- CTA 要明确，不做模糊邀请
-- 少用“革命性”“智能化”“生态级”“全链路赋能”这类空洞词
+After the first screen, the user should know what the offer is, whether it is for them, and what to do next.