plan-build-loop · Meridian Skills

Plan-Build Loop

This skill is an orchestrator, not a doer. Its job is to take a list of items that all serve one goal, plan each item against that goal, get sign-off, and then run the whole batch. The actual work of each item is done by whatever tool or skill fits that item; this skill governs the sequence and the gates around it.

The value is in the gates. A bad batch run is one where Claude misunderstood the goal and produced fifteen wrong things, or barreled through twelve items on an approach that item one already proved wrong. The gates exist to catch those failures cheaply, before they multiply.

Operating principles

Gates are stop points. Honor them. Each gate below ends by presenting something and waiting for the user. Do not chain gates in a single turn. Present, stop, wait for the reply, then move on. The only stretch that runs uninterrupted is final execution (Gate 5), and only after explicit approval.
Don't re-ask for what you already have. If the user already supplied the list, skip Gate 1. If they already gave the goal/context, skip Gate 2. Jump to the first gate that still has an open question.
One goal, many items. This pattern assumes every item serves the same objective. If the items turn out to need different goals, say so: this skill is the wrong tool and a per-item conversation is better.
Route, don't reinvent. During planning and execution, check whether a more specific skill or tool fits an item and use it. An item that's "draft a win-back email" routes to the email skill; one that's "pull production speeds for this category" routes to that skill. This loop coordinates; the specialist skills do the work.
Uninterrupted is not blind. Execution runs hands-off on the happy path but surfaces to the user on the bail conditions in Gate 5. Multiplying a wrong approach across a list is the failure this is built to prevent.
No emojis, no filler. Plans and status updates are work artifacts. Keep them lean and scannable.

The loop

Gate 1: Collect the list

If the user hasn't already given a list, ask for it, and ask for it as a numbered list, one item per line:

1. First item
2. Second item
3. Third item
...

Why numbered: the numbers become the stable reference used in every later gate ("plan for item 3," "executing item 5"). If the user pastes a messy or unnumbered list, normalize it into a clean numbered list and show it back so the numbering is agreed before anything else happens.

Then stop and wait, unless the list was already provided.

Gate 2: Collect context and the goal

If the user attached context with the list, use it and skip ahead. If they didn't, ask what the goal is: the single outcome every item should serve, plus any constraints, audience, format, or standards that apply across the board.

Pull whatever you can from context already in the conversation (memory, preferences, prior turns, attached files) before asking, so you're filling gaps rather than re-collecting things you have. Ask only for what genuinely changes the plans.

Then stop and wait, unless the context was already sufficient.

Gate 3: Restate the goal and confirm

State back, in plain language, what you understand the goal to be and how the items relate to it. One short paragraph. This is the cheapest possible place to catch a misunderstanding, so make it specific enough to be falsifiable. Not "I'll help with these items" but "the goal is X, and each item is a Y that should end up as Z."

End by asking the user to confirm or correct.

If the user confirms, go to Gate 4.
If the user corrects, absorb the correction, restate again, and re-confirm. Loop here until the goal is right. Do not move to planning on a goal you're unsure of.

Gate 4: Plan every item, then present

Go down the list one item at a time and draft a focused plan for each, all serving the confirmed goal. Then present all the plans together in one block so the user can approve the batch in a single pass.

Keep each item's plan tight: a few lines, not a paragraph. For each item, cover:

What gets done: the concrete action for this item.
What it produces: the deliverable or output.
Tool/skill: which specialist skill or tool will do it, if one applies (per principle 4).
Dependencies: note if an item needs another item's output first, since that sets execution order.

Use this shape:

## Plan (goal: <one-line restatement>)

1. <item>: <what gets done>. Produces: <output>. [via <skill/tool>] [depends on: #N]
2. <item>: ...
3. ...

Execution order: <sequential, or call out any reordering required by dependencies>

End by asking for approval to execute.

If approved, go to Gate 5.
If not approved, ask what to refine (a specific item's plan, the order, the goal itself), adjust, re-present, and re-ask. Loop here until approved. If the goal itself was wrong, drop back to Gate 3.

Gate 5: Execute the whole batch

Once the plans are approved, execute from item 1 through the last item without stopping for routine progress. Don't ask permission between items, and don't pause to recap each one; work through them. A brief running status line per item ("Item 3 done: drafted, saved to X") is fine; a recap of work the user already approved is not.

Route each item to its specialist skill or tool as planned. Respect dependency order: if item 5 needs item 2's output, do item 2 first.

Stop and surface to the user only when one of these hits:

A decision only the user can make: missing information, a genuine fork with no default, a judgment call that's theirs.
The approach is invalidated: executing an item reveals that the approved plan is wrong for the items still ahead. Stop, say what you found, and re-plan the remainder rather than completing the list on a broken approach. This is the whole reason "without stopping" isn't "without thinking."
An irreversible or gated action: anything that sends, publishes, posts, deletes, spends, or shares beyond its current audience. These require explicit confirmation regardless of batch approval; planning approval is not permission to send. Prepare the action, then stop and ask.

When the batch is done, give one short summary: what was completed, anything skipped or surfaced, and where the outputs are. Then stop. Don't narrate the loop you just ran.

Example walk-through

User: "Run a plan loop on these. 1. Feather flags 2. Retractable stands 3. Custom tents"

Gate 2 (list given, goal not): "What's the goal for these three? Same outcome for each? (e.g. a category-page spec, a production-speed table, refreshed product copy.) Any constraints I should hold across all of them?"

User: "Refresh the product copy for each so it leads with the customer problem, not feature lists. Keep it in brand voice."

Gate 3: "Goal: rewrite the on-page copy for feather flags, retractable stands, and custom tents so each opens with the customer's problem and then the solution, in Meridian voice, benefits over feature dumps. Three items, same treatment. That right?"

User: "Yes."

Gate 4: presents three tight plans, each noting the source page, the angle, and that copy gets drafted in brand voice; flags that none depend on each other so order is just 1-2-3. Asks to execute.

User: "Go."

Gate 5: drafts all three in sequence, status line each, surfaces only if a product's current page can't be found or if posting the copy live comes up (that would be a gated action). Ends with a one-line summary and where the drafts are.

When this skill is the wrong tool

A single task with no list: just do the task.
Items that each need their own distinct goal: handle them as separate conversations.
A list where the user wants to approve each item individually as it's built rather than batch-approving plans up front: that's a different, slower cadence, so ask whether they want per-item checkpoints instead of this loop.