An agent can produce a plausible implementation before anyone has settled what the feature means. That speed exposes familiar engineering problems: unclear requirements, changes that break distant callers, and tests that confirm the implementation's assumptions. A useful skill makes those failures harder to repeat by specifying what the agent must inspect, decide, and verify.
Lauren Tan's pstack, Matt Pocock's skills, and Dietrich Gebert's Ponytail address this problem at different levels. This article compares their documented approaches and proposes a workflow for experienced developers. The workflow is an editorial recommendation, not a benchmark or a claim that these collections combine automatically. Sources were checked on October 22, 2026.
What a skill actually changes
A skill supplies reusable instructions, sometimes with supporting scripts and references. It does not retrain the model, grant missing permissions, or prove that an implementation works. Its effect depends on whether the agent loads the relevant instructions and has access to the tools those instructions expect.
Evaluate a skill by the decision it changes. Does the agent inspect callers before changing a signature? Does it ask about an unresolved product rule? Does it verify the result through the application? A long instruction file that changes none of these decisions adds reading cost without a clear engineering benefit.
Pstack coordinates the engineering process
Tan's pstack lives in Cursor's plugins repository. Its entry point, poteto-mode, selects a playbook and brings in other skills as the task requires. The repository documents workflows for investigations, bug fixes, features, reviews, and longer autonomous work. Model selection is configured through setup-pstack. These are workflow instructions with runtime dependencies, so check the adapter for your particular agent.
The current architect skill starts with the surrounding system, then sketches types, signatures, and module boundaries. It asks for structurally different design candidates before implementation. It also treats repeated implementation friction as evidence that the design may need replacement. This costs more up front, but it gives reviewers something concrete to challenge before a large patch exists.
The mode's trigger rules connect activities to the relevant discipline. Architecture, parallel exploration, measurement, and UI verification each have explicit expectations. That coordination is pstack's distinguishing contribution. A team adopting it should decide which workflows fit its review process and which integrations are actually available.
Matt Pocock makes alignment and feedback explicit
Pocock's collection frames recurring failures around misalignment, unclear domain language, missing feedback, and difficult code structure. Its setup skill records repository-specific choices such as the issue tracker and documentation location. That gives subsequent work an agreed place to record decisions.
The grill-with-docs skill composes grilling with domain modeling. This matters when a request contains a hidden business rule. “Allow users to reorder categories” leaves open who owns the order, whether inactive categories participate, and what happens when two editors save concurrently. Those decisions affect persistence and authorization, so resolving them after implementation creates avoidable rework.
Pocock's codebase-design vocabulary defines an interface broadly. Callers must understand its invariants, errors, ordering constraints, and configuration as well as its type signature. A deep module provides substantial behavior through a small interface. This is a useful review question: how much coordination must each caller perform correctly?
The current TDD skill requires agreement on the interfaces under test, then small failing-test and implementation cycles. It rejects tests coupled to private structure and tests that recreate the same calculation as the implementation. Its current text places refactoring in the review stage. Read the actual skill when precise workflow behavior matters, because a repository overview can describe an older convention.
Ponytail constrains the size of the solution
Gebert's Ponytail skill asks the agent to solve the complete task with the least necessary new code. Its preference order starts by questioning unnecessary scope, then checks existing project code, platform capabilities, and installed dependencies. It explicitly preserves validation, security, accessibility, and error handling that prevents data loss.
That distinction matters. Reusing an existing form component can remove work. Omitting server validation merely transfers risk to production. Ponytail also requires the agent to inspect the places a change must reach, including callers, tests, configuration, and fixtures. A short diff is valuable after the affected behavior is understood.
Ponytail review reads connected code beyond the diff and prioritizes correctness, safety, behavior under load, testing, performance, and unnecessary code. Its central question is practical: what breaks for the user, and what change fixes that failure? The project's published measurements remain upstream results, not a guarantee for your repository.
A concrete workflow for a reorder feature
Consider an admin interface that stores the display order of skill domains. Use this example to evaluate the collections on one bounded task. The following prompt is illustrative and does not depend on a particular slash-command syntax:
Inspect the existing domain model and every reader of domain order.
Ask only about product decisions the repository cannot answer.
Propose the smallest complete update contract.
Verify stale submissions, authorization, and public rendering.
Report evidence and any unverified behavior.Start with alignment. Decide whether the order is global, whether every domain must appear in a submitted list, and whether a stale editor should overwrite newer changes. Record those decisions in the project's own terms. This is where Pocock's interview and documentation approach is useful.
Next, inspect the data and readers. A reorder operation may affect the admin list, a create-form dropdown, and the public portfolio. Write one contract before selecting an implementation. For example, a request supplies every current domain ID once, and the server commits the new positions atomically. An incomplete list produces a conflict that the interface can explain.
Use pstack's design discipline when the contract crosses meaningful boundaries. Compare a global order with a per-user preference only if both are plausible product requirements. Multiple designs should settle a real uncertainty. They should not create extra infrastructure for a decision already settled by the existing model.
Apply Ponytail's constraint during implementation. Reuse the application's authentication, transaction support, and existing reorder control. Avoid introducing an event system or a generalized ranking service for a small global list. Keep the stale-list check and access control because they implement the agreed behavior.
Verification must observe the promised behavior
Pstack's prove-it-works principle requires checking the actual result rather than a proxy. For the reorder example, a successful HTTP response alone cannot establish that visitors see the right sequence.
A useful verification record covers an authorized reorder, an unauthorized request, and a stale submission. It also checks the public order after reload and confirms that unrelated skill ratings remain unchanged. Choose automated checks at the agreed interfaces, then inspect the browser interaction when the feature changes the UI. A test that only asserts which helper was called misses the product requirement.
Compose deliberately and measure locally
My recommendation is to assign one collection responsibility for coordinating a task, then use selected skills for a specific need. Pstack can coordinate a complex investigation. Pocock's skills can clarify the domain and test interface. Ponytail can challenge unnecessary implementation scope. This division is a proposed team convention, not a built-in interoperability guarantee.
Before installation, inspect names, triggers, and approval rules. Two skills called tdd may impose different expectations. Automatic updates can change a workflow, while copied files need deliberate maintenance. Keep a record of the version or commit used when reproducibility matters.
Evaluate adoption with representative repository tasks and independent acceptance criteria. Record correctness failures, review effort, total completion time, and unnecessary dependencies. Repeat tasks enough to expose variability. Fewer lines or tokens are useful only when the implementation still satisfies the same contract. Keep the skills that measurably improve decisions, and remove instructions that repeatedly conflict with the way your team ships software.