mirror of
https://github.com/cursor/plugins.git
synced 2026-09-14 20:00:00 +08:00
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>
91 lines
4.0 KiB
Markdown
91 lines
4.0 KiB
Markdown
# Route work through `/poteto-mode`
|
|
|
|
`/poteto-mode` is the front door. You give it a goal, it matches one of sixteen playbooks, copies that playbook's steps into the todo list, and calls the other skills as the steps need them. In this page you learn what a good prompt looks like, and how little of one you actually need.
|
|
|
|
|
|
|
|
## What happens to your prompt
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
A[Your prompt] --> B[poteto-mode]
|
|
B --> C[Read the Principles section]
|
|
C --> D{Match the task}
|
|
D -->|Read-only question| E[Investigation]
|
|
D -->|Defect| F[Bug fix]
|
|
D -->|New behavior| G[Feature]
|
|
D -->|Structure only| H[Refactoring]
|
|
D -->|Measured slowness| I[Perf issue]
|
|
D -->|Large work or no match| J[figure-it-out]
|
|
E --> K[Verify and report]
|
|
F --> K
|
|
G --> K
|
|
H --> K
|
|
I --> K
|
|
J --> K
|
|
```
|
|
|
|
The diagram shows the common routes. There are also playbooks for hillclimbing a metric, diagnosing runtime symptoms and captured traces, prototypes, visual parity, authoring and evaluating skills, autonomous runs, session pickup, pausing safely, and multi-phase plans. The [playbook directory](../../skills/poteto-mode/playbooks/) has the full set.
|
|
|
|
## Say the goal, not the ceremony
|
|
|
|
You don't write a spec. You say what's wrong or what you want, plus anything you already know that saves the agent time:
|
|
|
|
```text
|
|
/poteto-mode users get two notifications after a retry. repro first, then fix and verify.
|
|
```
|
|
|
|
That's a Bug fix prompt. "repro first" is a real constraint, not politeness, and the playbook honors it. Watch the todo list fill with the Bug fix steps. A skipped step stays visible with `skip: <reason>`.
|
|
|
|
When the conversation already carries the context, the prompt shrinks to almost nothing. All of these are enough:
|
|
|
|
```text
|
|
/poteto-mode do it
|
|
```
|
|
|
|
```text
|
|
continue
|
|
```
|
|
|
|
```text
|
|
keep going until done
|
|
```
|
|
|
|
Short works because the mode is sticky and the playbook holds the structure. Your words carry the intent, and the skill carries the rigor.
|
|
|
|
## Switch tasks with "new task"
|
|
|
|
A long chat accumulates context from the last task. When you change subjects, say so:
|
|
|
|
```text
|
|
/poteto-mode new task. figure out why the cache entry survives logout. don't change any code yet.
|
|
```
|
|
|
|
"new task" tells `/poteto-mode` to re-match rather than continue the prior playbook. "don't change any code yet" pins this one to Investigation. Without those two phrases, a mode mid-Feature tends to treat your question as the next feature step.
|
|
|
|
## Give parallel work its own worktree
|
|
|
|
If you run several agents against one repository, they will fight over the working tree. Ask for isolation up front:
|
|
|
|
```text
|
|
/poteto-mode new task. branch off <base> in a fresh worktree, then port the parser change there.
|
|
```
|
|
|
|
Each task in its own branch and worktree means no agent stomps another's files. The [Opening a PR playbook](../../skills/poteto-mode/playbooks/opening-a-pr.md) already works from a worktree for code changes, so mostly you only say this when a specific base or location matters.
|
|
|
|
## Leave it running
|
|
|
|
When you step away, say what done means and go:
|
|
|
|
```text
|
|
/poteto-mode im stepping away. keep going until the migration check reports zero old callers. log your decisions.
|
|
```
|
|
|
|
Work you'll review later routes through [`/figure-it-out`](../../skills/figure-it-out/SKILL.md), which designs the run's phases and keeps a [`/show-me-your-work`](../../skills/show-me-your-work/SKILL.md) decision log. [Run work while you sleep](./07-overnight.md) covers the full overnight contract.
|
|
|
|
**Pitfall:** don't enumerate skills in your prompt ("use /how, then /architect, then /arena..."). The playbook already sequences them, and a hand-written sequence usually reorders or drops steps the playbook would have kept. Name a skill only when you want to override a specific choice.
|
|
|
|
Read [`poteto-mode`](../../skills/poteto-mode/SKILL.md) itself for the full routing rules.
|
|
|
|
Next: [Understand the code](./03-understand.md).
|