mirror of
https://github.com/cursor/plugins.git
synced 2026-09-14 20:00:00 +08:00
lauren
24bd6eb895
lauren tan's working style as a Cursor plugin. Bundles the poteto-mode routing skill plus the workflow skills it routes through (how, why, architect, arena, unslop, interrogate, automate-me, reflect, tdd) and the full seventeen-skill set of first principles. Ships the poteto-agent subagent that runs the same workflow end-to-end. The why skill discovers available MCPs at run time and maps each to an evidence category (source control, issue tracker, long-form docs, real-time chat, infra observability, error tracking, analytics warehouse). No third-party service integrations required. cursor-team-kit's control-cli, control-ui, and deslop are referenced as sibling-plugin dependencies for surfaces and commit cleanup; the kit works standalone otherwise. Marketplace entry registered at the root .cursor-plugin/marketplace.json.
1.4 KiB
1.4 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| principle-make-operations-idempotent | Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs. | true |
Make Operations Idempotent
Design operations so they converge to the correct state regardless of how many times they run or where they start from. Every state-mutating operation should answer: "What happens if this runs twice? What happens if the previous run crashed halfway?"
Why: Commands, lifecycle operations, and processing loops run where crashes, restarts, and retries are normal. If partial state changes the next run's outcome, every restart becomes a debugging session.
The pattern:
- Convergent startup: scan for existing state, clean stale artifacts, adopt live sessions
- Content-based cleanup: compare by content equivalence, not creation order
- Self-healing locks: use PID-based stale lock detection
- Idempotent scheduling: failed work respawns cleanly, fresh input regenerated after each cycle
The test:
- What happens if this runs twice in a row?
- What happens if the previous run crashed at every possible point?
- Does re-execution converge to the same end state?
If any answer is "it depends on what state was left behind," the operation needs a reconciliation step.