pstack: poteto-agent description routes /poteto-mode into a nested runner, which loses Task and the todo list on Cloud Agents

[dev2o]

Summary

pstack/agents/poteto-agent.md describes itself as the "Routing target for /poteto-mode". On a Cloud Agent, a parent chat that follows that literally spawns one poteto-agent to run the whole playbook. That child sits one level below the Cloud Agent, where Cursor does not expose the Task tool and todo_write does not attach to the chat. Every step that needs a spawn or a todo silently degrades. The parent sees one "done" payload and no checklist.

pstack 0.15.1, plugin head f8abedd. Cursor Cloud Agent (web), parent model cursor-grok-4.6-xhigh-fast.

Back story

I ran /poteto-mode fix issue <repo>/issues/139 in a Cloud Agent chat. The bug was a PHP fatal on a set of /g/ pages. The parent read poteto-mode/SKILL.md, matched Bug fix, then spawned Task(subagent_type: "poteto-agent", run_in_background: true) with the issue text and told it to run the Bug fix playbook.

The child produced a correct fix and a PR. Reviewing its transcript afterwards showed the playbook shell around that fix did not run:

• todo_write called 5 times. Every result was success: false, finalTodos: [], initialTodos: []. No todo list ever appeared on the parent chat or the child.
• Child thinking, verbatim: "No Task tool is available, so subagent delegation is impossible. I will perform the investigation and fix myself." Zero Task calls in the child.
• Bug fix step 2: how and why skills were Read, no how/why subagents.
• Bug fix step 3: architect skill was Read, implementation done in-thread, no delegate.
• Opening a PR: no-comments/SKILL.md was Read, Comment Sicko never spawned. No /deslop, no interrogate. PR opened as draft because the child had no ManagePullRequest tool and fell back to the GitHub MCP, whose PAT could not mark it ready.
• No skip: <reason> lines, because there was no todo list to put them in.

Cursor staff confirmed the platform side in the forum thread "Official nesting depth for subagents" (2026-08-10): IDE and CLI allow main → L1 → L2. Cloud Agents allow one level from the main agent. So on Cloud, whatever chat runs the playbook must be the one that spawns how, why, Comment Sicko, and code delegates. Putting the runner one level down guarantees those steps cannot execute.

Why this is a pstack issue and not only a Cursor one

poteto-mode/SKILL.md already says the chat is the owner: "You own this task. Plan, review, verify. Delegate investigation and the fix to subagents, stay in the lead." and "Open a todolist whose first items are the matched playbook's steps."

agents/poteto-agent.md and README say the opposite in practice: "Routing target for /poteto-mode" and "spawn it from a parent agent via subagent_type: "poteto-agent". it reads poteto-mode in full ... substituting generalPurpose skips that read and drifts." A parent reading that treats poteto-agent as the runner for the slash command.

The feature.md step 4 text also tells a delegate "You can spawn a subagent even though you are one" and calls "a subagent cannot spawn one" wrong. On Cloud Agents that is false for any L1 subagent.

Suggested fix

1. In agents/poteto-agent.md, change the description so it is a delegate, not the runner. Something like: "Style wrapper for delegates spawned by a /poteto-mode runner. Do not use as the runner for /poteto-mode itself. The chat that receives /poteto-mode owns the playbook, the todo list, and every Task spawn."
2. In skills/poteto-mode/SKILL.md Subagents section, add one line: "The chat that receives /poteto-mode is the runner. Never spawn a poteto-agent to run the playbook. On Cloud Agents only the main agent can spawn, so every how, why, Comment Sicko, and code delegate must come from the runner."
3. In playbooks/feature.md step 4, qualify the "you can spawn even though you are one" sentence with the Cloud one-level cap, or drop the claim that "a subagent cannot spawn one" is always wrong.
4. README "the poteto-agent and Comment Sicko subagents" section: same reframing as 1.

Repro

1. Open a Cloud Agent on any repo with pstack installed.
2. Send /poteto-mode fix <small bug>.
3. Observe the parent spawn poteto-agent and end its turn.
4. Fetch the child transcript. Grep todo_write results and Task calls. Expect empty todos with success: false and zero Task calls.
5. Compare with the same prompt in the IDE, where the chat itself opens the todo list and fans out how/why.

Related

• pstack: default Task model slugs are unresolvable in current Cursor #335 / pstack: use Task-spawnable default model slugs #336 cover Task model slugs. Different failure. Task exists there and rejects the slug. Here Task is absent.
• pstack: poteto-mode name breaks the documented identifier constraint and fails to load on other harnesses #237 is the poteto-mode name field. Unrelated.