Working with the agent

Blocker handling

Before concluding it cannot be done: check the signs, re-judge, then open several different routes.

Free Free to read and free to ask for by email.

Background

Core: real flexibility is not coming up with more options after you are stuck — it is switching direction the moment the first sign appears; the wrong direction gets harder to turn back the further you go.

Why it is built this way

The first section is a stop list. Flexibility here means switching when the first sign appears, and the signs are checkable without judgement: the same action tried twice with no path change, one change touching more than one variable, a plan starting to add budget or time. Adding budget is read as evidence that the direction is wrong, since more effort on the same road was already tried. The four questions follow because a blocked path is often a wrong query or an unconfigured parameter, and both look like cannot be done.

The irreversibility split decides where the first two minutes go. Delivery form, core method, target spec and external commitments cost roughly a rebuild when wrong, so one item, one page, one interface or one sample gets verified before scaling. Style, wording, ordering, font, volume, naming and bitrate cost nothing to change and are not worth agonizing over before starting. The fallback is written down before work begins as three degradation levels plus recombining existing material, because the test of whether delivery survives every external means failing cannot be answered afterwards.

Where it bites

• Walking one road until it goes black The same error gets rewritten three ways and tried again, the third attempt wasted, then budget and time get added as if the direction were fine. Signs 1, 2 and 7 stop this: two attempts with no path change, the thought of trying once more, and any move to raise budget or time.
• All green with the artifact unread A checker returns ok and the delivery is called passed, while frame extraction sought to the frame before the cut point and compared two identical shots. The acceptance action feeds every checker one known-bad input before it goes live. Returning ok is not evidence, blocking a known error is.
• A tool limit read as an unreachable target The script answers that this mode is unsupported and the whole task gets declared impossible, while the capability sits one layer down and only the tool's own gate is in the way. Question 2 separates a blocked path from an unreachable target, and the method table answers change the gate, do not bypass the tool.
• Paraphrasing an error instead of copying it Blocked by an upstream rule gets rewritten as an invalid parameter, so the next fix adjusts the parameter and the same rule blocks it again. Trial-and-error rule 5 asks for the error text verbatim, because a lost qualifier guarantees the wrong fix.

Inside this skill

1. 1. Watch the early signs (**before the problem explodes**)
2. 2. Irreversibility check (**if the direction is wrong, no amount of later bending brings it back**)
3. 3. Universal fallback (**one must already be prepared before you start**)
4. 4. Already stuck: first ask "is this even the problem" (four questions)
5. 5. Once it is confirmed to be a problem, list at least three paths of **different kinds**
6. 6. Handle the variable with the invariant: five methodologies
7. 7. Trial-and-error discipline
8. 8. Anti-patterns (each one has already been paid for)
9. References

The outline is the skill file's own headings, in the order it uses them.

When to use it

Use this when you hit a blocker, an error, a rejection, or are about to conclude 'this cannot be done' — watch the early signs first, then re-judge the problem, then open several paths of genuinely different kinds; and complete the irreversibility check plus a universal fallback before starting work. Use it for troubleshooting, external platform obstacles, a rejected plan, the same step failing repeatedly, and risk prevention before starting. Not for routine implementation with no obstacle.

How to use it

1. Ask for the file by email — it is a single SKILL.md.
2. Put it in the skills folder your agent reads, in a directory named flexible-handling.
3. Start a message with the trigger from the description, or name the skill directly.