SuperAPI AI 工具集找到适合任务的 Agent Skill，阅读介绍并复制安装命令。
更新于 10-16 00:02
36,282 个结果
w-api-docs 是一个用于刷新 API 文档的技能，强调从拥有 schema 的源头更新文档，而不是手工编辑生成的 OpenAPI。它适用于使用 TypeBox/Fastify 路由或仓库中已有文档生成器的项目。核心做法是：阅读 API 文档 MDX 与生成器 README，识别拥有源与 package.json 中的生成脚本；修改拥有 schema 或路由，而非生成产物；运行文档化的生成命令，并在仓库有漂移脚本时检查漂移；仅针对行为变化更新采用者 MDX，不臆造认证、限流或版本策略。若行为或命令发生变化，可参考 /w-docs。
w-architecture 是一个用于规划实现结构的技能，属于 blockmatic/basilic-skills 技能集。它针对用户提出的问题产出实现结构方案，强调持久的系统分解决策应归属于已有的 ADR（架构决策记录）和架构文档，而不是另建一套 ADR 树或创建分支。该技能会读取匹配的架构 MDX 与 ADR，若变更涉及持久边界则停止并记录到现有 ADR/文档体系；同时区分实现目标与锦上添花项，列出约束、权衡与替代方案，标记高风险项供人工处理，并给出 3–5 条假设。仅在结构或流程不清晰时添加 Mermaid 图。保存行为取决于用户是否提供路径，否则在对话中返回结果。
w-build 是一个用于按计划增量实现任务并验证结果的技能，属于 blockmatic/basilic-skills 技能集。它适用于已有计划或足够清晰的实现请求，要求在动工前阅读仓库说明、受影响的 README 与脚本、匹配的规则与技能以及技术文档。对于有重大影响的决策，它要求从匹配文档中求解；涉及产品范围、密钥或破坏性操作时应询问人类，且不进行提交。使用时会检查工作树、识别本任务负责的文件、声明验收条件并保留无关改动。实现时使用既有包和模式完成一个完整切片，修改所属 schema 并运行文档化的生成器，而非直接编辑生成的客户端或迁移。验证方面，运行针对该改动的最小既有检查；可复现的逻辑缺陷应有回归检查；仅在要求或仓库规定时使用 TDD。失败检查应先调查再构建依赖工作，区分本次回归与既有或环境失败，绝不通过削弱检查来获得通过。若行为、命令或约定发生变化，应更新匹配的 MDX 和最近的 README，否则用一行说明原因。
w-clarify 是一个用于在需求不完整时进行澄清提问的技能，目标是从已检查的上下文中解决那些会影响正确实现的关键缺失需求。它强调只针对会阻塞正确工作的决策提问，不越出当前请求范围，不虚构产品范围。使用时会先检查代码、README 以及匹配的 MDX/ADR 文档，寻找已经存在的答案，然后列出仍然存在的关键缺口，例如行为、信任边界、破坏性操作等，并跳过可逆的细节。它要求提出最小集合的问题，当用户已经覆盖相关内容时，则基于已陈述的假设继续推进。该技能还提到相关概念：持续的设计树式访谈称为 grill，超出单次会话范围的迷雾称为 wayfinder。
w-coderabbit 是一个用于处理 CodeRabbit 代码审查评论的技能。它能够获取当前 PR 或未提交差异中的 CodeRabbit 评论，应用高置信度的修复，并在本地验证后停止。该技能通过 gh 识别分支和 PR，若无 PR 则审查当前任务差异；通过可用的 CodeRabbit MCP 获取评论，当评论跨多个文件时按文件和严重程度进行只读分组。修复从 critical/high 级别开始，遵循仓库规则，并运行与变更匹配的仓库 lint/type/w-test 命令。仅样式或不明确的条目会以列表形式保留，不自行发明安全或质量标准。若行为或命令发生变化，可参考 /w-docs 文档。该技能不会在未要求的情况下提交代码。
w-commit 是一个用于按仓库约定审查并提交任务预期改动的技能。它在收到提交请求后，会先检查已暂存与未暂存的改动以及授权任务范围，再决定暂存内容。创建新分支时要求先执行 git fetch origin，再使用 git switch -c <name> --no-track origin/main，避免基于过期的本地 main。它会区分任务自有改动与无关工作，包括预先暂存的文件；若无法安全分离预期提交，则要求澄清文件范围。暂存前，若行为、命令或约定发生变化，匹配的 MDX 与最近的 README 必须出现在 diff 中，否则需说明原因。它依赖提交钩子，不使用完整的 pre-push 套件，只暂存明确属于任务的路径或代码块，禁止使用 git add -A，禁止暂存 .env、凭据或密钥。提交信息采用 Conventional Commit 格式：小写类型/范围、不超过 60 字符的祈使句摘要、无句号，并通过 heredoc 传入，在启用钩子的情况下提交。最后检查结果与剩余工作区，返回提交 ID 和范围。单独的提交请求不授权推送。
w-council 是一个用于代码库探索的技能：先自行检查目标区域，收集架构与关键词，再按需启动少量不同视角的并行探索代理，最后汇总并核对发现。它只做调查，不提交、不推送、不创建 PR；只有在用户已明确要求时才继续实现。
w-debug 是一个用于诊断故障并验证修复的调试技能。它要求先记录预期行为与实际行为、复现条件、相关日志和近期变更，再以最小输入和仓库现有工具复现原始故障。诊断类请求保持只读，只有明确要求修复时才授权进行限定范围的实现。它帮助定位失败边界（编译器、类型、浏览器、API、数据库、依赖、环境或测试），区分观察到的事实与假设，一次只验证一个假设，并在修复后重复原始场景与受影响检查。
w-deslop 是一个用于清理代码分支中 AI 生成冗余内容的技能。它通过将当前分支与 main 分支进行差异对比，找出并移除人类开发者通常不会添加的多余注释、防御性噪音，以及与文件周围风格不一致的类型转换。该技能要求对分支修改过的每个文件（包括新增和已修改的既有文件）进行 diff，定位 AI 生成痕迹，如额外注释、在可信路径上异常出现的 try/catch、强制转换为 any，以及不符合文件整体风格的写法。清理时只移除这些冗余内容，不重写无关结构，并对受影响文件运行最小范围的现有检查。若行为或命令发生变化，还需参考 /w-docs 文档。
w-diagram 是一个用于生成 Mermaid 图表的中文技能，可根据用户指定的代码、架构或数据流，产出对应的可视化图表。它强调基于实际来源绘图，不虚构架构或文档内容；当请求涉及产品、用户旅程或架构文档时，会读取指定的 MDX/DESIGN.md，并从这些来源生成至多两张 Mermaid 图，同时标注文档与代码之间的不一致，而不提出新的方法论。除此之外，它会检查指定的代码或文档，并根据问题类型选择 flowchart、sequence、class、er、state 或 journey 等合适的图类型。输出要求标签简短、过大的图拆分为多张，并使用 mermaid 代码围栏包裹，最后用几句话解释图表展示的内容，且节点与连线必须对应检查过的来源。除非用户提供了文件路径，否则默认只在对话中输出。
w-errors 是一个用于加固代码失败路径的技能，帮助开发者为当前代码添加与仓库现有错误处理和日志包相匹配的错误处理逻辑。它要求遵循 AGENTS.md 中指定的错误处理页面以及现有的错误/日志包，并强调不要用重试掩盖真正的失败原因。该技能会识别变更路径上的失败点（如校验、I/O、授权、空值或非法输入），使用仓库既有的错误类型和日志器，返回或渲染已有的面向用户的错误模式。只有在写入可安全重放时才进行重试，否则保留显式的无重试路径，并在已有重试需求时设置有限期限。此外，它要求用测试或具名的手动场景覆盖新路径，并运行最小的现有检查；若行为或命令发生变化，则参考 /w-docs 文档。
w-fix-push 是一个用于修复已报告问题并提交推送的技能。它针对指定的问题执行“修复→最小匹配检查→提交→推送”的流程，适用于处理 lint、类型、测试或评审反馈中的错误与警告。该技能不是 /w-ship（不创建 PR，也不运行完整的推送前检查套件），也不是合并或部署操作，遵循 git publish 规范。若需新建分支，应先执行 git fetch origin，再使用 git switch -c <name> --no-track origin/main，绝不跳过 fetch，也不使用过期的本地 main。修复后运行与失败相匹配的最小现有检查，而非完整推送前套件。仅提交预期路径，然后推送已检查的上游。除非用户要求 /w-pr 或 /w-ship，否则不打开 PR。
w-git-repair 是一个用于解决常见 Git 问题的技能，帮助处理冲突、分离头指针（detached HEAD）、上游分支分叉等本地 Git 问题。它强调先检查再操作：通过 git status、git branch -vv 和相关日志确认当前状态，用一句话说明问题，然后提出最小化的安全命令并解释其影响。对于可能丢弃本地更改的命令（如 git reset --hard、git clean、git restore）要求明确确认；对于改写历史的命令（如 git rebase、对已发布提交执行 git commit --amend）要求用户明确请求。执行授权命令后会重新检查状态和剩余冲突，且从不强制推送或绕过钩子。
w-lint 是一个用于运行项目代码检查（linter）并应用最小修复的技能。它会执行仓库中记录的 lint 命令，在仓库提供自动修复时启用自动修复，捕获剩余错误，然后以最小差异（minimal diffs）修复剩余问题，并反复重新运行 lint，直到检查套件干净为止。该技能明确不是合并门禁（merge gate），也不会提交（commit）代码。它强调仅在证据表明必要时才修改抑制规则或配置，修复后需重新运行 lint 并抽查差异，但不要暂存或提交。若行为或命令发生变化，可参考 /w-docs 文档。
w-onboard 是一个面向新开发者的上手引导技能，目标是把开发者从克隆仓库带到本地应用成功运行。它依据仓库自身的脚本和文档来指导环境搭建流程：运行文档中记录的根目录安装脚本（Basilic 项目为 pnpm setup），根据 AGENTS.md 中指定的开发环境页面判断采用本地还是远程环境，启动文档中记录的 Web 与 API 开发命令（Basilic 项目为 pnpm dev），可选地按移动端 README 中的过滤命令启动移动端，最后验证应用能够加载并连通 API。当开发者准备发布工作时，会引导其转向 /w-pr；若行为或命令发生变化，则指向 /w-docs。该技能强调遵循仓库既有文档，不主动创建 PR，除非被明确要求。
w-perf 是一个用于定位和优化性能瓶颈的技能。它强调以实测基线为依据，通过仓库自带的工具（如 profiler、trace、测试或 gh 任务计时）来测量性能问题，而不是凭空估算。该技能会先读取测试文档中已有的性能预算，采集基线数据，再借助证据定位真正的热点路径（查询、渲染、内存分配等），然后推荐最小的改动方案。默认情况下仅报告问题，只有在用户明确授权时才实施修改，并在改动后重新测量以验证效果。若需要新的性能预算，应记录到现有测试文档中，而不是自行发明 SLO。
w-pr 是一个用于创建或更新可评审拉取请求（Pull Request）的技能，属于 blockmatic/basilic-skills 技能集。它的核心用途是：在确认任务相关改动已提交并通过验证后，发布目标分支并为其创建或更新 PR。该技能要求先确保改动已提交（必要时使用 commit），若需要新建分支，则必须先执行 git fetch origin，再使用 git switch -c <name> --no-track origin/main，禁止跳过 fetch，也禁止基于过期的本地 main 分支。随后使用 push 推送目标分支。PR 描述需独立撰写，包含问题、改动后的行为、验证证据和重要限制，并遵循仓库模板，不得创建空描述；若仓库有要求，需使用约定式 PR 标题。若该分支已存在 PR，应复用而非重复创建。标签和评审人只能使用已知且适用的，不得自行编造指派。使用 CLI 时，应将多行文本写入临时文件并通过 body-file 选项传入。完成后需验证标题、目标分支和描述，并返回 PR 链接。需要特别注意的是，创建 PR 并不授权合并或部署。
w-push 是一个用于安全推送 Git 分支的技能，属于 blockmatic/basilic-skills 技能集。它的核心目标是在推送当前任务分支时，保留与任务无关的工作内容，避免误提交或误推送。该技能会先审查预期差异和所需的检查结果，仅移除任务引入的临时调试代码；若任务改动需要提交，则按提交流程处理，同时保留无关的已暂存和未跟踪文件。推送时面向已检查的上游分支，若不存在则使用仓库预期的远程和当前分支，并在发布前解决歧义。对于被拒绝的推送，会检查分叉情况并使用仓库的非破坏性同步流程，明确禁止强制推送或绕过钩子。除非被要求，否则不会创建 PR、部署或启动 CI 监控。
w-refactor 是一个用于重构所选代码的技能，核心目标是在保持行为不变的前提下改进代码结构，并在修改后进行验证。使用时可针对选中的文件或指定的关注点进行重构。编辑前需通过测试、类型检查或手动场景捕获当前行为，建立基线，明确调用方依赖、验证手段以及不可改变的部分。重构以最小有效差异改进结构，包括提取重复代码、澄清命名、减少嵌套，并复用已有包，不添加复述代码的注释。只有在仓库的 profiler、测试或 trace 提供可测量证据时，才更改算法或数据结构。修改后运行基线中受影响的检查，若失败则恢复行为，不运行完整的 pre-push 套件。若行为或命令发生变化，可参考 /w-docs 文档。该技能不授权 commit、push 或 PR。
w-review 是一个只读的代码变更审查技能，用于在不修改代码的前提下，针对指定的 diff、分支、PR 或工作区，结合其预期行为，找出有证据支撑的缺陷与风险。它要求先理解触发条件与预期结果，再判断实现是否合理，并通过阅读测试了解哪些断言真正被执行。审查覆盖范围内的多个维度（行为变更时包括文档/README），可派生 2–3 个只读探索者分工检查，重点关注变更行为、调用方与失败路径，并明确说明哪些维度不在范围内。对疑似缺陷需用具体执行路径、失败用例或源码证据加以验证，不得凭外观臆测时序或漏洞。发现按影响排序，附文件/行号、触发条件、后果与最小有效修复建议。该技能强调审查不等于测试通过的证明，也不构成合并批准。
w-roadmap 是一个用于将代码库与 GitHub issues 及对应文档进行差异比对的技能，目的是核对实现进度，而不是凭空编造待办清单。它读取 GitHub 上的开放与近期关闭的 issue，以及匹配的 MDX、README、DESIGN.md 中提到的阶段性目标，再检查对应代码，标注哪些已交付、部分完成或缺失，每一项都需引用 issue、MDX 或代码作为依据。该技能仅在对话中进行，不会创建 PRODUCT.md、ROADMAP.md 或第二份待办清单。若本轮没有已梳理的探索，会按 council 步骤 1–3 从 issue、匹配文档和代码三个角度展开。最后会询问用户是希望编辑文档，还是对已获授权的条目使用 /w-plan。
w-ship 是一个用于把代码改动从实现一路推进到 PR 的技能。它接收任务或计划后，读取仓库说明、分支状态、相关文档与脚本，按 git-publish 分支规则创建分支，完成实现并同步更新文档，运行仓库完整的推送前质量门禁，提交并推送改动，最后创建或更新 PR，返回提交、分支、PR 链接与检查结果。它不负责合并或部署，也不等同于仅提交的 /w-commit。
w-v0 是一个用于从当前文件生成 v0.dev 提示词的技能。它会结合当前文件、选中内容和项目技术栈，起草一份面向 Next.js 与 shadcn 的简洁提示词，内容涵盖 App Router、TypeScript、Tailwind、shadcn、默认使用服务端组件、可访问的 HTML、移动优先，以及不包含密钥或仓库内部路径。生成后先展示提示词，并等待用户回复 OPEN、EDIT: 或 CANCEL。回复 EDIT: 时进行修改并再次等待；回复 CANCEL 时停止；回复 OPEN 时对提示词进行 URL 编码并打开 https://w-v0.dev?chat={prompt}，且仅回复 v0 已打开，不输出包含完整提示词的 URL。若行为或命令有变化，可查阅 /w-docs。
w-yolo 是一个用于修复本地检查失败的技能，强调在不发布代码的前提下处理问题。它要求使用最小失败命令或用户指定的命令进行修复，禁止运行完整的 pre-push 套件，禁止编辑 .env，禁止删除功能来让检查通过。修复后需重新运行失败命令，并可选用 /w-review 只读审查任务差异。若存在 CodeRabbit 或 CI 评论且用户要求处理，则按 /w-coderabbit 或 /w-comments 执行但不提交。行为或命令变更时参考 /w-docs。