lauren
424829e3e0
* docs(pstack): complete the poteto-mode route map The guide's route paragraph predates the autopilot playbooks, so a reader browsing routes never learns a PR queue can run on autopilot. Add that route, and give worktree cleanup a prompt in the section that tells readers to fan out worktrees in the first place. Co-authored-by: lauren <poteto@users.noreply.github.com> * docs(pstack): teach /no-comments and Comment Sicko in the cleanup chapter The cleanup habit covered /deslop and /unslop but not the comment pass, so readers never met Comment Sicko or the constraint-encoding offer. Add the before-review step and state the deslop / unslop / no-comments division of labor. Co-authored-by: lauren <poteto@users.noreply.github.com> * docs(pstack): cover Babysit and Shipping after the PR opens The chapter ended at opening the PR and a note claiming pstack bundles no PR monitoring. That note is stale: Babysit ships with the watch-pr watcher and Shipping lands verified stacks through Graphite merge-when-ready. Replace it with the two playbooks, their prompts, and the merge-ready versus land distinction. Co-authored-by: lauren <poteto@users.noreply.github.com> * docs(pstack): teach the autopilots and orchestrate in the overnight chapter The chapter covered one task per night and nothing bigger, so the queue and program playbooks had no home in the guide. Add autopilot-full, autopilot-stack, and orchestrate with prompts and the rule for choosing between them. Co-authored-by: lauren <poteto@users.noreply.github.com> * docs(pstack): introduce /technical-writing and /bro in the later chapters Both skills shipped without a guide mention. /technical-writing sits with skill authoring, where readers already write prose that agents and humans consume. /bro joins the recipes as the one-word prompt for a jargon-free restatement. Co-authored-by: lauren <poteto@users.noreply.github.com> * docs(pstack): technical-writing pass over the new guide prose Fixes traced to the skill's rules. Split sentences carrying two or three thoughts (STE). Moved 'only' next to what it changes and gave the merge-ready heading a real subject instead of 'it' (Global English). One name per thing: uncommitted work, Autopilot-full, verdict instead of say-so. Replaced unglossed jargon with plain words: 'drains completions' and 'merge frontier' now say what the coordinator does, 'the real surface' is now 'proves the behavior live'. Co-authored-by: lauren <poteto@users.noreply.github.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
4.5 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.
Write docs to a standard with /technical-writing
Skills aren't the only prose you ship. For docs, RFCs, readmes, PR descriptions, and commit messages:
/technical-writing review the readme changes
/technical-writing applies a layered standard with one goal, prose a tired engineer understands on the first read. It picks the document's mode first (tutorial, how-to, reference, or explanation), then works sentence by sentence: who does what, one thought per sentence, nothing readable two ways. Use it to review what you or an agent just wrote, or name it up front when you ask for a doc.
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.