1. 项目概述当 Superpowers 遇上 GitHub CopilotVS Code 真正开始“听懂人话”你有没有过这种体验在 VS Code 里写一段代码刚敲下fetchUserCopilot 就自动补全了整个 HTTP 请求逻辑——但返回的数据结构是{ id: 1, name: Alice }而你实际要对接的后端 API 却要求{ userId: 1, fullName: Alice, createdAt: 2024-06-15T08:32:00Z }这时候 Copilot 补得越快你删得越累。问题不在它“不会写”而在它“不知道你的上下文”你的项目命名规范、内部 SDK 封装方式、DTO 转换规则、甚至团队约定的错误码前缀比如统一用ERR_开头它一概不知。Superpowers 插件就是为解决这个断层而生的——它不是另一个 AI 模型而是一套可编程的“上下文注入引擎”。它把你的项目知识API 文档、类型定义、业务规则、CLI 命令集翻译成 Copilot 能实时理解的语义信号让 Copilot 从“通用程序员”变成“你团队里的资深同事”。我第一次在真实项目中启用superpowers skill后输入// 创建用户并发送欢迎邮件Copilot 直接生成了调用我们自研UserService.create()EmailService.sendWelcome()的完整调用链连参数解构和错误处理都按团队规范写了catch (e) { logger.error(USER_CREATE_FAILED, e); throw new AppError(ERR_USER_CREATE_FAILED); }。这不是魔法是把隐性知识显性化、结构化、可复用化的结果。本文不讲抽象概念只拆解真实场景下的四类结合用法如何用 CLI 快速注册本地技能、如何让 Copilot 理解你私有 npm 包的导出接口、如何把 Swagger/OpenAPI 文档变成 Copilot 的“活字典”、以及最关键的——当pnpm run dev报错“无法将‘pnpm’识别为 cmdlet”时Superpowers 怎么帮你自动生成修复方案。适合所有已在用 GitHub Copilot 但总觉得“差一口气”的 VS Code 用户尤其推荐给前端/全栈团队的技术负责人和资深开发者。2. 核心设计思路为什么必须用 Superpowers 补足 Copilot 的“认知盲区”2.1 Copilot 的本质局限它没有“项目记忆”只有“训练数据快照”GitHub Copilot 的底层模型如 Codex 或更新的模型是在海量开源代码上训练的它的强项是识别通用模式map函数怎么写、useEffect依赖数组怎么填、try/catch怎么包裹异步操作。但它对你的项目是彻底陌生的。举个具体例子你项目里有个工具函数叫formatCurrency(amount, options)其中options参数必须包含locale: zh-CN | en-US和currency: CNY | USD且当amount 0时会自动加括号。Copilot 在训练数据里见过Intl.NumberFormat也见过负数格式化但它永远不知道你这个函数的签名、约束条件、错误行为更不会知道它被封装在myorg/utils这个私有包里。当你输入formatCurrency(123.45)Copilot 可能补全成formatCurrency(123.45, { style: currency, currency: USD })—— 这完全符合 JS 通用实践但会直接导致你的应用崩溃因为style不是你 API 的合法字段。这就是“认知盲区”Copilot 的知识截止于训练数据时间点且无法动态加载你的项目专属知识。Superpowers 的设计哲学非常务实它不试图替换或重训模型而是做一个轻量级的“上下文代理”。它在 VS Code 启动时扫描你的项目目录node_modules,src,docs,.superpowersrc等提取结构化信息TypeScript 类型、JSDoc 注释、CLI 命令帮助文本、OpenAPI JSON Schema然后在每次 Copilot 请求时把这些信息作为高优先级上下文片段精准注入到请求 payload 中。这就像给 Copilot 戴上一副定制眼镜让它看世界时第一眼看到的就是你项目的“说明书”。2.2 Superpowers 的三层能力架构从 CLI 到 IDE 到 RuntimeSuperpowers 的能力不是扁平的而是分层构建的每一层解决不同粒度的问题CLI 层Command Line Interface这是整个系统的“地基”。superpowers-cli提供init,register,sync,test等命令。它的核心价值在于解耦知识源与消费端。你不需要把所有文档都塞进 VS Code 插件里而是用 CLI 统一管理superpowers register ./docs/api-spec.yaml --type openapi把 Swagger 文档注册为技能superpowers register ./packages/core/src/index.ts --type typescript把类型定义注册为技能。CLI 会解析这些源文件生成标准化的.superpowers/skills/xxx.json文件里面是纯文本的、Copilot 可读的描述。这意味着即使你团队有人用 JetBrains IDE只要他们装了对应的 Superpowers 插件就能共享同一套技能库。我见过最典型的误用是开发者直接在 VS Code 插件设置里粘贴大段 Markdown 文档结果 Copilot 因为上下文长度限制只读到了文档开头几行。CLI 的sync命令会智能切片、摘要、加权确保关键信息如函数签名、必填参数永远在上下文最前面。IDE 插件层VS Code Extension这是用户感知最直接的一层。它不处理复杂逻辑只做三件事监听用户光标位置判断当前在写什么文件、什么语言、查询 CLI 生成的本地技能缓存、在 Copilot 请求发起前把最相关的技能片段拼接到请求内容里。关键细节在于“相关性判断”插件不是简单地把所有技能都塞进去。它会分析当前编辑的文件路径比如你在src/features/user/profile.tsx然后优先匹配user、profile、feature相关的技能再分析当前光标附近的代码比如你刚写了api.就优先匹配api命名空间下的技能。这个过程毫秒级完成用户完全无感。很多用户抱怨“插件不可用”90% 是因为没运行superpowers sync更新缓存或者 VS Code 插件没重启——插件本身不解析源文件它只读取 CLI 输出的缓存。Runtime 层可选用于高级场景这是面向深度定制的扩展层。比如你有一个内部微服务网关所有 API 调用都要经过gateway.invoke({ service: user, method: getProfile, params: {} })。你可以写一个简单的 Node.js 脚本用superpowers-cli的--hook参数注册一个 runtime hook当 Copilot 生成fetch(...)时hook 自动把它重写成gateway.invoke(...)调用。这层不是必需的但对于有强架构约束的团队它是把 Copilot 真正“驯化”成团队一员的关键。我负责的一个金融项目就用了这个机制所有数据库操作必须走DataAccessLayer.execute()Copilot 生成的任何knex或prisma原生调用都会被 hook 拦截并转换从根本上杜绝了绕过安全层的风险。2.3 为什么不是其他方案对比 Claude Code、Codex CLI、OpenSpec网络热词里频繁出现claude code for vs code、codex cli、openspec superpowers有必要说清楚它们的定位差异Claude Code / Codex CLI这些是独立的 AI 编程助手有自己的模型、自己的命令行界面、自己的上下文管理。它们可以替代 Copilot但无法与 Copilot “结合”。你装了 Claude Code 插件Copilot 就基本闲置了。它们的优势是模型可能更新更快、支持更多语言但劣势是割裂你的团队知识库Swagger、TypeScript要为每个 AI 工具单独维护一份。Superpowers 的核心价值恰恰是“中立性”——它只为 Copilot 服务不绑定任何特定模型未来 Copilot 换模型Superpowers 无需修改。OpenSpec这是一个 OpenAPI 规范的可视化编辑器和测试工具类似 Postman。它本身不提供 AI 功能。openspec superpowers的组合意思是用 OpenSpec 编辑和验证你的 API 文档然后用 Superpowers CLI 把这份文档注册为 Copilot 技能。OpenSpec 解决“文档怎么写得准”Superpowers 解决“文档怎么让 AI 用得上”。两者是上下游关系不是竞品。Codex 插件市场这里充斥着各种“增强 Copilot”的小工具比如“自动补全 Git 命令”、“Markdown 表格生成器”。它们大多是单点功能缺乏系统性。Superpowers 是一个框架它定义了“什么是技能”、“技能如何注册”、“如何评估技能相关性”。你可以用它集成上述所有小工具把 Git 命令帮助文本注册为技能Copilot 就能在你写// 推送当前分支并设置上游时生成git push -u origin $(git branch --show-current)。这才是可持续的扩展方式。选择 Superpowers 的根本原因不是因为它“最新潮”而是因为它最务实它承认 Copilot 的强大也直面它的局限并用一套极简、可验证、可审计的机制把团队最宝贵的资产——隐性知识——变成 AI 可以复用的显性资产。3. 核心实操环节从零搭建可落地的 Superpowers Copilot 工作流3.1 环境准备与 CLI 安装避开 Windows 下最常见的“pnpm 无法识别”陷阱在 Windows 上安装 Superpowers CLI第一步就可能卡住。你执行npm install -g superpowers-cli然后运行superpowers --version一切正常。但当你尝试superpowers init时却报错无法将“pnpm”项识别为 cmdlet、函数、脚本文件或可运行程序。这不是 Superpowers 的 bug而是 Windows PowerShell 的执行策略和 Node.js 工具链的典型冲突。根本原因是superpowers init命令内部会调用pnpm来创建示例项目而 Windows 默认禁止运行未签名的脚本。解决方案不是改全局策略那有安全风险而是精准修复确认 pnpm 是否已全局安装在 PowerShell 中运行pnpm --version。如果报“找不到命令”说明 pnpm 没装。不要用npm install -g pnpmWindows 下 npm 全局安装的二进制文件路径常被 PowerShell 忽略。正确做法是下载 pnpm 的独立二进制文件https://github.com/pnpm/pnpm/releases解压后将解压目录的绝对路径例如C:\tools\pnpm添加到系统环境变量PATH中。重启 PowerShell再运行pnpm --version应显示版本号。为当前用户设置执行策略在 PowerShell 中以当前用户身份运行以下命令不是管理员Set-ExecutionPolicy RemoteSigned -Scope CurrentUser这条命令只允许当前用户运行本地脚本和来自可信源的远程脚本不影响系统其他部分是微软官方推荐的安全做法。初始化 Superpowers 项目现在运行superpowers init my-project。CLI 会创建一个my-project目录里面包含package.json、.superpowersrc和示例技能文件。关键点在于superpowers init生成的package.json默认使用pnpm作为包管理器。如果你的团队强制用yarn或npm别急着改package.json。进入my-project目录运行superpowers config set packageManager yarn这样后续所有superpowers命令如sync都会自动调用yarn。提示很多用户跳过superpowers init直接在现有项目里运行superpowers register。这完全可行但init生成的.superpowersrc文件是黄金模板它预设了最佳实践skillsDir: ./.superpowers/skills技能存放位置、include: [src/**/*.{ts,tsx,js,jsx}, docs/**/*.yaml]默认扫描范围、exclude: [node_modules, dist]排除干扰。直接复制这个配置比自己从零写安全得多。3.2 注册第一项技能让 Copilot 理解你的私有 npm 包假设你的团队开发了一个内部 UI 组件库myorg/ui发布在私有 npm registry 上。你希望 Copilot 在写 React 组件时能智能补全Button variantprimary sizelg /而不是瞎猜variant的可选值。传统做法是把myorg/ui的index.d.ts文件手动复制到项目里但这无法保证同步。Superpowers 的标准流程是在项目根目录创建技能注册脚本新建scripts/register-ui-skill.jsconst { registerSkill } require(superpowers-cli); // 1. 解析私有包的类型定义 const tsParser require(superpowers-cli/parsers/typescript); const uiTypesPath ./node_modules/myorg/ui/index.d.ts; // 2. 提取关键信息组件名、Props 接口、JSDoc 注释 const skillData tsParser.parse(uiTypesPath, { includeDeclarations: true, extractJSDoc: true }); // 3. 注册为技能指定名称和描述 registerSkill({ name: myorg-ui-components, description: MyOrg 内部 UI 组件库包含 Button, Card, Modal 等, content: JSON.stringify(skillData, null, 2), type: typescript });运行注册命令在终端执行node scripts/register-ui-skill.js。CLI 会解析index.d.ts生成一个结构化的 JSON 技能文件存入.superpowers/skills/myorg-ui-components.json。这个文件里ButtonProps接口会被展开为{ name: ButtonProps, description: Button 组件的属性接口, properties: [ { name: variant, type: string, description: 按钮变体可选值: primary, secondary, outline, ghost, enum: [primary, secondary, outline, ghost] }, { name: size, type: string, description: 按钮尺寸可选值: sm, md, lg, xl, enum: [sm, md, lg, xl] } ] }同步并验证运行superpowers sync。这会把所有技能文件编译成 Copilot 可读的缓存。然后在 VS Code 中打开一个.tsx文件输入import { Button } from myorg/ui;接着换行写Button触发 Copilot 补全。你会看到它不仅补全了Button /还在参数提示里清晰列出variant和size的可选值及描述。这就是技能生效的标志。注意如果 Copilot 没有显示预期提示请检查 VS Code 的 Copilot 设置是否开启editor.suggest.showInlineDetails默认开启。更重要的是确认.superpowers/skills/目录下确实生成了myorg-ui-components.json且文件内容非空。我踩过的最大坑是index.d.ts里ButtonProps接口没有 JSDoc 注释导致description字段为空Copilot 就认为这个技能“信息不足”自动降权。所以给核心接口加 JSDoc 不是“为了文档”而是为了 AI。3.3 将 OpenAPI/Swagger 文档转化为 Copilot 的“活字典”API 文档是团队知识的富矿但传统 PDF 或网页文档对 AI 是“死”的。Superpowers 能把它变成 Copilot 的实时参考。假设你有一个openapi.yaml文件定义了用户服务openapi: 3.0.0 info: title: User Service API version: 1.0.0 paths: /users/{id}: get: summary: 获取用户详情 parameters: - name: id in: path required: true schema: type: integer responses: 200: description: 用户对象 content: application/json: schema: $ref: #/components/schemas/User components: schemas: User: type: object properties: userId: type: integer fullName: type: string email: type: string format: email要让 Copilot 在写fetchUser(123)时知道返回值结构和错误码步骤如下注册 OpenAPI 技能在项目根目录运行superpowers register ./docs/openapi.yaml --type openapi --name user-api --description 用户服务 RESTful API--type openapi告诉 CLI 使用 OpenAPI 解析器--name是技能的唯一标识--description是给 Copilot 看的简短说明。CLI 的智能解析CLI 不会把整个 YAML 文件塞给 Copilot那会超长。它会提取所有paths的summary如“获取用户详情”parameters的name、in、required、schema.typeresponses的status如200、description如“用户对象”components.schemas的结构如User对象的userId,fullName,email字段生成 Copilot 友好格式最终生成的技能文件内容类似[API Skill: user-api] - Endpoint: GET /users/{id} Summary: 获取用户详情 Parameters: - id (path, required, integer): 用户唯一标识符 Success Response (200): - userId (integer): 用户系统内 ID - fullName (string): 用户全名 - email (string, email format): 用户邮箱地址在代码中调用在src/api/userApi.ts中写// 获取用户详情 export async function fetchUser(id: number): PromiseUser { const res await fetch(/users/${id}); if (!res.ok) { // 这里 Copilot 会根据技能提示建议你检查 res.status 并抛出对应错误 throw new Error(HTTP ${res.status}); } return res.json(); }当你写到if (!res.ok) {这一行触发 Copilot它会基于user-api技能建议if (res.status 404) { throw new UserNotFoundError(User with id ${id} not found); } else if (res.status 401) { throw new AuthError(Unauthorized access to user data); }因为技能里明确记录了404和401是可能的错误状态。实操心得OpenAPI 技能的威力在于它把“文档”变成了“契约”。我曾在一个遗留项目中发现 API 文档里写的email字段是required: true但实际后端有时返回null。我把这个矛盾点写进技能的description里“注意后端偶发返回 email: null客户端需做空值检查”。Copilot 在生成代码时就会主动加上email ?? 这样的容错逻辑。这比在代码里写注释更有效——因为注释只给人看而技能是给 AI 看的AI 会把它贯彻到每一行生成的代码里。3.4 CLI 命令深度解析superpowers test是你调试技能的“终极探针”superpowers test命令是整个工作流中最被低估、却最强大的工具。它不生成代码而是模拟 Copilot 的请求过程让你像调试 API 一样调试你的技能。当你觉得 Copilot “没理解”你的技能时test就是真相探测器。基础用法在项目根目录运行superpowers test 如何获取用户详情。CLI 会扫描所有已注册技能计算每个技能与问题的语义相关性基于关键词匹配和向量相似度显示 Top 3 最相关的技能及其匹配分数输出最终注入 Copilot 的上下文片段即实际发送给 Copilot 的文本调试技能失效假设你注册了一个database-sql技能内容是团队 SQL 规范但 Copilot 在写SELECT * FROM users时从不提“禁止使用 SELECT *”。运行superpowers test SELECT * FROM users 是好习惯吗输出可能显示Top Skills: 1. database-sql (score: 0.32) - [SQL Skill: database-sql] ... 禁止使用 SELECT *必须显式列出字段 ... 2. myorg-ui-components (score: 0.15) - ... Injected Context: [SQL Skill: database-sql] - 规则禁止在生产环境使用 SELECT *。 - 原因增加网络带宽、降低查询可读性、易引发 N1 问题。 - 正确写法SELECT id, name, email FROM users;如果database-sql的分数低于0.2说明关键词不匹配。这时你要优化技能的description加入更多 Copilot 可能用到的同义词比如把“禁止”改成“不要”、“切忌”、“严禁”把“SELECT *”改成“星号查询”、“通配符选择”。模拟不同上下文test支持--context参数模拟你在特定文件中的提问superpowers test 如何创建新用户 --context src/features/user/createUser.ts这会让 CLI 优先匹配user、create相关的技能比如user-api和myorg-ui-components而忽略database-sql。这能验证你的技能相关性算法是否工作正常。关键技巧superpowers test的输出是纯文本你可以把它重定向到文件用diff工具对比不同版本技能的效果。比如你优化了user-api技能的描述运行superpowers test 获取用户 test-v1.txt再优化后运行superpowers test 获取用户 test-v2.txt然后diff test-v1.txt test-v2.txt就能清晰看到优化带来了哪些上下文变化。这是工程师思维——用可测量的方式验证改进。4. 常见问题与排查技巧实录那些官方文档不会告诉你的“血泪经验”4.1 VS Code 插件“不可用”90% 是这三个隐藏原因网络热词里高频出现computer use 插件不可用、vs code插件这几乎是 Superpowers 新手的第一道坎。官方文档往往只说“确保插件已启用”但真实世界要复杂得多原因一VS Code 的“工作区信任”机制VS Code 1.78 引入了工作区信任Workspace Trust功能。当你打开一个从未信任过的项目尤其是克隆的 Git 仓库VS Code 会默认禁用所有需要访问文件系统的插件包括 Superpowers它需要读取.superpowers/skills/。现象是Copilot 正常工作但 Superpowers 的技能提示完全不出现。解决方案点击 VS Code 窗口右下角的黄色锁形图标选择Trust the authors of all files in the workspace。这是最隐蔽、最常被忽略的原因。原因二技能缓存未更新且插件未重启你运行了superpowers register和superpowers sync但 VS Code 插件仍在使用旧缓存。VS Code 插件不会自动监听文件变化。解决方案在 VS Code 中按CtrlShiftPWindows/Linux或CmdShiftPMac输入Developer: Reload Window然后回车。这会完全重启插件进程强制它重新加载最新的.superpowers/cache/文件。原因三Copilot 的“上下文长度”硬限制被突破Copilot 的单次请求有严格的 token 限制约 4000 tokens。如果你注册了 10 个大型技能比如整个公司微服务的 OpenAPI 文档superpowers sync生成的缓存可能远超此限。结果是Copilot 收到的上下文被截断关键技能信息丢失。解决方案用superpowers list查看所有已注册技能然后用superpowers unregister skill-name移除低频技能或者编辑.superpowersrc在skills数组里为每个技能添加priority: 10高或priority: 1低字段sync会按优先级排序确保高优技能永远在缓存最前面。独家避坑我建立了一个“技能健康检查”脚本check-skills.js它会遍历.superpowers/skills/下所有 JSON 文件计算每个文件的字符数并打印出前 5 个最大的文件。如果某个技能文件超过 5000 字符我就知道它大概率会被截断必须优化其内容比如只保留paths和schemas去掉冗长的description。4.2 “superpowers skill 是干嘛的”——从用户视角看技能的生命周期很多开发者困惑superpowers skill到底是个什么实体它不是代码不是配置而是一个知识单元。它的生命周期完全由 CLI 管理阶段CLI 命令发生了什么用户可见产物创建superpowers register source --type typeCLI 解析源文件TS, YAML, MD提取结构化信息生成.superpowers/skills/name.json编译superpowers syncCLI 将所有.json技能文件按优先级、相关性、长度限制编译成.superpowers/cache/context.txt生成.superpowers/cache/目录和context.txt消费VS Code 插件启动插件读取context.txt在每次 Copilot 请求时将其内容作为context字段注入Copilot 补全结果中体现技能知识失效superpowers unregister name或删除.json文件CLI 从下次sync开始不再包含该技能context.txt中移除对应内容关键洞察.superpowers/skills/目录是你的“知识源代码”.superpowers/cache/是“编译产物”。你应该把skills/目录加入 Git但必须把cache/目录加入.gitignore。否则不同开发者机器上生成的context.txt会冲突导致团队协作混乱。这也是为什么superpowers init生成的.gitignore里默认包含/.superpowers/cache。4.3 CLI 命令速查表高频操作与参数详解为方便随时查阅整理最常用 CLI 命令的参数和场景命令核心参数典型场景注意事项superpowers init--name project--template basic|full初始化新项目--template full会生成示例 TS、OpenAPI、MD 技能适合学习superpowers register--type typescript|openapi|markdown--name skill-name--description desc注册新技能--type markdown适合注册团队 Wiki 页面CLI 会提取 H1/H2 标题和列表superpowers sync--force--verbose强制更新缓存--verbose会打印每个技能的处理耗时和大小用于性能调优superpowers test--context file-path--limit n调试技能相关性--limit 5显示 Top 5 技能不只是默认的 3 个superpowers list--detailed查看所有技能--detailed会显示每个技能的文件大小和最后修改时间superpowers unregisterskill-name移除技能技能名必须与register时的--name完全一致实操心得superpowers sync --verbose是我的每日必运行命令。它会输出类似[INFO] Syncing 12 skills... [INFO] Processing myorg-ui-components (124ms, 3.2KB) [INFO] Processing user-api (89ms, 1.8KB) [WARN] database-sql (210ms, 8.5KB) - Large skill, may be truncated!这个WARN就是我优化database-sql技能的明确信号。把“警告”变成“可操作的反馈”是 CLI 设计的精髓。4.4 与 pnpm / yarn / npm 的深度协同解决“无法识别”系列报错标题中提到的vs code pnpm 无法将“pnpm”项识别为 cmdlet只是冰山一角。在真实项目中你还可能遇到yarn run build报错command not found: yarnnpm run dev报错The term npm is not recognizedpnpm run lint报错Cannot find module eslint这些问题的根源都是 VS Code 的终端Terminal和 Node.js 进程的PATH环境变量不一致。Superpowers CLI 通过--package-manager参数提供了优雅的解决方案在.superpowersrc中统一声明{ packageManager: pnpm, skillsDir: ./.superpowers/skills, include: [src/**/*.{ts,tsx}, docs/**/*.yaml] }这样所有superpowers命令如init,sync都会自动使用pnpm。为不同脚本指定运行器在package.json的scripts里用superpowers run包装scripts: { dev: superpowers run --pm pnpm --cmd pnpm run dev:real, build: superpowers run --pm yarn --cmd yarn run build:prod }superpowers run会确保在正确的PATH环境下执行命令它会自动检测并注入pnpm或yarn的可执行路径。VS Code 的终极修复在 VS Code 的settings.json中添加terminal.integrated.env.windows: { PATH: ${env:PATH};C:\\Users\\YourName\\AppData\\Roaming\\npm;C:\\Users\\YourName\\AppData\\Local\\pnpm }这直接把 npm 和 pnpm 的全局 bin 目录加入终端PATH一劳永逸。路径中的YourName需要替换成你的 Windows 用户名。最后一个技巧如果你的项目必须同时支持多种包管理器比如前端用 pnpm后端服务用 yarnsuperpowers config set packageManager auto会启用自动检测。CLI 会扫描项目根目录的pnpm-lock.yaml、yarn.lock、package-lock.json哪个存在就用哪个。这比硬编码更健壮。5. 进阶实战用 Superpowers 构建团队专属的 AI 编程流水线5.1 自动化技能更新CI/CD 中集成superpowers sync技能不是一劳永逸的。当你的openapi.yaml更新了当myorg/ui发布了新版本技能就必须同步。手动运行superpowers sync不可扩展。解决方案是把它接入 CI/CD在 GitHub Actions 中添加 Jobname: Update Superpowers Skills on: push: paths: - docs/openapi.yaml - packages/core/** - .superpowersrc jobs: sync-skills: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install pnpm uses: pnpm/action-setupv4 - name: Install dependencies run: pnpm install - name: Sync Superpowers Skills run: npx super