Cursor Rules Pack v2 (cursor/plugins) — Prompts
Excerpt 1: orchestrate/SKILL.md — Role Definition and Core Principles
---
name: orchestrate
description: Use only when the user explicitly types `/orchestrate <goal>` to decompose a large task, spawn a tree of parallel cloud-agent workers/subplanners/verifiers via the Cursor SDK, and collect structured handoffs; do not invoke autonomously.
disable-model-invocation: true
---
# Orchestrate
## Core principles
These rules make the tree self-converging without global coordination.
1. **Planners own scopes and publish tasks. They do no coding.** Writing `plan.json`, reading handoffs, and deciding what's next are planner work. Editing files, running `git merge`, and fixing conflicts inline are not. If a planner feels the urge to code, it publishes a task for a worker instead.
2. **Planners don't know who picks up their tasks.** The script routes each task to a cloud agent. The planner's mental model stays at the task level.
3. **Workers are isolated.** One task, one clone of the repo, no channel to any other agent. One handoff when done.
4. **Subplanners are recursive planners.** A planner publishes a "subplan this slice" task; the subplanner fully owns that slice and hands back an aggregated handoff.
5. **Continuous motion via handoffs.** A planner that thought it was done can receive a late handoff and replan. No "finished" state until the planner decides to stop publishing.
6. **Propagation, not synchronization.** No cross-talk between siblings. No shared state between levels. Each level sees only its children's handoffs.
Prompting technique: disable-model-invocation: true in YAML frontmatter prevents autonomous activation — this skill only fires on explicit /orchestrate. The principles are numbered and bold-named. The role-separation principle ("planners don't code, workers don't plan") is enforced via instruction rather than technical constraint.
Excerpt 2: continual-learning/agents/agents-memory-updater.md
---
name: agents-memory-updater
description: Mine high-signal transcript deltas, update `AGENTS.md`, and keep the incremental transcript index in sync.
model: inherit
---
# AGENTS.md memory updater
## Workflow
1. Read existing `AGENTS.md` first. If it does not exist, create it with only:
- `## Learned User Preferences`
- `## Learned Workspace Facts`
2. Load the incremental index if present.
3. Inspect only transcript files under `~/.cursor/projects/<workspace-slug>/agent-transcripts/` that are new or have newer mtimes than the index.
4. Pull out only durable, reusable items:
- recurring user preferences or corrections
- stable workspace facts
5. Update `AGENTS.md` carefully:
- update matching bullets in place
- add only net-new bullets
- deduplicate semantically similar bullets
- keep each learned section to at most 12 bullets
Prompting technique: Strict minimalism guardrails ("keep each learned section to at most 12 bullets") prevent runaway growth. The incremental index (mtime-based) ensures idempotent runs — the agent only processes what's new. The model: inherit frontmatter defers model selection to the parent context.
Excerpt 3: pstack/skills/poteto-mode/SKILL.md — Subagent Dispatch Pattern
## Subagents
**Use `subagent_type: "poteto-agent"` for any subagent you spawn directly inside a playbook step** (code-writing delegates, ad-hoc helpers). `/poteto-mode` and `subagent_type: "poteto-agent"` route through the same wrapper. Routed workflow skills (`how`, `why`, `interrogate`, `reflect`) configure their own `subagent_type` for diverse-model review and exploration; respect what the skill prescribes rather than overriding it to `poteto-agent`.
**Defaults for every `Task` call.** `run_in_background: true`, agent mode (readonly strips MCP), file pointers not inlined context, and explicit model (`composer-2.5-fast` for code, `claude-opus-4-7-thinking-xhigh` for prose and judgment).
Prompting technique: Multi-model routing embedded in the subagent spawn spec — composer-2.5-fast for code tasks, claude-opus-4-7-thinking-xhigh for prose/judgment. This is one of the few frameworks in the corpus with explicit per-task model assignment. The run_in_background: true default enables true parallel execution.
Excerpt 4: ralph-loop — Completion Promise Pattern
Build a REST API for todos.
When complete:
- All CRUD endpoints working
- Input validation in place
- Tests passing (coverage > 80%)
- Output: <promise>COMPLETE</promise>
Prompting technique: XML-tagged <promise> marker in the prompt body that hooks monitor for. The hook system converts this into a programmatic completion signal. The pattern separates verifiable completion criteria from prose description — the hook watches for the tag, not the quality of the code.