agent-planning-loop

Agent Planning Loop

Use this skill when the user wants the agent system to do the planning debate before asking for a human decision. It is a bounded orchestration workflow, not an implementation workflow.

The point is to capture the useful 80% of agent suggestions while preventing the remaining 20% from drifting into the wrong product direction. Scout workers generate and challenge options; the main session owns judgment, scope control, and the final recommendation.

Boundary

This skill owns:

• deciding whether a planning loop is worth running;
• dispatching bounded scouts for entropy discovery and document-grounded grill;
• filtering candidates for materiality, product fit, and execution risk;
• iterating once or twice when the first pass exposes a better question;
• returning a compact recommendation set for one user review.

It does not own:

• implementation;
• approving its own plan;
• changing public contracts without user review;
• letting workers ask the user directly;
• running paid, slow, hardware, or credentialed probes unless the user already authorized that cost class.

After approval, route execution back through $intuitive-flow, $intuitive-refactor, or a concrete worker prompt.

When To Use

Use this loop for fuzzy or contested work where a normal one-shot answer would likely miss important scope:

• a promising idea needs a clearer plan;
• previous conclusions may be overbroad or stale;
• multiple good suggestions need triage;
• docs, tests, metrics, or agent behavior may disagree;
• the user wants workers to run reduce-entropy and grill-batch before bringing them a synthesis.

Do not use it for one-file fixes, simple status checks, obvious bug fixes, or a plan that already has accepted scope and verification.

When the loop is run against an existing plan artifact, assume the plan is the intended execution unit unless the user asks for slice selection or the plan is plainly too broad for their goal. Scouts may recommend phase order, stop gates, or risk isolation, but the main-session recommendation should not quietly shrink the final action to "only implement slice 1." If only a subset is safe, say why full-plan execution is blocked and ask for that decision instead of presenting the subset as the normal next action.