Skills Registry

• 把 skills 从“藏在本地和聊天里的经验片段”变成了一个可分享、可解释、可持续维护的能力入口。
• 相比单纯罗列 skill 名称，这个版本更适合作为公开作品来展示你的 workflow 设计能力。

• 把信息架构从“按 skill 名浏览”改成“先按任务与场景找入口”，让用户先缩小范围，再进入具体 skill。
• 把网站定位为 registry / triage layer，而把完整 spec、更新与源码留给 GitHub 承接。

• 线上站点已明确呈现“先找到要做的事，再点最合适的 skill”的入口语义，并按场景组织内容。
• 本地较早版本仍以 skills-hub 为名，说明它经历了从个人目录到公开 registry 的演化，而不是一次性静态页。

• Owner / Product Engineer：把分散在本地目录、仓库和工作流里的 skills 产品化成一个可公开访问的入口，并明确它的内容边界与使用方式。

• 当 skills 越来越多时，真正的阻碍不再是“有没有能力”，而是“知道要做什么时，不知道该先看哪个 skill”。

• 公开站不能直接暴露私密 workflow、内部路径或未脱敏内容，因此需要在“能公开什么”与“完整说明放在哪里”之间做分层。
• 如果把所有说明都堆在网站里，目录会迅速变重、变乱，也会增加后续维护成本。

当常用 skills 累积到一定程度，问题就不再是“有没有”，而是“真正开始做事时，先调哪个”。这个项目想解决的，是 skills 被埋在本地文件夹、聊天记录和仓库里的可见性问题，把它们变成一个稳定的公开入口。

• 当你知道自己要做“调研、写文档、做前端、自动化交付”这类任务，但还不知道具体该先用哪个 skill 时，先从场景页缩小范围。
• 当你想把常用 workflow 公开分享给别人，又不想让对方直接淹没在一堆 SKILL.md 和仓库结构里时，用这个站做入口层。
• 当你需要区分“公开技能 / 脱敏公开 / 仍然私有”的边界时，用 registry 来管理展示层，而不是把所有内容混在一起。

• 任务优先的首页：不是先背 skill 名，而是先看“你要完成什么”。
• 场景页 + 技能总览：先做筛选和判断，再跳转到更深入的说明。
• GitHub 分流：公开站负责介绍、筛选和分享，完整说明、更新记录与源码继续由仓库承接。

• 信息架构从早期偏“目录式 skills-hub”演进到现在的“task-first registry”，核心判断是：大多数人先知道任务，而不是先知道 skill 名称。
• 页面保留暖纸色背景、衬线字和细线分割，是为了让它更像一份可读的 guide / registry，而不是高噪音的 SaaS dashboard；这种气质更适合长时间浏览和打印。
• 没有把完整说明全部塞进站里，而是故意把深文档留在 GitHub，避免首页承担过多文档压力。

• 当前公开站以静态站形态发布，重点放在内容编排、入口组织与链接治理，而不是重型应用状态。
• 站点与 GitHub 仓库分工明确：前者负责展示和导航，后者承载完整 skill 内容、更新记录与源码演化。
• 公开页面同时承接“公开技能数量、脱敏公开数量、已上线场景”等状态表达，让能力目录也具有发布层语义。

• 线上入口：https://skills.zondev.top。
• 页面中已经直接提供 GitHub 仓库、技能目录与最近更新链接，方便继续深挖完整内容。