pstack

Skills

58 in the Cursor listing

• architectSketch types, signatures, and module structure before code, then stay in the loop while implementation fills in.
• arenaSpawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it.
• Automate meUse for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works.
• Benchmark checklistVet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it.
• Blast radiusFind what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up.
• broRestate the last message in plain human language, with no jargon.
• correctFind the mistakes agents keep repeating in this repo and make each one impossible.
• Create formal verification skillGenerate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits.
• Create verification skillGenerate a project-local verification skill that drives your app the way a user does — any language, framework, or platform.
• Figure it outDesign an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away.
• howUse for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer").
• In your own wordsRestate in your own words what you think the user's goals are and what problem they're trying to solve.
• interrogateUse for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find blind spots", or "tear this apart".
• ketchupCatch the user up on what changed in this chat since their last message, in plain words and small visuals.
• Ketchup videoCatch the user up like /ketchup, with a short silent video of slides for what happened and the waiting calls as text under it.
• Maintain formal verification skillBring a project's formal verification back in line with the code after the code changes: find the commits that touched verified code, update the model, harness, or properties to describe the code as it is now, rerun, and say whether each failure is drift in the verification or a
• Maintain verification skillPeriodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections.
• Make bot uiUse when building a custom UI (page, dashboard, buttons) that should wake a Grok Bot over a webhook, when the user must provide a webhook sender key, or when exposing that UI on Tailscale.
• No commentsSpawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.
• Poteto helpGuides users through pstack setup, /poteto-mode, and picking the skill, playbook, or principle for a task.
• Poteto modepoteto's agent style for concise, detailed responses, deliberate subagents, unslopped prose, simple code, and verified work.
• Principle attack the premiseApply when two or more fixes that share one premise have failed the same gate.
• Principle boundary disciplineApply when wiring validation, error handling, or framework adapters.
• Principle build the leverApply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks.
• Principle encode lessons in structureApply when you catch yourself writing the same instruction a second time, or notice a recurring correction.
• Principle exhaust the design spaceApply when facing a novel UI interaction or architectural decision with no precedent in the codebase.
• Principle experience firstApply when product, UX, or feature-scope tradeoffs come up.
• Principle explain the numberApply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result.
• Principle fix root causesApply when debugging.
• Principle foundational thinkingApply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share.
• Principle guard the context windowApply when context is filling up: large outputs, long files, repeated reads, fan-out planning.
• Principle laziness protocolApply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading.
• Principle make operations idempotentApply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries.
• Principle migrate callers then delete legacy apisApply when introducing a new internal API while old callers still exist.
• Principle minimize reader loadApply when reviewing or shaping code that's hard to trace.
• Principle model the domainApply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files.
• Principle never block on the humanApply when tempted to ask 'should I do X?' on reversible work.
• Principle outcome oriented executionApply during planned rewrites and migrations with explicit phase boundaries.
• Principle prove it worksApply after completing a task, before declaring done.
• Principle redesign from first principlesApply when integrating a new requirement into an existing design.
• Principle separate before serializing shared stateApply when concurrent actors might write to the same file, branch, key, or state object.
• Principle sequence verifiable unitsApply to multi-step work (sweeps, migrations, runs of similar edits) and to how you stack commits and PRs.
• Principle subtract before you addApply when sequencing an addition, refactor, or rewrite.
• Principle test behavior not implementationApply when you write, change, or keep a test.
• Principle type system disciplineApply when designing types, reviewing a function signature, or writing code in any statically-typed language.
• recallReconstruct your recent working context from your own chat history, live state, and the shared record (user reports, prior fixes, incidents), then hand back a tight current-state brief.
• reflectSpawn three parallel review subagents over the active transcript, surface learnings, and route each to a concrete edit on an existing skill.
• Setup pstackConfigure which models pstack uses per role and at what reasoning budget.
• sharpenMake a task deeper, not bigger, then rewrite the prompt.
• Show me your workKeep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result).
• statechartCheck a TLA+ model of a system that moves between states, such as a product flow, a protocol, or a service, and draw it as a Mermaid statechart.
• swarmFan out N parallel workers, drain them, and return one report.
• tddUse only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target.
• teachExplain a body of work plainly so a person actually understands it.
• Technical writingLayered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax.
• Typescript best practicesTypeScript best practices.
• unslopCut AI tells from any writing.
• whyUse for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds.