简报

技术简报AI Skill集合优秀SKILL侦测与发现

优秀SKILL侦测与发现 第 3 期

生成
2026-11-08 16:27
首次公开
2026-11-08 16:27
本版公开
2026-11-10 00:19 · v2
来源
开源技术雷达
自动排版

本期挑出三个已形成方法体系的设计类技能与一个组织型模板：Impeccable（24 命令 + 62 条确定性反 AI 味规则，跨 20 余种 harness）、Hallmark（50 套主题材料 + 三层门禁 + 浏览器级 lint）、jakubkrehel/skills（16 个可单维度结算的界面技能）、以及把 49 个职级化 agent 写进模板的 Claude Code Game Studios。共同趋势是：技能正在从“描述风格”转向“给命令 + 给门禁”。

目录 · 5 节
  1. 本期精选
  2. 候选项目
  3. 相关资料
  4. 值得进一步研究
  5. 原始阅读依据

本期精选

Impeccable

把“设计”从形容词变成动词：不只说“好看点”，而是用 24 个具体动作（bolder、quieter、distill、typeset、harden…）指挥 agent，再用 deterministic 规则把 AI 味的东西堵在发布前。

主要应用领域让 agent 改界面时不再靠猜“好看”；对已有页面做 UX 评分与技术审计（无障碍、性能、主题、响应式，按 P0→P3 排序）；把团队视觉规范沉淀成 DESIGN.md 后复用。

核心价值它解决了 agent 做 UI 最典型的失效模式——默认审美（Inter 字体、紫蓝渐变、卡片套卡片、标题上方一个圆角图标）反复出现。用具体动词替代“做得好看点”，是把设计意图传给 agent 的低成本办法。

采用建议如果你已经在用 agent 改界面，这是性价比最高的一个：先只启用 critique 与 audit 两个审查动作，别急着让 agent 自己 bolder；企业环境先把遥测关掉并审查 hook。

能力、接入与限制

能力与接入以 skill（SKILL.md + 命令手册）形式交付，通过 npx 安装到 Claude Code、Cursor、Codex CLI、Copilot、Gemini CLI、OpenCode、Trae、Qoder、Pi 等 20 余种 harness；每个命令是一份针对单一动作的 playbook，指向一个目标（组件/页面/流程）；自带 62 条确定性 slop 规则（无需 LLM、无需 API key），init 生成 PRODUCT.md、document 生成 DESIGN.md。以上为 README 阅读结论，未安装运行。

关键限制主要面向“已有界面”的迭代，新建页面属更难模式；62 条 slop 规则是确定性规则而非模型判断，只能盖住已知套路；安装器还要写各工具的 hook，而 README 自述“钩子不受模型审批控制、首次编辑可能下载引擎”，无人值守环境需先审查；部分运行会向 impeccable.style 拉取视觉方向（关遥测也仍会请求），对完全离线环境不适用；未安装验证。

项目原始入口15

106,000Apache-2.0

Hallmark

不让模型自由发挥审美：先从 50 套“材料”（纸、字、色、表面）里发三张牌选一，再按页面“要完成的事”决定结构，最后用 lint 在真实浏览器里把人造痕迹和破格逐条扫出来。

主要应用领域营销落地页、产品官网、活动页从零搭建；对已上线页面做“保留内容与接线”的重构；把 AI 生成页的常见毛病（每页都有 email 订阅、表单假感谢、hero 不贴屏）当门禁卡住。

核心价值它把“审美”拆成了可执行的两步：选材料（限制发散）+ 门禁（限制下限）。对有品牌要求但又不想请设计师的小团队，这比“让 agent 自己发挥”稳得多。

采用建议适合“从零做一个落地页/营销页”的场景：先让它选材料出三张牌，再做 hero 单独评审，比一次性生成整页可控；发布前把 sloplint 当 CI 步骤跑。

能力、接入与限制

能力与接入skill + 脚本组合：`theme.mjs deal/draw` 从 50 套主题（每套不超过 8KB 的单文件材料）中发牌并生成页面的“解剖结构”；`sloplint.mjs --render` 在 8 个宽度下渲染检查，另有 fresh-context 子 agent 做二次评审；门禁分三层（Floor 永不可过、Reflex 默认但可记录理由后过、Finish 不阻塞发布）；支持 redesign 保留内容重做结构与 audit 只报告。以上为 README 阅读结论，未安装运行。

关键限制依赖 Node 18+；浏览器检查（sloplint --render、截图）还需额外安装 puppeteer-core 与 Chrome，否则只剩静态检查；50 套主题是“材料”不是布局方案，仍需人判断取舍；实时截图需能访问目标 URL 或 dev server；照片库来自 Wikimedia（各自协议不同），商用需逐个核对；未安装验证。

项目原始入口25

50,500MIT

jakubkrehel/skills

把“界面好不好”拆成 16 个可单独调用的检查器：排版、颜色、无障碍、布局、文案各一个技能，另配几个“把组件在所有状态下渲染出来给你看”的工具型技能。

主要应用领域已有产品做界面体检与逐项修复；代码评审时专门检查“这次改动破坏了哪些界面维度”；把组件的所有状态渲染出来逐个调；离线时让 agent 自行找改进并在本地分支留报告。

核心价值它的价值在“可分别结账”：不像一个大而全的设计技能，这 16 个技能每个对应一个可验收维度（比如只查对比度、只查焦点顺序），适合纳入团队的逐项整改清单。

采用建议适合已有前端项目的团队做“按主题逐个清账”：先跑 better-interface 拿一份排序报告，再按报告逐项用 better-typography / better-colors / better-accessibility 修；不建议一次全装。

能力、接入与限制

能力与接入一组独立的 agent skills：better-interface（跨无障碍、布局、文案、排版、颜色、UI 给一份排序报告）、better-ui、better-typography、better-colors、better-accessibility（对照 WCAG 2.2）、better-layout、better-writing，另有 interface-review（审分支/PR/未提交改动引入的界面问题）、explain-interface（从 URL 或截图反推实现）、break（把组件在所有可达场景下渲染并压测）、build-design（从 Figma 或设计图还原并沿用项目 token）、teardown、state-machine、variant、afk。以上为 README 阅读结论，未安装运行。

关键限制强依赖具体前端工程（能跑 dev server、能渲染组件）才有完整体验，纯文档或后端项目用不上；技能数量多（16 个），选哪个需要先懂一点设计术语；afk 技能会在本地分支自行改代码，团队协作时需先约定分支策略；未安装验证。

项目原始入口35

11,600MIT

候选项目

Claude Code Game Studios

把一整间游戏工作室搬进一个终端会话：49 个带职级的 agent（总监→主管→专员）、74 个流程技能与钩子校验，模拟真实工作室的评审与升级路径。

主要应用领域独立游戏开发者需要“设计文档—任务拆分—实现—QA”这套流程约束；可作为多 agent 协作与质量门禁的模板参考；studio-tests 与 /skill-test 提供了技能自检的写法。

核心价值创意点不在游戏本身，而在“把组织结构写成 agent 契约”：职级、升级路径、领域边界、路径级规则。这套组织方法可以直接搬到任何需要多人（多 agent）协作交付的业务流程里。

采用建议不建议直接拿来改自己的业务项目；它的价值是作为“多 agent 组织设计”的参照：看它如何用职级、升级路径、路径级规则与钩子把一个松散流程变可验收。

能力、接入与限制

能力与接入以 Claude Code 模板形式交付：agents/ 下 49 个带 YAML frontmatter 的 agent 定义（三个总监指定 Opus、lead-programmer 与 15 个专员指定 Sonnet，其余 30 个继承会话模型）；skills/ 74 个斜杠命令覆盖从 /start、/design-system 到 /dev-story、/story-done；另有 15 个钩子（提交、推送、资产变更、设计文档读写等自动校验）、14 条路径级规则与 62 个文档模板；project.yaml 用 modes.rigor（minimal/standard/full）一扇门统管六个旋钮。以上为 README 阅读结论，未安装运行。

关键限制体量极大（49 agent + 74 skill + 15 钩子 + 14 规则 + 62 模板），一次会话的上下文与成本开销明显；深度绑定 Claude Code 生态与特定引擎（Godot/Unity/UE），换 harness 需重写；README 自述“不是自动驾驶”，仍需人持续决策；未安装验证。

项目原始入口45

36,700MIT

相关资料

设计类技能的三层结构：词汇层、检查层、材料层；以及“组织结构即契约”的模板思路

本期的三个设计类技能（Impeccable、Hallmark、jakubkrehel/skills）说明“设计技能”已经分出了三层结构：①词汇层——把模糊的“好看/高级”翻译成可执行动词（bolder、quieter、typeset、harden）；②检查层——用确定性规则或门禁分级把下限卡住（Impeccable 的 62 条规则、Hallmark 的 Floor/Reflex/Finish 三层门禁与 sloplint 八宽度渲染、jakubkrehel 的逐维度审查）；③材料层——给有限的选择而不是无限发散（Hallmark 的 50 套主题、Impeccable 的 DESIGN.md/PRODUCT.md 上下文文件）。选型时可据此判断缺口：只会“描述风格”的技能只覆盖第一层，效果最不稳定；带确定性检查与上下文文件的才可重复。另一个观察是 Claude Code Game Studios 把“组织结构”本身写成了 agent 契约（职级、升级路径、领域边界、路径级规则），这套写法与游戏无关，可直接搬到任何多 agent 交付流程。

研究价值用于筛选任何声称“提升设计/交付质量”的技能：先问它有没有第二层（确定性检查或可验收门禁），再问第三层（是否有持久上下文文件约束发散）。做多 agent 流程设计时，可参考游戏工作室模板的分层与升级路径，而不是堆提示词。

1234

值得进一步研究

1) 在本机 agent 上只装 Impeccable，对现有项目的一个组件跑 critique 与 audit，记录它指出的问题中有多少是你认账的；2) 用 Hallmark 从零做一个真实营销页，重点看 sloplint 在 8 个宽度下报了什么；3) 把 jakubkrehel 的 better-accessibility 单独拿来对照 WCAG 2.2 检查一个表单；4) 不建议本期就引入 49 agent 的游戏工作室模板，先只借鉴它的路径级规则与钩子写法。

原始阅读依据

  1. 1pbakaus/impeccable
  2. 2Nutlope/hallmark
  3. 3jakubkrehel/skills
  4. 4Donchitos/Claude-Code-Game-Studios
  5. 5Hacker News