找到让你的 Agent 更能干的技能

用浏览器自动化对本地或线上 Web 应用做端到端验证：截图比对、交互脚本、控制台错误捕获。

Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.

Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.

Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.

Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.

Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when personal data or privacy compliance (GDPR, CCPA) is involved.

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks.

Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.

Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".

Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.

Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.

Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.

Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.

Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.

Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.

Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.

Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

查看文档/散文以了解写作指南的合规性。在被要求“查看我的文档”、“检查写作风格”、“审核散文”、“查看文档的语音和语气”或“根据写作手册检查此页面”时使用。

查看用户界面代码以了解Web界面指南合规性。在被要求“查看我的用户界面”、“检查辅助功能”、“审核设计”、“查看用户体验”或“根据最佳做法检查我的网站”时使用。

用于部署项目的Vercel成本和性能优化，特别是Next.js、SvelteKit、Nuxt和有限的Astro应用程序。首先收集Vercel指标、使用情况、项目配置和代码扫描结果；仅调查指标支持的候选人；生成基于已验证文件和版本感知的Vercel/框架文档的排名推荐。触发Vercel账单减少、缓慢或昂贵的路线、缓存机会、函数调用、构建分钟、快速数据传输、核心Web Vitals、机器人管理、流体计算或成本分解请求。

使用基于令牌的身份验证在Vercel上部署和管理项目。使用访问令牌而不是交互式登录使用Vercel CLI时使用—例如“部署到vercel” ， “设置vercel” ， “将环境变量添加到vercel”。

使用React的View Transition API （ “<ViewTransition>组件”、“addTransitionType”和CSS视图过渡伪元素）实现平滑、原生感觉的动画的指南。每当用户想要添加页面过渡、动画路由更改、创建共享元素动画、动画组件的进入/退出、动画列表重新排序、实现定向（前进/后退）导航动画或在Next.js中集成视图过渡时，请使用此技能。当用户提及视图过渡、“startViewTransition”、“ViewTransition”、过渡类型或询问React中没有第三方动画库的用户界面状态之间的动画时，也可以使用此选项。

React Native和Expo构建高性能移动应用程序的最佳实践。在构建React Native组件、优化列表性能、实现动画或使用本机模块时使用。触发涉及React Native、Expo、移动性能或本机平台API的任务。

Vercel Engineering的React和Next.js性能优化指南。在编写、审阅或重构React/Next.js代码时应使用此技能，以确保最佳性能模式。触发涉及React组件、Next.js页面、数据获取、捆绑优化或性能改进的任务。

将应用程序和网站部署到Vercel。当用户请求“部署我的应用”、“部署并给我链接”、“推送此实时”或“创建预览部署”等部署操作时使用。

反应可扩展的组合模式。使用布尔属性扩散重构组件、构建灵活的组件库或设计可重用的API时使用。触发涉及复合组件、渲染道具、上下文提供程序或组件体系结构的任务。包括React 19 API更改。

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).

Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", or invokes /ponytail-review. Complements correctness-focused review, this one only hunts complexity.

Quick-reference card for all ponytail modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /ponytail-help, "ponytail help", "what ponytail commands", "how do I use ponytail".

Show ponytail's measured impact as a compact scoreboard: less code, less cost, more speed, from the benchmark medians. One-shot display, not a persistent mode, and not a per-repo number. Trigger: /ponytail-gain, "ponytail gain", "what does ponytail save", "show ponytail impact", "ponytail scoreboard".

将代码库中的每个“ponytail:”注释收获到债务分类账中，这样就可以跟踪马尾辫留下的故意快捷方式和延迟，而不是腐烂到“以后意味着永远不会”。当用户说「ponytail debt」、「/ponytail-debt」、「ponytail defer」、「list the shortcuts」、「ponytail ledger」或「what did we mark to do later」时使用。一次性报告，什么都不会改变。

过度工程的整体备份审核。类似于ponytail-review ，但扫描整个代码库而不是diff ：要删除、简化或替换为stdlib/native等效的内容的排名列表。当用户说“audit this codebase”、“audit for over-engineering”、“what can I delete from this repo”、“find bloat”、“ponytail-audit”或“/ponytail-audit”时使用。一次性报告不适用于改进项。

任何编码任务（编写、重构、修复、审查）的懒高级开发模式：首先是YAGNI、stdlib ，没有未经请求的抽象。不适用于非编码请求。

查看过度设计的差异。查找要删除的内容：重新设计的stdlib、不必要的deps、投机抽象。每个发现一行。

马尾辫的模式、技能和命令的快速参考。一次性显示。

将马尾辫测量的影响显示为记分牌：从基准中位数来看，代码更少、成本更低、速度更快。一次性显示。

收获每个马尾辫：将快捷方式注释到一个债务分类账中，以便跟踪延期而不是遗忘。一次性报告。

审核整个存储库的过度设计。要删除、简化或替换为stdlib或本机功能的排名列表。