前端开发者的 Skill 与 MCP 实践分享

英文标题：在职前端 Skill 和 MCP 分享

作者分享了在代码仓迁移过程中实际使用的一组 AI Skill，覆盖组件与数据流可视化、任务拆分、功能实现、冲突解决、代码审查和代码精简等环节。其工作流以先生成 spec、再通过 to-tickets 将功能清单细分、最后使用 implement 执行开发为核心，以减少 Agent 的无序执行与幻觉，并提升验证可靠性。作者同时开始舍弃部分 MCP，转向 Token 消耗更低的 Skill 方案。对于 Mac 用户，文中推荐使用 ego-lite 及其 ego-browser skill，通过共享 Cookie 和将 DOM 映射为 ref 节点来降低浏览器自动化场景的 Token 开销。

打开原文相关 3 · 机会 1

中文

距离上一次分享已经过去很久。这次主要分享我在迁移代码仓时使用的一些 Skill，同时也移除了一些 MCP。

首先是 Skills：

show-me：结合 AI 迁移代码时，往往会生成数不清的组件。无论是复盘，还是排查性能问题，仍然需要了解相应模块或功能中的组件关系与数据流向。这个 Skill 可以将复杂逻辑非常直观地展示出来。
to-tickets：在迁移过程中，我已经沉淀出一套 spec 生成流程，因此不需要使用 Matt 的 to-spec skill，而是使用 to-tickets。它能够将已制定的功能清单进一步拆细，生成多个小清单，避免 Agent 工作时无序混乱。这样既能保障开发后的验证，也能减少幻觉。
implement：该 Skill 需要与 to-tickets 配合使用。在清单拆分完成后，由它执行具体的功能开发，效果非常好。
resolving-merge-conflicts：适用于多人协作开发或上游代码更新的场景。它会追溯代码提交源头，分析上下游代码，最终解决冲突。
code-review：一个分支对应一个 issue，开发完成后即可调用。它能够基于项目 rules 检查不足之处，主要包括代码规范以及 spec 功能清单方面的检查。
code-simplifier：当代码行数超过 350 行时，我会使用这个 Skill。

接下来是一批 MCP 的舍弃，以及相应的替代方案。

本质上，是将 MCP 方案替换为 Token 消耗更低的 Skill 方案。从 Playwright CLI 官网的一张图中即可看出差异：

playwright-cli 与 MCP 的对比

如果使用 Mac，推荐使用 ego-lite 浏览器。它提供 ego-browser skill，可以打开独立的浏览器空间进行功能验证，并且共享你的 Cookie。页面中的 DOM 节点会映射为 ref 节点，能够节省更多 Token，体验上比 Playwright 好用不少。

English / 原文

距离上一次分享已经过去好久，这次主要分享我在做迁移代码仓时用到的一些 skill，同时也移除了一些 mcp。

首先是 skills：

show-me 结合 ai 迁移代码往往有数不清的组件生成，复盘或者在研究性能问题时总还是需要了解对应模块或功能的组件关系和数据流走向的，该 skill 可以把复杂的逻辑非常直观地展现出来。
to-tickets 在迁移过程中，我已经沉淀了一套 spec 生成流程，所以不需要用到 matt 的 to-spec skill，而用 to-tickets，可以把已经制定好的功能清单再切细一些，生成几张小清单，不至于 agent 工作时无序错乱，这样开发后的验证有保障、且幻觉更少。
implement 该 skill 需要和 to-tickets 一起使用，在切好清单后，由它来实施功能开发，效果非常好。
resolving-merge-conflicts 多人开发或者上游有更新时使用，会追溯代码提交源头，分析上下游代码，最后解决冲突。
code-review 一个分支对应一个 issue，开发完以后调用，能够基于项目 rules 检查出不足之处，主要包括规范类和 spec 功能清单的检查。
code-simplifier 在代码行数超过 350 行时，我会用一下。

接下来是一批 mcp 的舍弃以及对应的替代方案。

本质上是把 mcp 方案换成 token 消耗更低的 skill 方案。playwrigt-cli 官网有一张图就能看出来：

playwright-cli vs mcp

如果是 Mac 电脑推荐使用 ego-lite 浏览器，它提供了 ego-browser skill，可以打开一个浏览器独立空间进行功能验证，且共享你的 cookie，页面上的 DOM 节点映射为 ref 节点更省 token，要比 playwright 好用不少。