re-structure-analysis
用于逆向工程第一阶段的代码库结构分析技能：在指定范围内识别入口点、依赖、模块与组件，并生成带 file:line 可追溯性的结构图与 manifest.json，供后续阶段串联使用。
Skill 广场
找到适合任务的 Agent Skill，阅读介绍并复制安装命令。
更新于 11-05 00:16
编程与开发
39,560 个结果
pr
该技能用于为 GitHub 仓库创建带结构化摘要的拉取请求（PR）。它会先检查并提交未提交的改动，对比基线分支梳理分支上的全部提交与差异，推送当前分支，再通过 gh pr create --draft 生成草稿 PR。标题简短并沿用 feat、fix 等提交前缀，用户可通过参数指定标题；正文包含 Summary 要点列表与 Test plan 验证清单，并支持用 Closes #编号 关联关闭工单。适合需要规范提交、推送并开 PR 的开发协作场景。
architect
architect 是一个面向代码库架构设计的智能体技能，用于在写实现前先做接口与模块设计的草图。它以调用方用法为起点，先梳理新代码会触及的每个系统，形成真实的架构理解；再用多个候选方案并行对比，合成一份设计包；随后按这份草图填充实现，并在架构确实不成立时果断废弃重来。整个过程强调只读调查与文档漂移的报告、设计空间穷举、优先用更小的公共接口隐藏复杂度，以及把与草图的偏差当作信号而非默默吸收。
how
how 是一个用于代码库探索与架构讲解的智能体技能，主要回答“X 是如何工作的”这类问题。它面向 Pstack 代码走查、子系统行为分析，以及模块位置与归属问题。该技能通过 /domain-modeling 解析并读取调用项目已配置的产物；只读调查与评审会报告文档漂移而不做修改，创建或实现则通过对应负责人协调已接受的模型变更。使用时，它会评估问题复杂度：简单问题（单个模块、小型工具、如“函数 X 如何工作”的窄问题）不派探索者，直接生成一个讲解者，在一次遍历中完成探索与讲解；复杂问题（跨多文件或服务的子系统、横切特性、完整架构概览）则先拆解为 2 到 4 个角度，并行派出只读探索者，收集源码指针、运行时流程与缺口后，再由一个讲解者综合所有发现。每个探索者与讲解者都通过 /swarm 运行且为只读；若无委派能力，则按相同顺序串行执行并予以说明。最终输出按讲解者提示定义的章节呈现：Overview、Key Concepts、How It Works、Where Things Live、Gotchas，不适用的章节可省略，仅做轻微编辑，不进行大幅改写。目标是让读者能够追踪子系统，并区分当前行为与设计理由（后者属于 /why）。
interrogate
Interrogate 是一个用于 Pstack 对抗性审查的技能，旨在尝试破坏具体的代码差异（diff）或有争议的设计，并且只保留能够通过实际运行证明的发现。它通过调用 /domain-modeling 读取项目配置的产物，以只读方式调查和审查文档漂移，不进行编辑。该技能会明确审查范围和意图，然后通过 /arena 和 /swarm 机制派出多个对抗者（adversaries），每个对抗者在独立的工作树中运行命令，尝试用失败测试、复现脚本或命令输出证明发现的问题。所有发现都需要经过重新运行验证，只有输出显示失败且该失败破坏了意图的发现才会被保留，共享根因的发现会被合并。最终输出包括意图重述、已验证的发现（含命令、输出、如何破坏意图及发现者）以及被丢弃的发现统计。该技能不应用修复，仅报告发现。
no-comments
no-comments 是一个面向代码注释审查的智能体技能，用于处理 Pstack 注释审查、不必要的叙述性注释，以及掩盖代码问题的抑制性注释。它通过 /swarm 生成名为 Comment Sicko 的子智能体，对调用者指定的文件或 diff（默认与 main 分支对比，含工作区）进行审查，并依据仓库文档化的注释约定执行。该技能会检查报告与 diff，拒绝应用代码修改、范围越界、受异常保护的删除、错误陈述的 MUST KILL 理由，以及对有意保留代码的错误标记；对遗漏的作用域内 lint 和 TypeScript 抑制进行审计，正确性或安全性抑制保持为可执行的 MUST KILL。它直接修复简单的已接受标记（如删除死路径、去掉参数、使用真实 API），必要时运行 /architect 生成一次草图，然后实施最小根因修复并移除所有具名变通方案。对于约束性注释，提供最廉价的作用域内类型、运行时、测试或 CI lint 方案，等待交互式批准后编码并删除，否则删除并报告约束未解决。最终报告删除数量、恢复的注释、重跑、架构草图、修复、编码提议、编码、未强制约束及其他未完成工作。
principle-boundary-discipline
该技能是一套关于系统边界纪律的工程原则，用于指导验证、错误处理与框架适配代码的编写。核心主张是把校验、类型收窄和错误处理集中在系统边界（CLI 参数、配置文件、外部 API、网络协议），系统内部则无条件信任类型化数据，不再重复校验。业务逻辑应写成不依赖框架的纯函数，外壳保持薄而机械。适用于配置解析、数据解析、提示词构造、评分评估等场景，帮助减少冗余校验、提升可测试性。
principle-fix-root-causes
这是一个用于调试场景的智能体技能，核心原则是修复根因而非症状。它要求把每个症状追溯到系统第一次出错的位置并在那里修复，强调先复现、逐步追问“为什么”、用实际错误和状态而非猜测来定位问题，并判断触发症状的状态是否合法。技能还提醒警惕守卫、重试、吞掉错误、截断数值、丢弃状态等隐藏缺陷的常见手段，关注重启后才出现的持久化状态问题，按模式而非个例排查并修复所有同类缺陷，避免用冗长注释为变通方案辩护。
principle-foundational-thinking
这是一个名为「principle-foundational-thinking」（基础性思考原则）的智能体技能，用于在编写逻辑之前先做结构性决策。它强调数据结构优先：先确定数据形态、尽早定义核心类型、追踪所有访问模式，并选择与主要路径匹配的结构。在代码层面主张对结构而非每一行做 DRY，类型与数据模型应收敛，宁可保留三行相似语句也不要过早抽象，偏好显式而非取巧，测试行为与边界情况而非行数。它还给出并发推论：在多个执行者共享状态前，先问「若另一个执行者并发修改它会怎样」，若答案不是「什么都不会发生」就应隔离。此外提出脚手架优先：若某件事对后续每个阶段都有帮助就先做，CI、lint、测试基础设施和共享类型属于脚手架，排序以保留选择价值为原则，先搭建再开发功能、先测试再修复，提交保持小而单一用途。每个增量应落地一个连贯抽象或深化已有抽象，不要把新能力以特例协调方式散落到各调用方。减法先于脚手架：先删除死代码，再打地基。涉及模块/接口推理时可调用 /codebase-design，涉及项目术语、关系或归属变更时可调用 /domain-modeling 并同步项目权威产物。
principle-laziness-protocol
这是一个面向代码重构与变更评估的代理技能，核心是“懒惰协议”：在重构、评估 diff 规模，或想要新增抽象、分层、信号传递时应用。它主张偏向删除代码，只做解决问题所需的最小改动，把重复决策收敛到单一事实来源，并以简单标志传递结果，减少样板代码。
principle-make-operations-idempotent
该技能是一项设计原则，用于指导命令、生命周期步骤和处理循环的幂等性设计。它要求每个会改变状态的操作都能在崩溃、重启和重试后收敛到同一最终状态，核心方法是：从当前实际状态推导每一步，而非依赖上一次运行的意图；读取当前状态、与目标比较、只应用差异。运行留下的锁、临时文件、半写入记录或已认领任务，必须能被下一次运行识别为过期，且过期判断应基于在上一次运行可能停止的任何位置都成立的证据。技能提供三个自检问题：连续运行两次会怎样、上一次在每个可能点崩溃会怎样、重新执行是否收敛到同一最终状态；若答案取决于遗留状态，则需要增加对账步骤。
principle-migrate-callers-then-delete-legacy-apis
该技能用于在 API 或数据模式替换旧契约时选择迁移策略：是协调所有调用方一次性迁移并删除旧接口，还是为真实兼容性义务采用分阶段共存（expand-contract）。它要求先清点所有调用方与兼容性义务，包括外部消费者、独立部署版本、存储数据和发布回滚要求；仅在存在真实兼容义务或需要独立绿色发布时才使用共存，并为每个临时适配器设定移除条件和负责工单。适用于内部调用方协调变更、需要明确验证边界和最终集成单元的场景。
principle-minimize-reader-load
“Minimize Reader Load”（最小化读者负担）是一条面向代码审查与代码设计的技能原则，核心观点是：可维护性等于读者理解代码所需付出的工作量。它提出用两个独立维度衡量代码理解成本：需要追踪的层数（问题与答案之间的间接层级）和需要记住的状态（隐藏或可变的上下文）。该原则主张折叠只有一个调用者的包装器、没有第二种实现的适配器以及从未被需要的推测性间接层；要求相邻层必须改变抽象，否则就是纯传递层；强调接口压缩、缩小状态作用域（纯函数优先于修改、局部变量优先于字段、字段优先于模块状态、模块状态优先于全局变量）、用派生代替同步，并在边界处命名不变量。最终检验标准是：新读者能否在 30 秒内回答“X 从哪来”和“什么能改变 X”。
principle-model-the-domain
这是一条面向编码智能体的技能原则，用于在编写有状态逻辑、代码分支过多或跨文件重复同一形状假设时，把真实领域建模为数据结构，而不是把领域规则散落在条件判断中。它建议优先采用状态机、类型化模型、映射/注册表/查找表、可辨识联合、reducer 或命令/事件模型、围绕单一领域知识组织的模块、聚合重复行为与不变量的模块边界，以及队列、缓存、索引、图、树或规范化集合等结构。核心目标是让非法状态不可表示、删除分支、消除重复规则与生命周期风险。同时强调不要强行抽象：若现有形状已清晰、局部且不太可能增长，宁可保留朴素代码；对只增加间接层却不减少分支、重复规则、非法状态或生命周期风险的抽象保持怀疑。该技能还提供 /domain-modeling 调用，用于梳理项目术语、领域关系、不变量与归属，并据此统一项目中的规范产物。
principle-outcome-oriented-execution
该技能名为「结果导向执行」（Outcome-Oriented Execution），用于计划内的重写与迁移场景。其核心主张是：应针对可验证的最终目标状态进行优化，而不是为了保持每个中间步骤的稳定而引入临时兼容代码，因为这类代码往往会演变为长期技术债。技能要求收敛到目标架构，并在明确的验证边界上证明正确性。核心规则包括：优先保证最终状态的完整性而非过渡期的稳定性；当中间阶段的破坏是经过计划、范围明确且可回滚时，这种破坏是可以接受的。护栏条件包括：仅用于具有明确阶段边界的计划性重写与迁移；需声明何处允许临时破坏；对于同时存在新旧契约的迁移，应调用 /principle-migrate-callers-then-delete-legacy-apis 获取兼容策略与验证单元门禁，过渡性破坏须保持在声明的单元内，且必需的发布边界仍须通过；迁移期间对正在改动的区域保留高信号检查；在计划完成时要求完整的静态与运行时验证。
principle-redesign-from-first-principles
这是一个用于在现有设计中整合新需求的方法论技能。它主张不要将变更简单“打补丁”式地附加到原有设计上，而是假设该需求从一开始就是基础假设，重新进行整体设计。技能要求先阅读所有受影响的文件并理解当前设计，然后追问“如果从零开始、带着这个新需求，我们会构建什么”，再将变更传播到类型、文档、示例和设计理由等每一处引用，最后先想清楚完整重设计，再增量交付。其核心目的是在向既有设计整合变更时保留选择权（option value）。当涉及模块或接口推理时可调用 /codebase-design，当涉及已确认的项目术语、关系或归属变更时可调用 /domain-modeling 并协调项目权威产物。
principle-sequence-verifiable-units
该技能是一项工作方法原则，用于指导多步骤任务（如批量修改、迁移、同类编辑）以及提交与 PR 的组织方式。核心做法是把工作拆成一个个小的、可验证的单元，每个单元以可检查的状态结束，只有声明的检查通过后才进入下一个单元。它强调在批量操作中逐项验证、按能证明工作的顺序堆叠提交与 PR（典型形态是先有失败测试、再在其上放修复），从而把“相信我”变成“看它先红后绿”。该原则与 /principle-prove-it-works 和 /principle-build-the-lever 互补。
principle-subtract-before-you-add
这是一个关于系统演进顺序的工程原则技能，主张在新增、重构或重写之前先做减法。它要求先移除死代码、冗余校验器和占位引用，再在更简单的基础上构建。核心内容包括：把简化当作持续投入，让设计在相同或更小的表面下变得更简单且更有能力；先删减再打磨，先达到最小可用再投入质量；按实际观察到的使用情况设计，而非臆测的边缘情况；不添加规格未要求的推测性校验器、解析器或守卫；简化提示词，去掉冗余指令和过度模板；当某个引用没有新内容时直接删除，而不是留下占位。适用于代码重构、系统演进和提示词优化等场景。
principle-type-system-discipline
该技能是一套关于类型系统纪律的编码原则，适用于任何静态类型语言。核心目标是让编译器拒绝不可能的状态、混用的基础类型和未处理的变体，主张通过类型设计消除错误与特殊情况，而非不断增加处理分支。内容包括：为语义不同的基础类型（如 UserId 与 OrderId）建立品牌类型，在创建时校验一次、下游信任类型；在 RPC、JSON、IPC、CLI 参数、配置文件、环境变量、数据库行等边界处用解析函数把无类型输入转为类型化模型；从 protobuf、OpenAPI、GraphQL、数据库迁移、设计令牌等权威 schema 派生类型；仅在出现部分性时加强类型，把运行时断言、空值检查或“不应发生”的抛出上推到类型中，并优先使用全函数。TypeScript 语法示例可调用 /typescript-best-practices，验证位置可参考 /principle-boundary-discipline，结构编码可参考 /principle-encode-lessons-in-structure。
statechart
Statechart 是一个在 Pstack 任务中使用的技能，用来以 Mermaid 状态图展示系统在状态之间的迁移，例如产品流程、协议或服务的行为，并用 TLA+ 检查图表。图表用读者能观察或关心的词语标注状态（如“Paying”），用触发迁移的事件标注步骤（如“tap Pay”），而不使用变量名和动作名。工具通过 node <skill dir>/scripts/statechart.mjs --help 查看命令和读图方法，建议在仓库外的临时目录工作，首次运行会用 mise 安装 TLC 和 Java（约 305 MB，需联网）。
teach
teach 是一个用于 Pstack 任务的技能，用来以通俗语言同时讲清代码如何运作、以及它为什么被设计成这样。目标让人理解，而不是改代码。它建立在 /how 与 /why 之上：先读代码定位，再并行调用 /how（讲运作方式）与 /why（讲设计原因），把结果融成一份平实讲解，按提问动机与已知水平决定深度，先给最小完整答案，再按需分层深入。
typescript-best-practices
这是一份面向 TypeScript 类型编写的代理技能（Agent Skill），用于在编写类型定义、校验边界、可辨识联合或公共 API 时提供规则指导。内容以规则清单形式给出，涵盖可辨识联合、品牌类型、构造式建模、最简完备类型、用 unknown 替代 any、先写 schema 再做类型守卫、避免未经校验的断言、类型收窄优先级、类型守卫写法、穷尽性检查、用 satisfies 替代 as、边界校验、由 schema 派生类型、对象参数、真实测试和结构化遥测等最佳实践，并附有模式示例文件 references/patterns.md 的指引。
why
这是一个用于调查代码背后动机与意图的智能体技能，与回答代码做什么的 /how 互补，专门回答是什么力量塑造了代码当前形态。它通过并行调查源代码管理历史、工单、长文档、团队聊天、基础设施可观测性、错误追踪和产品分析等证据来源，再由合成器输出带置信度区分的结论。该技能强调谨慎、精确的调查态度，明确区分已知与推断，并要求记录空结果和跳过理由。
drizzle
面向 TypeScript 的 Drizzle ORM 技能，覆盖 schema 定义、查询与迁移，适用于需要类型安全且轻量的 SQL 访问场景。