lauren
02c03a9ded
* 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.9 KiB
Make it yours
poteto-mode is one person's style. The machinery underneath, playbooks, routing, model roles, works just as well wearing yours. This page covers generating a personal mode, capturing lessons from a session, authoring a focused skill, and testing a skill change before you trust it.
Generate your own mode with /automate-me
/automate-me
You don't describe your style, because /automate-me reads it out of your history. It mines your recent transcripts in the active workspace for repeated preferences, in how you like replies, delegation, verification, code, prose, and process, then asks you which patterns are really you. It drafts .cursor/skills/<your-name>-mode/SKILL.md through Cursor's built-in create-skill flow, runs the draft through /unslop, and opens a PR from a worktree so you review it like any other change.
Run it again whenever your habits drift:
/automate-me update my mode skill with everything since its last edit
Update mode mines only the history since the skill last changed. It keeps rules you haven't contradicted, revises the ones with new evidence, and adds sections only for genuinely new patterns.
Capture a session's lessons with /reflect
Right after a task that taught you something, run:
/reflect that took way too long. capture what we learned so the next run doesn't repeat it.
/reflect sends the transcript to three parallel reviewers, then a synthesizer sorts the proposals into Accepted, Rejected, and Backlog and waits for your approval before any skill changes. Approve a proposal only if it would change a future decision. One weird session is an anecdote, not a rule.
Author a focused skill
When you already know the workflow you want to capture:
/poteto-mode write a skill for verifying database migrations in this repo
Writing a skill matches the Authoring or modifying a skill playbook, which routes through Cursor's built-in create-skill, validates the frontmatter and links, and ships the result through the Opening a PR playbook. Agent-facing prose has a higher bar than human prose, because an unhelpful sentence becomes an instruction some future agent follows. Let the playbook hold that bar rather than writing a SKILL.md freehand.
One special case has its own generator. A skill that must drive your app and prove behavior is a verification skill, so use /create-verification-skill and /maintain-verification-skill instead. Verify and ship covers both.
Test a skill change blind
A skill edit affects every future session, so test it like the experiment it is:
/poteto-mode run the eval playbook on this skill change. same task for both variants, candidates stay blind.
The Eval playbook is built around one failure mode, the observer effect. An agent that knows it's being evaluated behaves differently. So candidate agents get an organic-looking task in sanitized directories, never the words "eval" or "candidate", and never each other's existence. One judge scores all outputs under neutral labels, and chain-following gets graded from which files each candidate actually read, not from what it claims.
Read every output yourself before accepting the verdict. If you disagree with the judge, suspect the rubric before you suspect your judgment.
Pitfall: don't edit a skill mid-task because it's misbehaving. Fix it in its own PR and keep the task moving. A skill edit that ships tangled into feature work is invisible to review and impossible to evaluate.
Next: Recipes and pitfalls.