Cursor skills: when pstack earns its extra cost

Why it matters

An agent can finish a task, pass the tests, and still deliver the wrong behavior. Anyone building software with AI needs a practical way to close that gap. Otherwise, faster implementation simply moves more work into review, debugging, and support.

Lauren Tan’s pstack packages engineering skills and workflows around that problem. In the video, Rob Shocks explores the stack while building a skill manager. What interests me most is the emphasis on producing evidence: investigate the failure, exercise the implementation, and leave behind a check another developer can run. That is useful even if you adopt only a small part of the package.

There is a tradeoff. More investigation, model reviews, and verification can increase both elapsed time and inference spending. I would judge the stack by the cost of reaching an accepted change, including human attention and rework. The framework below adds a risk-based adoption guide and a concrete data-import exercise. It is a proposed way to evaluate pstack; the demonstration results discussed here are Rob’s.

Key points

• 5:49 Product verification needs evidence from execution. Rob demonstrates reviews by multiple models and workflows that create reusable verification routines. These answer different questions. Review identifies plausible defects; running the application shows what happened in a particular scenario. A strong delivery process needs to distinguish the two.
• 11:40 Additional rigor consumes time and model calls. The presenter reports roughly thirty minutes without the stack and an hour with it, describing the latter result as more robust. This is an illustrative comparison rather than a controlled benchmark. It cannot establish a general productivity or defect-reduction claim.
• 1:35 The entry point routes work into an appropriate workflow. /poteto-mode reduces the need to select every supporting skill manually. The developer still needs to supply a clear objective, meaningful constraints, and an observable definition of completion.
• 2:38 Arena and swarm solve different coordination problems. Arena generates competing attempts at one problem. Swarm distributes different parts of the work. Competing designs can help resolve architectural uncertainty; independent assignments can help with separable tasks. The combined result still requires integration checks.
• 3:41 Historical context can explain surprising code. The why skill looks beyond source files to available evidence about previous decisions. That can uncover an important constraint, but an old discussion may no longer describe the current system. Findings should retain their sources and be checked against present behavior.
• 9:00 Less code and lower reading effort are explicit goals. The video highlights small changes, deletion, and simpler structures. These give a reviewer something concrete to assess: whether the resulting implementation can be understood and maintained without reconstructing the agent’s entire conversation.

How to apply

Cursor skills: match the workflow to the consequence

My starting rule would be to increase verification effort with the cost of an undetected mistake. The table below is an adoption framework I would use, rather than an official pstack classification.

| Change | Initial workflow | Acceptance evidence | | --- | --- | --- | | Local copy or visual adjustment | One implementation and direct inspection | Affected screens and states checked | | Business rule or reproducible bug | Reproduction, regression test, and workflow execution | Observed failure before the fix and expected behavior afterward | | Import pipeline, permissions, or structural change | Integration verification; additional review for a specific uncertainty | Correct persisted state, failure handling, and checks of related behavior |

Line count is a poor substitute for this assessment. A one-line permission change can have a wider impact than a large stylesheet update. Before adding another agent, identify the uncertainty it will investigate or the independent task it will own.

Start with a bounded trial

The official Cursor marketplace listing gives /add-plugin pstack as the installation command. The project README directs users to configure models with /setup-pstack and use /poteto-mode for work requiring rigor.

Record the version or commit you evaluate. The project has evolved since the recording, so the video’s skill counts and behavior should not become a permanent installation guide. Other environments have their own adaptations; Michael Denyer’s port is maintained separately from the Cursor original.

For the first trial, choose a known defect with a small scope and an observable outcome. That makes it easier to assess the workflow without also evaluating a major redesign.

Give verification a realistic target

Consider an order importer receiving exports from a Brazilian storefront. A successful upload message tells you little about whether 1.234,56 was interpreted correctly, whether 08/09/2026 became the intended date, or whether retrying the upload created duplicate orders.

Create a small fixture before implementation. Calculate its expected totals yourself, specify the source’s date convention, and decide how invalid rows should be handled. For this exercise, require repeat processing to preserve the correct order count.

Then follow the data through the application. Check the stored records and the query or screen the user relies on. A parser unit test is useful, but it does not establish that the persistence and presentation steps preserve the same meaning.

Use four acceptance conditions:

1. Stored monetary amounts match the fixture without a scale error.
2. Dates follow the convention declared for this source.
3. Processing the same fixture twice leaves the expected number of orders.
4. Invalid input receives the agreed treatment and enough identification to fix the source row.

A reusable verification routine now has a clear purpose: protecting these behaviors during the next importer change. If the implementing agent also writes the tests, inspect the expected values independently. The same mistaken assumption can otherwise appear in both artifacts.

For an extra reviewer, give a focused assignment. Asking it to examine retry behavior is easier to evaluate than asking whether the entire application looks good. Require a reproducible counterexample for any claimed defect.

Measure the whole delivery loop

Track model spending, elapsed time, human attention, correction rounds, and defects discovered after acceptance. Keep elapsed time separate from human work. A longer run may need little supervision; a short run may return a difficult review.

When comparing approaches on the same task, start from the same commit in separate sessions and preserve the acceptance conditions. Record the model, configuration, and budget as well. Repeat across several tasks before choosing a default. One impressive result is a reason to investigate further, not a stable performance estimate.

Use your actual billed cost when combining spending with internal labor costs. For teams working across currencies, record the conversion method so later comparisons remain meaningful. The useful outcome is cost per accepted task, including review and rework.

Make the handoff independently checkable

For the importer exercise, I would begin with this request:

Use poteto-mode to fix duplicate order imports. Reproduce the defect using the fixture, preserve its declared currency and date conventions, and demonstrate that processing it twice leaves the expected counts and values. Return the change, commands executed, observed results, and verification limits. Before using arena or swarm, identify the uncertainty or independent assignment that justifies the additional cost.

The final handoff should let someone else repeat the check without reading the full conversation. Keep the fixture, expected outcome, execution instructions, and observed result together.

I would retain pstack where that process reduces later corrections or makes review easier to complete. For a simple visual adjustment, I would begin with the smallest workflow in the table. Each additional step should earn its place by producing evidence the task needs.