Prototype risky steps early instead of discovering failure in the middle of implementation.
Prefer a separate subagent when the prototype is likely to create noisy context: failed attempts, dead ends, environment tweaking, or broad exploration.
Keep prototyping in the main agent only when it is small, fast, and unlikely to generate irrelevant detail.
The main agent should retain the final working idea, not the full trial-and-error history.
Use
before implementation. First prototype the packaging and test flow in isolation: build inside distro-specific containers, validate dependency availability, and check which architecture combinations can be tested locally. If the host architecture does not match the target, prefer a separate subagent to research and prototype the viable path: native containers, extensive web research, cross-compilation, or remote/CI builds, depending on context and available tools/hardware capabilities. Return only the working matrix, rejected approaches, required environment setup, and constraints. Then update the plan if needed and implement the real packaging workflow.
Use
before trying another patch. Isolate the failing assumption and create a small reproduction or spike outside the main implementation path. Prefer a separate subagent if debugging will involve noisy trial-and-error across logs, environment settings, network behavior, or library internals. Return only the confirmed root cause, the working fix strategy, constraints, and any setup needed to verify it. Then update the plan if needed and apply the real fix cleanly instead of continuing ad hoc patches.