find-skills
帮助用户发现并安装代理技能，通过技能市场搜索、验证并安装技能。
适合用户询问如何完成某任务时寻找现成技能
SKILL 分类
Agent 工作流
规划、调试、并行子代理、浏览器自动化和自主循环相关元技能。
- Skill
- 10
- 主要指标
- 安装量
按榜单顺序
Agent 工作流 Skills
10 个结果
agent-browser
agent-browser 是一个面向 AI 代理的快速浏览器自动化 CLI，基于 Chrome/Chromium CDP，提供无障碍树快照和元素引用。支持导航、点击、填表、截图、数据提取，并针对 Electron 桌面应用、Slack、探索性测试、Vercel Sandbox 微 VM 和 AWS Bedrock AgentCore 等场景提供专门技能。
适合需要与网站交互的自动化任务，如导航、点击、填表、截图、数据提取
skill-creator
skill-creator 是一个用于创建、测试、改进和发布新技能的技能。它提供了一套完整的工作流，包括捕获意图、编写 SKILL.md、创建测试用例、运行评估、迭代优化，以及优化技能描述以提高触发准确率。
适合从零创建新技能
brainstorming
来自 obra/superpowers 的 brainstorming skill，用于在任何创造性工作（新功能、组件、功能修改）之前，通过人机协作对话把想法转化为完整设计与规格。核心机制是先对请求分类为三条路径之一——Spike（可行性验证，产出结论而非保留代码）、Bounded（针对仓库中已有代码的小范围改动，在对话中给出简短设计）、Architectural（新项目或子系统，走完整流程）；若存疑则取更重路径，任务中途发现隐藏复杂度只能升级、不可降级。它要求用一句话写下对意图、约束与成功标准的理解供人纠正，一次只问一个重要问题，架构路径需提出 2-3 种方案、分段呈现设计、写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交、做占位符/一致性/范围/歧义自查，再经用户审阅后调用 writing-plans skill 生成实施计划。skill 内含 HARD-GATE：任何实现动作前必须获得对应阶段的明确批准，并强调“太简单不需要设计”是反模式。还提供可选的可视化伴侣：仅在确实出现图示比文字更清楚的问题时才单独发消息提议，获批后用浏览器标签页展示原型与图表。
适合在开发新功能、构建组件或修改既有行为之前，先澄清用户意图、需求与成功标准
systematic-debugging
系统化调试技能，遵循‘无根因调查不修复’的铁律，通过四阶段流程（根因调查、模式分析、假设测试、实施）定位并修复问题，强调避免症状修补。
适合修复测试失败
writing-plans
obra/superpowers 中的 writing-plans 技能，用于在动手写代码之前，为多步骤任务编写结构化的实施计划。计划面向一位没见过该代码库、也没读过规格说明的工程师：假定对方掌握项目语言并会写出符合习惯的代码，凡是其无法自行得知的决策——涉及哪些文件、命名与签名、规格中的哪些取值、由哪些测试证明每个任务——都要在计划中写明。计划以可勾选的小任务形式交付，遵循 DRY、YAGNI、TDD 与频繁提交。内容涵盖：范围检查（若规格横跨多个独立子系统则建议拆分为多份计划）；文件结构规划（按职责而非技术分层拆分，每个文件单一职责）；任务粒度（任务是最小自带测试周期、值得独立评审的单位）；步骤粒度（每个步骤只做一个动作并可检验，如写失败测试、运行确认失败、实现最小代码、运行确认通过、提交）；计划文档的固定头部（Goal、Architecture、Tech Stack、Spec 路径、Global Constraints、Review Focus）；随后是对照规格的自审清单（规格覆盖、步骤扫描、类型一致性、Review Focus、篇幅比例）；最后是执行交接，要求人类先评审计划，并在未指定执行方式时选择子代理驱动或原生执行。计划默认保存到 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md。
适合已有规格说明或需求，需要把它拆成一份可逐任务执行的多步骤实施计划
requesting-code-review
来自 obra/superpowers 的技能，用于在完成任务、实现主要功能或合并前请求代码审查。它要求先取 git SHA（如 BASE_SHA=$(git rev-parse HEAD~1) 或 git merge-base origin/main HEAD，HEAD_SHA=$(git rev-parse HEAD)），再派发一个 general-purpose 审查子代理，并填写 code-reviewer.md 模板，提供 DESCRIPTION、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA 四个占位符信息，只给审查者精确构造的上下文，不给整个会话历史。技能列出必须审查的时机（子代理驱动开发中每个任务后、完成主要功能后、合并到 main 前）与可选时机（卡住时、重构前、修复复杂 bug 后），并规定对反馈的处理方式（Critical 立即修、Important 继续前修、Minor 记录、可基于技术理由反驳），另附常见借口对照表与红旗清单。
适合子代理驱动开发中，每完成一个任务后请求审查
test-driven-development
一套强制纪律的测试驱动开发（TDD）工作流技能：先写一个最小失败测试（RED），必须亲眼看到它以预期原因失败，再写刚好通过测试的最简代码（GREEN），并运行整个项目测试套件确认全绿，最后在保持绿灯的前提下重构（REFACTOR），循环重复。核心铁律是“没有失败测试，就不写生产代码”，先写实现再补测试被视为需删除代码重来；同时列出常见合理化借口、红旗信号、验证清单，以及测试难以编写时的设计排错建议。适用于新功能、Bug 修复、重构与行为变更，一次性原型、生成代码、配置文件等例外需征得人类搭档同意。
适合Agent 实现新功能时，需要先写失败测试再写实现
executing-plans
executing-plans 是 obra/superpowers 中的 Agent 工作流技能，用于在当前会话中由执行者本人逐步执行一份实现计划：不为每个任务派发实现子代理和评审子代理，只在最后对整条分支做一次全新上下文评审。它的核心原则是“计划已经完成了思考”——严格按计划执行，用先看到失败、再看到通过的测试证明每一步，并留下能抵御自身遗忘的记录。做法包括：在隔离 worktree 中建立每个计划专属的 workspace 与 ledger（进度账本，首行标识计划文件），读取计划与 spec，做 pre-flight 扫描检查任务间共享接口的冲突；随后逐任务循环，用 scripts/task-start 取 brief 与 BASE、按计划既有的 RED-GREEN 顺序执行每步并与 Expected 行比对真实输出，代码出错走 systematic-debugging，计划出错则作出 ruling 并记账，按计划提交，满足完成契约后用 scripts/task-done 跑测试并仅在通过时写入完成行。全部任务完成后生成 review-package 并派发一次整分支评审（无子代理工具时由作者自评审并声明其较弱），Critical/Important 发现只做一次修复（每个修复需测试 RED→GREEN 且全套件通过），Minor 记入 ledger 并在最终消息中上报；最后删除该计划的 workspace 并交由 finishing-a-development-branch。
适合已通过 superpowers:writing-plans 得到实现计划，且 human partner 在交接时选择内联执行
subagent-driven-development
这是一个面向会话内执行实施计划的 Agent 工作流技能：为计划中的每个任务派发一个全新的实施者子代理（拥有隔离上下文），每个任务完成后派发任务审查（规格符合性 + 代码质量），最后对整个分支做一次广义终审。核心原则是「每任务新子代理 + 任务审查 + 最终广度审查」，以在保持控制器上下文干净的同时实现高质量、快速迭代。技能强调：用 ledger 文件（workspace 内 progress.md）记录进度以抵抗上下文压缩；派发前记录 BASE commit 并用脚本生成任务简报、审查包与工作区；实施者只有四种状态（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）；审查发现问题进入修复循环，最多 5 轮，第 1-3 轮恢复原实施者，第 4-5 轮换更强模型的新实施者，触顶后逐条裁定并记账；只有四类情况才停下询问人类（不可逆/破坏性操作、安全敏感动作、工作树之外的副作用如合并推送发布、计划破碎到每一条路都是猜测）。除这些之外不中断执行、不做进度汇报式确认，冲突与歧义由控制器裁定并写入 ledger。
适合在当前会话中按已写好的实施计划逐任务落地，且任务之间大体独立