* pstack: add public usage tutorial Co-authored-by: lauren <poteto@users.noreply.github.com> * pstack: document verification skill workflows Co-authored-by: lauren <poteto@users.noreply.github.com> * pstack: mention verification setup offer Co-authored-by: lauren <poteto@users.noreply.github.com> * pstack: clarify optional verification setup Co-authored-by: lauren <poteto@users.noreply.github.com> * pstack: rewrite tutorial prompts to match real usage The example prompts read like specs. Real prompts are short, informal, and goal-first, so every example now uses that register. The prose reshapes around them: friendly second-person tutorial voice, goals before mechanics, pitfalls where readers actually trip, and the playbook reference table replaced with prompts in context. Every skill claim re-checked against the skill files at this commit. * pstack: make the README guide link an invitation Point new readers at what the guide walks them through instead of listing its topics. * pstack: drop the version bump This PR only adds documentation, so the plugin manifest stays at main's 0.11.7. * pstack: add illustrations to the guide One hero image per major guide page (routing, understanding, design, verification, overnight runs, recipes), 1200px JPEGs under docs/guide/images/. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
3.6 KiB
Build the change and clean the diff
The build playbooks share one discipline. Say what you observed, let the playbook demand the evidence. This page shows what to put in the prompt for each common build task, then the cleanup habit that keeps diffs reviewable.
Prompt each build playbook with what you know
A bug prompt states the symptom and asks for a reproduction first:
/poteto-mode this command emits two records after a retry. repro first, then fix and verify.
A feature prompt states the behavior and what must not change:
/poteto-mode add a --json flag. text output stays byte-identical. verify both forms.
A refactoring prompt pins behavior before structure moves:
/poteto-mode move parsing into one module, zero behavior change. record the current output first and prove it's unchanged after.
A perf prompt states the measurement, not a vibe:
/poteto-mode startup takes 1.8s on this fixture. trace it, fix the measured cause, show me before and after.
Each of these routes to its playbook (Bug fix, Feature, Refactoring, Perf issue), and the playbook supplies the steps you didn't type: reproduce before fixing, name the data shape before implementing, pin behavior before restructuring, profile before optimizing.
For sustained improvement of one number, there's the Hillclimb playbook. Give it the metric, a target, and a floor on attempts, and it loops one hypothesis at a time with a frozen measurement harness. It keeps wins and reverts everything else.
Write the failing test first with /tdd
When a bug has a cheap local test path, the whole prompt can be two words:
/tdd implement
In context, that's enough. /tdd writes the smallest test that fails for the intended reason, then the fix, then reruns the test. If a test would need broad harness setup or brittle mocks, the skill says so and uses the closest executable check instead. Don't force a test where a real command is stronger evidence.
Let the TypeScript rules load themselves
typescript-best-practices has no slash command in your workflow. It loads whenever the agent touches a .ts or .tsx file and turns the type-system principles into concrete rules: discriminated unions, unknown at boundaries, exhaustive variants, schema-derived types.
Clean before you commit
The Opening a PR playbook runs /deslop on the diff before each commit and applies /unslop to the PR description and commit bodies. /deslop ships in the cursor-team-kit plugin, not in pstack. If you don't have it, ask for the same outcome in plain words: remove narrating comments, unsupported guards, dead compatibility paths, and unrelated edits.
For prose, /unslop takes a target and any extra rules you have:
/unslop the readme changes, no emdashes
You'll develop your own shorthand. The skill reads intent fine from terse prompts like unslop that, tighten it.
Pitfall: cleanup is not optional polish. A diff with narrating comments and defensive dead weight reads as unfinished to reviewers, and the extra code is where the next bug hides. If the diff feels padded, say deslop it before you commit, not after review calls it out.
Next: Verify and ship.