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>
71 lines
3.8 KiB
Markdown
71 lines
3.8 KiB
Markdown
# Design before you write code
|
|
|
|
One attempt at a hard design locks in the first shape the model thought of. These three skills exist so that doesn't happen. `/architect` settles types and boundaries before implementation. `/arena` runs several attempts in parallel and merges the best parts. `/interrogate` has other models try to break the result.
|
|
|
|
|
|
|
|
## Settle the shape with `/architect`
|
|
|
|
```text
|
|
/architect design the import pipeline before writing any code. i care most about how callers use it.
|
|
```
|
|
|
|
[`/architect`](../../skills/architect/SKILL.md) grounds itself first, running `/how` over the code the design touches and `/why` when it moves ownership or layers. Then it runs `/arena` to produce competing design sketches, with the caller's usage written first in each, followed by types, signatures, and a module map.
|
|
|
|
By default it proceeds straight from the synthesized design into implementation. If you want to see the design first, say so:
|
|
|
|
```text
|
|
/architect with checkpoint. stop and show me before implementing.
|
|
```
|
|
|
|
## Fan out attempts with `/arena`
|
|
|
|
```text
|
|
/arena take my prompt to the arena verbatim. i want to compare their proposals with yours.
|
|
```
|
|
|
|
[`/arena`](../../skills/arena/SKILL.md) is the general tool underneath. N subagents attempt the same task in parallel, each writing to its own worktree or directory. A read-only judge, on a different model family when your configuration allows one, scores every candidate against a rubric. The coordinator reads each candidate end to end, picks a base, grafts in the best ideas from the losers, and verifies the result.
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
A[One task] --> B[Configured panel]
|
|
B --> C[Candidate 1]
|
|
B --> D[Candidate 2]
|
|
B --> E[Candidate N]
|
|
C --> F[Cross-judge]
|
|
D --> F
|
|
E --> F
|
|
F --> G[Pick a base]
|
|
G --> H[Graft the best parts]
|
|
H --> I[Verify]
|
|
```
|
|
|
|
The panel comes from your [`/setup-pstack`](../../skills/setup-pstack/SKILL.md) configuration, and you can adjust it per task. Ask for more candidates when the decision matters, fewer when it doesn't:
|
|
|
|
```text
|
|
/arena this, 5 candidates. the cache key format is expensive to change later.
|
|
```
|
|
|
|
## Break it with `/interrogate`
|
|
|
|
```text
|
|
/interrogate the whole branch, but skeptically. no nitpicks unless it's an actual bug or regression.
|
|
```
|
|
|
|
[`/interrogate`](../../skills/interrogate/SKILL.md) sends the same diff, intent, and rubric to several reviewers on different model families. Model diversity is the point. Different models have different blind spots, so a finding two models raise independently is high-confidence signal. The lead sorts everything into `Act on`, `Consider`, `Noted`, and `Dismissed`, with a reason for each dismissal, and applies nothing automatically.
|
|
|
|
Read the dismissals too. The lead is a pragmatic senior engineer, not an oracle, and you can override it.
|
|
|
|
## How much design work does a task deserve?
|
|
|
|
You might be wondering whether every change needs this. No. Most changes need none of it. A rough ladder:
|
|
|
|
- A small, finished change you're unsure about needs `/interrogate` alone.
|
|
- A change that crosses function boundaries or moves ownership earns `/architect`, which brings `/arena` with it.
|
|
- A standalone decision where independent attempts would help, like naming, formats, or an algorithm, is `/arena` directly.
|
|
- A contested design that's expensive to reverse gets `/architect`, then `/interrogate` before shipping.
|
|
|
|
`/poteto-mode` already applies this ladder. Boundary-crossing work triggers `/architect` on its own, so you reach for these directly mainly when you want more or less scrutiny than the default.
|
|
|
|
Next: [Build and clean the change](./05-build-and-clean.md).
|