improve-codebase-architecture
该技能用于扫描代码库中的架构改进机会：找出可被"深化"的浅层模块，将其以可视化 HTML 报告形式呈现，再由用户选择其一后通过提问式流程逐步推演重构决策。目标是提升可测试性与 AI 可导航性。它基于项目领域模型与共享的架构词汇（模块、接口、深度、接缝、适配器、杠杆、局部性），并在报告中为每个候选方案提供涉及文件、问题、方案、收益、前后对比图与推荐强度，最后给出首选建议。
Skill 广场
找到适合任务的 Agent Skill，阅读介绍并复制安装命令。
更新于 10-14 00:01
编程与开发
4,828 个结果
setup-matt-pocock-skills
setup-matt-pocock-skills 是 Matt Pocock 技能集合中的初始化技能，用于为一个仓库搭建工程类技能所依赖的配置。它会探索仓库当前状态，然后引导用户确认三部分配置：issue 跟踪器位置（默认 GitHub，也支持 GitLab 和本地 markdown 文件）、triage 标签词汇（五个标准角色的标签字符串）以及领域文档布局（GLOSSARY.md 与 ADR 的存放位置及读取规则）。该技能是提示驱动的，并非确定性脚本：先探索、展示发现、与用户确认，再写入文件。运行一次后，相关工程技能即可从这些配置文件中读取信息。
prototype
Prototype 是一个用于构建一次性原型（throwaway prototype）的技能，目的是回答某个设计问题。它强调原型的形态由要回答的问题决定：如果问题是“这套逻辑或状态模型是否合理”，就构建一个单一的、可分享的 HTML 文件，包含自由操作按钮和分标签的引导式走查，把状态机推进到难以纸上推理的场景，并让非开发者也能上手操作；如果问题是“这个界面应该长什么样”，就在单个路由上生成多个差异显著的 UI 变体，通过 URL 搜索参数和底部悬浮栏切换。该技能要求原型从第一天起就明确标记为一次性代码，放置在真正会用到它的模块或页面附近，但命名上让普通读者一眼看出不是生产代码；运行要极其简单；默认不做持久化；跳过打磨；每次操作或变体切换后展示完整相关状态；完成后把已验证的决策并入真实代码，并把原型本身提交到一次性分支作为一手来源。
codebase-design
codebase-design 是一套关于“设计深模块（deep modules）”的共享词汇与设计原则，来自 mattpocock/skills。它主张把大量行为藏在一个小接口之后，并把接口放在干净的接缝（seam）上，从而可以完全通过该接口进行测试。其目标是：为调用方带来杠杆（leverage），为维护者带来局部性（locality），并为所有人带来可测试性。该方法给出了一组需要严格使用的术语（Module、Interface、Implementation、Depth、Seam、Adapter、Leverage、Locality），并规定不要用“component”“service”“API”“boundary”等词替代。它包含深模块与浅模块的对比示意、设计接口时的自问清单、若干原则（如删除测试、接口即测试面、一个适配器只意味着假想接缝、两个适配器才意味着真实接缝），以及面向可测试性的设计建议（接受依赖而非创建依赖、返回结果而非产生副作用、缩小接口面积）。资料还提到 DEEPENING.md 和 DESIGN-IT-TWICE.md 两份进阶文档，分别涉及加深模块簇的依赖处理与替代接口探索。
lark-skill-maker
lark-skill-maker 是一个用于创建新 Skill 的工具型技能，基于 lark-cli 命令行为飞书开放平台能力编写 Skill。其核心理念是：一个 Skill 就是一份 SKILL.md 文件，用于教会 AI 通过 CLI 命令完成特定任务。该技能提供 CLI 核心能力说明，梳理了三种调用方式的优先级（Shortcut > 已注册 API > api 裸调），并给出调研 API、确定参数与权限范围（scope）的流程。当 CLI 没有对应的已注册 API 或 Shortcut 时，可借助 lark-openapi-explorer 从飞书官方文档库逐层挖掘原生 OpenAPI 接口，再通过 lark-cli api 裸调完成。工具还提供 SKILL.md 模板，包含 frontmatter 元数据（name、version、description、requires.bins）以及命令、权限表格等结构，并强调 description 决定触发时机、认证需说明 scope、写入操作前确认用户意图并建议使用 --dry-run 预览、多步编排需说明数据传递与失败回滚等关键原则。
code-review
code-review 是一个面向代码变更的审查技能，来自 mattpocock/skills。它对 HEAD 与用户指定的固定点（提交、分支、标签或 merge-base）之间的 diff 进行双轴审查：Standards 轴判断代码是否符合该仓库文档化的编码规范，Spec 轴判断代码是否忠实实现了来源 issue/规格说明。两个轴以并行子智能体方式运行，避免互相污染上下文，最后由该技能汇总两边结论。使用前需要用户提供固定点，并建议已配置 issue 追踪器；如未配置，需运行 /setup-matt-pocock-skills。技能本身仅定义审查流程与提示，不改变代码内容。
git-guardrails-claude-code
git-guardrails-claude-code 是一个用于 Claude Code 的技能，通过配置 PreToolUse 钩子（hook）在执行前拦截并阻止危险的 git 命令。被阻止的命令包括 git push（含 --force 等所有变体）、git reset --hard、git clean -f / git clean -fd、git branch -D、git checkout . 与 git restore .。当命令被拦截时，Claude 会收到提示，告知其没有权限访问这些命令。该技能会引导用户选择生效范围（仅当前项目或所有项目），复制随附的钩子脚本 scripts/block-dangerous-git.sh 到对应位置并赋予可执行权限，然后把钩子配置合并进相应 settings.json 的 hooks.PreToolUse 数组，而不会覆盖其它已有设置。之后会询问是否需要增删拦截规则，并通过管道回显一条 git push 命令进行验证，预期以退出码 2 结束并向 stderr 输出 BLOCKED 信息。
lark-openapi-explorer
飞书/Lark 原生 OpenAPI 探索技能，用于从飞书官方 markdown 文档库中逐层挖掘未经 CLI 封装的原生 OpenAPI 接口。当现有 lark-* skill 或 lark-cli 已注册命令无法满足用户需求时，通过本技能检索官方文档定位接口，并用 lark-cli api 裸调完成调用。流程包括：确认现有能力不足、从顶层索引定位模块、从模块文档定位具体 API、获取完整规范、通过 CLI 调用。使用前需先了解认证、身份切换和安全规则。
repo-intake-and-plan
repo-intake-and-plan 是一个面向“README 优先”的深度学习仓库复现场景的 Rigor Intake 辅助技能。它用于在复现工作开始阶段对目标仓库进行扫描与规划：读取 README 及常见项目文件，梳理仓库结构，盘点文档中记录的命令，并将命令候选保守地归类为推理、评估、训练或其他类别。该技能还会给出最小可信复现建议以及需要注意的歧义或风险清单。它本身只做扫描与规划，不安装环境、不准备大型资产、不执行实质性复现命令，也不决定高风险修补，通常由编排器（orchestrator）调用。输入需要目标仓库路径，以及 README 等常见项目文件的可访问权限，可选地接受用户关于优先级（例如推理优先）的提示。其输出包括简洁的仓库结构摘要、文档化命令清单、推断的候选类别、最小可信复现建议和明显歧义或风险列表。适用于 README 优先复现工作的起点、需要快速获取仓库结构与命令映射、需要保守分类推理/评估/训练候选，或用户希望先只检查仓库而不运行任何内容的情况；不适用于执行已开始、非仓库复现任务、只解读论文而不检查仓库，或用户已选定命令只需搭建或执行的场景。
prisma-client-api
中文介绍正在整理，稍后补充。
prisma-cli
Prisma ORM 7 CLI 命令参考技能，面向已使用 Prisma 7 的应用或明确选用 Prisma 7 工作流的场景。内容覆盖 prisma init、generate、migrate、db、dev、studio、validate、format、debug、complete、mcp 等命令，并按设置、生成、开发、数据库、迁移、工具等类别划分优先级。技能强调使用与项目版本匹配的 CLI，不要安装浮动的 prisma@latest；并区分稳定版 ORM 命令 prisma 与公测版平台包 @prisma/cli。还包含 AI 安全机制说明：当检测到 AI 代理时，破坏性命令（如 migrate reset、db push --force-reset、db push --accept-data-loss）会被阻塞，需用户明确同意。
prisma-driver-adapter-implementation
中文介绍正在整理，稍后补充。
safe-debug
safe-debug 是面向深度学习研究工作的 Rigor Debug / Rigor Audit 技能，安装后的 slug 仍保持为 safe-debug 以兼容。它用于处理用户粘贴的 traceback、终端报错、CUDA OOM、checkpoint 加载失败、shape 不匹配等具体训练或推理失败症状，目标是先诊断再改动。该技能会遵循共享的操作原则，引导进行保守诊断，同时不阻碍模型定位局部根因。默认情况下不修改仓库代码；如果确实需要补丁，会提出最小修复方案并要求先获得明确的人工批准。对于中风险或高风险改动，会先升级为 savepoint 或分支创建。它明确指出调试修复并不自动等同于研究贡献，如果修复改变了实验含义或可比性，会予以说明。输出方面，预期生成 debug_outputs/DIAGNOSIS.md、debug_outputs/PATCH_PLAN.md 和 debug_outputs/status.json。适用于用户希望在代码被修改之前先进行诊断、缩小根因范围并获得最小补丁建议的场景，不适用于没有活跃故障的宽泛仓库讲解、推测性实验或代码适配、以及大规模重构或可读性重写。
systematic-debugging
系统化调试（Systematic Debugging）是一套用于处理缺陷、测试失败和异常行为的结构化调试方法论。其核心原则是：在提出任何修复方案之前，必须先找到根本原因，仅修复症状被视为失败。该技能适用于任何技术问题，包括测试失败、生产环境缺陷、意外行为、性能问题、构建失败和集成问题，尤其在时间紧迫、看似只需“快速修复”、已尝试多次修复但无效、或不完全理解问题时更应使用。流程分为四个必须依次完成的阶段：根本原因调查（仔细阅读错误信息、稳定复现、检查近期变更、在多组件系统中收集证据、追踪数据流）、模式分析（寻找可工作的示例、与参考实现对比、识别差异、理解依赖）、假设与测试（提出单一假设、最小化测试、验证后再继续）以及实施（创建失败测试用例、实施单一修复、验证修复）。该技能还提供红旗信号清单、常见借口与现实的对照表，以及配套技术文档，如通过调用栈向后追踪根本原因、在多层添加验证的纵深防御、用条件轮询替代固定超时等。
requesting-code-review
这是一个用于在完成任务、实现重大功能或合并代码前请求代码审查的技能。它通过派发独立的代码审查子代理来发现潜在问题，避免问题层层累积。审查者获得的是精心构造的上下文，而非整个会话历史，因此能专注于工作成果本身。核心原则是尽早审查、频繁审查。适用时机包括：子代理驱动开发中每完成一个任务后、完成重大功能后、合并到主分支前；也可在遇到困难、重构前或修复复杂 bug 后使用。使用方式为获取 git SHA 后派发通用子代理并填写模板，根据反馈修复问题。
subagent-driven-development
“subagent-driven-development”（子智能体驱动的开发）是一套用于在当前会话中执行实施计划的技能工作流。它适用于计划中的任务基本相互独立的情况：为每个任务分派一个全新的实施子智能体，任务完成后进行规格符合性与代码质量审查，全部任务结束后再做一次覆盖整个分支的广泛审查。其核心理念是“每个任务用全新子智能体 + 任务级审查（规格+质量）+ 最终广义审查 = 高质量、快速迭代”。工作流强调连续执行：不在任务之间暂停询问用户，而是持续执行计划中的全部任务；只在下述四类情形停止——不可逆或破坏性操作、安全敏感操作、工作区之外需要事先征询的副作用（如合并、推送到共享分支、发布）、以及计划彻底损坏以致任何前进路径都只能靠猜测。每个计划拥有独立的工作区，进度记录在 ledger 文件中，以抵御上下文压缩带来的记忆丢失。
receiving-code-review
这是一个处理代码评审反馈的技能，强调在实施建议前先进行技术验证，而不是情绪化附和。它要求接收反馈时完整阅读、用自己的话复述需求、对照代码库实际情况核实、判断技术合理性，再逐条实现并测试。适用于收到代码评审意见的场景，尤其是反馈不清晰或技术上存在疑问时，帮助开发者用技术理由而非社交客套来回应评审。
finishing-a-development-branch
中文介绍正在整理，稍后补充。
request-refactor-plan
该技能用于为代码重构制定详细计划：通过访谈用户明确问题与解决方案，探索仓库验证现状，确定实现范围与测试覆盖情况，将实现拆解为尽可能小的提交步骤，最终以 GitHub issue 形式记录重构计划。issue 内容包含问题陈述、解决方案、提交计划、决策文档、测试决策和范围外说明等部分。
convex-quickstart
从一句话想法快速搭建一个最简的 Convex + Web 模板并在本地运行。该技能会创建项目、安装依赖、启动后端（匿名开发部署）和 Web 开发服务器，并输出可访问的开发 URL。它强调模板保持最小化——本地开发服务器、无发布步骤、无预置鉴权，不使用 Postgres/Redis/Express，而是采用 Convex 原语。适用于需要快速验证想法、生成可运行的 Convex 后端与前端骨架的场景；也可在无法运行脚手架的降级场景下，改为直接编写标准 Convex 项目代码。
xcode-project-setup
该技能用于安全地修改 Xcode 项目（.pbxproj），以添加 Swift Packages 并链接文件，适用于 iOS 项目需要安装依赖的场景。它通过随附的原生 Swift 脚本（scripts/xcode_spm_setup）完成包依赖注入与模块到主目标的链接，并支持在添加 Firebase 产品时自动向 OTHER_LDFLAGS 注入 -ObjC 标记，以避免静态链接导致运行时崩溃。技能明确禁止使用 Ruby、Rails 或 xcodeproj gem 及相关脚本，要求优先利用现代 Xcode 的文件夹同步机制添加源文件与资源，不得手动修改 .pbxproj 添加文件；若确需脚本操作，必须使用 Swift，仅在 Swift 完全不可行时才可用 Node.js 或 TypeScript。使用前需运行 swift --version 校验工具链，未安装时须停止并建议用户安装。若目录中不存在 .xcodeproj 或 .xcworkspace，须先让用户在 Xcode 中创建空项目。使用 Firebase SDK 时应查阅官方 releases 页面选用最新版本。脚本为幂等操作，会自动跳过已存在的链接。
browser-use
中文介绍正在整理，稍后补充。
review-loop
review-loop 是一个迭代式“工作者—评审者”循环技能，核心思路是在单次会话内先完成工作，再生成一个评审子代理对成果进行 1-10 分打分并给出可执行的修改反馈，然后根据反馈修改，反复循环直到满足质量门槛。其基本理念是：初稿永远不是终稿，迭代式批判能比单次成稿产出更好的结果。该技能默认最少循环 2 次、最多 4 次，质量门槛为 8/10；评审者能力必须等于或高于工作者，以避免无法识别复杂逻辑问题。它适用于代码实现、设计文档、技术写作、需要更稳健的复杂实现等场景，也支持“仅评审已有成果”的模式。使用时可自然语言指定质量门槛、循环次数和评审模型。该技能依赖支持子代理生成的平台，否则需通过新开会话并仅粘贴工作成果来模拟评审。资料未提供收费与价格信息。
convex-performance-audit
这是一个面向 Convex 应用性能审计的 Agent 技能，主要用于诊断和修复 Convex 应用中的性能问题。它按问题类别逐项处理，关注的信号包括高读写字节数、文档读取量、OCC 冲突、订阅数量过多、UI 更新缓慢、函数执行或事务接近上限等。技能强调先收集信号（如部署 Health insights、npx convex insights --details、convex-doctor 提示），再根据信号路由到对应参考文件，包括热路径规则、OCC 冲突、订阅成本、函数预算等。使用时不建议在小规模、低流量或信号不足的场景下过度优化，也不应在无测量信号时推荐摘要表、文档拆分或迁移型改造。工作流涵盖问题范围界定、完整读写路径追踪、应用修复、同步修复同类兄弟函数，以及完成前的验证。它适合处理慢功能、insights 发现、OCC 冲突或读放大等问题，不适合初始搭建、纯模式迁移或无用户可见问题的微优化。