Make it yours

Source

This page reprints the English original.

pstack/docs/guide/09-make-it-yours.md (cursor/plugins 12d587d).

中文页

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.