how
How
Read the installed poteto-mode reference ../poteto-mode/references/t3-execution.md before selecting models or delegating. It owns named-role resolution, catalog option keys, accounts and automatic authorized missing-usage fallback.
Explore the codebase to answer "how does X work?" questions. Produce architectural explanations at the level of a senior engineer onboarding onto a subsystem, enough to build a working mental model, not so much that it reads like annotated source code.
Every spawn is a read-only delegate_task child with mode: "async" and a self-contained brief. Explorers use the how explorer line in pstack-models.md, and every explainer uses the how explainer line. Resolve a missing line from that role's bundled default at xhigh reasoning through live catalog option keys unless the user chooses a budget. For auto or inherit-parent, resolve the parent target. Handle rejected entries through the execution adapter's authorized fallback preserving effort and required diversity and say so. Retain task IDs, once nothing independent is left, end the turn until their completion notifications wake you, then read each result with task_status, and task_cancel only a child whose status is not terminal. T3 child agents get only the brief, never the parent's context. Set each subagent's reasoning level and speed per the Subagents section of the poteto-mode skill.
1. Assess complexity
If the scope is ambiguous, state your interpretation and explore. The user can redirect.
- Simple (a single module, a small utility, a narrow question such as "how does function X work"): no explorers. Spawn one explainer that explores and explains in one pass, built from
references/explainer-prompt.mdwithout the explorer-findings section. Go to step 4. - Complex (a subsystem spanning multiple files or services, a cross-cutting feature, a full architectural overview): go to step 2.
When in doubt, take the simple path.