ungate-queue

ungate-queue — remove the gate, then stop

An unattended run produces two piles. The autonomous pile gets done without the user. This skill is the other half: the gated pile, walked WITH the user. The user's presence is the whole premise, so nothing here is deferred or guessed.

This pass spends user attention, not compute. That is what makes it the right pass to run when compute is scarce or expensive — but only while it stays cheap. The moment it starts doing the work it unblocked, it costs both, and the property that made it worth running is gone.

The boundary: record and return

Your output is a changed gate state, not a changed repository. For each item: ask, record the answer on the item, retier it, move to the next one. Then hand the released pile to a later unattended run.

Concretely, per item you are done when:

1. The answer is written onto the item itself, in enough detail that a fresh session could act on it without you in the room.
2. The item's verdict is updated through the queue's own interface — no longer gated, or still gated with a smaller reason.
3. You have moved on.

You are NOT done-and-continuing. Do not open the files. Do not start the fix "while we are here". If an item is one line of work and the temptation is strong, that is exactly the case to resist: releasing thirty gates in one attended sitting is worth far more than releasing four and fixing one.

Only the FIRST gate is yours. An item often has a second blocker behind the first. Remove the one in front, record what is now known about the next, and let the item come back around. Chasing a chain to its end turns one question into a project.

Rank the gated pile by how cheaply it can be released

Gated is not one flat bucket. Items differ enormously in what an answer buys, so present the cheapest-to-release first. Ask in this order:

• G1 — one answer, gone forever. A single answered question removes the gate permanently. Highest value per unit of attention. These are what this pass exists for; ask them first, always.
• G2 — an installation something already does. The gate is a setup step an existing script or documented command already performs, so it costs little or nothing to clear. Still cheap, still good.
• G3 — a custom installation. Clearing it needs real work: trying approaches, testing, iterating. Genuinely harder, so it must not crowd out G1 and G2. Surface it after them.
• G4 — not an ungating candidate at all. The gate is constant multi-step user interaction while the task runs. There is no answer that releases it into autonomy; the task simply has to be done attended. Keep these at the back and raise them only if the user explicitly asks. Naming one as attended work is a complete result.
• ENV — a recurring precondition, not a failure. An external condition that will be true sometimes and false at other times: an application must be running, a particular network must be joined, a device must be plugged in. These can never be permanently removed and must not be reasoned about as though they could be. Mark them once as recurring, and thereafter the only question is "is the condition true right now?" — never "how do we solve this?".