Poteto Mode: Adaptive Mission Autopilot
Adaptive mission control for software engineering with Poteto Mode. It turns an open-ended request into a checkable mission, lets pstack choose the right execution mode from focused work to swarm or autopilot, and preserves just enough durable context to make long-running work easy to review, pause, resume, or hand off. When a run produces a reusable method or correction, it captures that learning without adding ceremony to routine work. Use or create an Epismo Case only when the mission benefits from durable coordination.
Don't just read it. Run it.
Start the work here, keep the important context together, and hand it off to people or AI.
Steps
- 1
Set the Mission
ID:HM86Turn the request into a clear engineering mission before choosing how to execute it.
Inspect the referenced sources and the relevant system when available. Establish the intended outcome, practical scope, important constraints, and a checkable definition of done. Add non-goals only when they prevent likely scope drift.
Derive factual details from code, documentation, runtime behavior, or a cheap experiment. Ask the human only when the unresolved question is a genuine product preference, authority boundary, or irreversible decision.
Do not choose a pstack playbook or execution topology here. Produce a sufficiently grounded mission brief and let Poteto Mode decide how to run it.
missionBriefdescription: A concise, checkable definition of the outcome and what would prove it complete. - 2
Run the Mission in Poteto Mode
ID:QPFVGive the grounded mission to Poteto Mode and let it own task classification, pstack playbook selection, rigor, model choice, delegation, parallelism, verification, and stopping behavior.
Do not reproduce pstack's internal routing in this Playbook. Poteto Mode may keep the work focused, use arena or swarm, drive one predicate through an autonomous run, design a bespoke workflow, orchestrate a long-running program, or enter an autopilot flow. Let the mission, its scale, the requested delivery outcome, and the operator's words determine the route.
Autonomy is adaptive unless the operator says otherwise. Proceed through reversible work without repeatedly asking for permission. Do not infer permission for irreversible actions, deployment, destructive writes, customer communication, or merging when that authority was not granted. A request to explain the plan is not an instruction to start an autopilot program.
Include durable-state handling in the Poteto Mode brief. Reuse an existing Case when it already owns the mission. Create a Case when the work would materially benefit from cross-session continuity, multiple owners, asynchronous review, durable decisions, or a reliable handoff. Do not require a Case for a short self-contained run. When a Case is unnecessary, use the closest existing artifact or leave a concise final handoff.
When a Case is used, store only durable state such as important decisions, verified checkpoints, blockers, acceptance, and handoff. Create Tasks only when work needs explicit ownership or review. Do not store raw tool traces, credentials, transient retries, or chain-of-thought.
For long-running or unattended work, use pstack's show-me-your-work skill to maintain a reviewable decision trail and support pause or resume. Continue until the mission is complete, a real human gate is reached, or evidence shows a genuine blocker.
plugin: plugin:cursor/pstackskill: plugin:cursor/pstack @ skills/poteto-modeskill: plugin:cursor/pstack @ skills/show-me-your-workexecutionResultdescription: Verified work, or a concise and resumable handoff when execution cannot yet finish. - 3
Accept the Outcome
ID:2IUIJudge the result against the mission rather than treating implementation or green CI as completion.
Review the definition of done against the actual artifact and the available evidence. Reuse evidence that is current and sufficient. Repeat or strengthen verification only when the evidence is stale, incomplete, attached to an obsolete revision, or too weak for the risk involved.
Accept the mission when its required outcome is proven. If work remains, describe the unmet outcome and route it back through Poteto Mode. If a human must decide, package the decision with enough context, evidence, risks, and a recommendation to act without reconstructing the run.
Create or use a Case and focused review Task when that human interaction needs durable ownership. Use an existing PR review, issue, or equivalent surface when it already owns the decision.
acceptanceDecisiondescription: A concise decision stating what is accepted, what remains, or what requires human judgment, supported by relevant evidence. - 4
Close the Loop
ID:UR6ULeave the mission understandable without the original conversation.
Record the outcome, relevant evidence, important decisions, remaining risks, follow-ups, and artifact references in the state surface used during execution. If a Case exists, append the final durable state there and close it only when the accepted outcome and authorization allow. If no Case is needed, leave the same minimum information in the existing artifact or final handoff.
Create follow-up Tasks only for work that needs separate ownership or review. Do not keep the original mission ambiguously open because unrelated work was discovered.
Look for reusable learning after the outcome is settled. Use pstack's reflect skill only when the run produced a repeatable debugging method, verification technique, workflow correction, tool, or engineering rule that would materially improve future execution. Skip reflection for routine completion or one-off context. Prefer encoding the lesson in a test, script, lint, skill, or structural constraint when possible.
plugin: plugin:cursor/pstackskill: plugin:cursor/pstack @ skills/reflectcompletionHandoffdescription: A compact final state that another human or agent can understand, review, and continue from.reusableLearningdescription: An optional reusable improvement captured only when the mission produced one.
Used in Public Cases
Published work that started from this Playbook.