---
name: flexible-handling
description: "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."
---

> Original skill · commissioned by the user · English edition, 2026-11-12

# Flexible Handling

**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.

> **This skill is domain-agnostic (hard constraint)**: every rule below is written in generic language, and **the rule layer must not depend on any specific domain**. Examples are illustrations only and come from different domains; when the domain changes, **keep the rules and drop the examples**.

## 1. Watch the early signs (**before the problem explodes**)

Any one of these means you are heading toward solving the head and ignoring the tail: **stop immediately and re-assess the direction** instead of trying once more:

| # | Early sign | Why it is dangerous |
|---|---|---|
| 1 | The same action has been tried **twice** and the path has not changed | A third attempt is almost pure waste; the first two already proved this direction does not work |
| 2 | "**Just try it once more and see**" surfaces in your head | This is the entrance to walking one road until it goes black |
| 3 | **You only want to patch it, you have not checked the root cause** | A patch is luck; even when it works it cannot be reproduced |
| 4 | A report is **all green, but you have not looked at the artifact** | This is where false greens breed — "it passes" must be able to name which items passed |
| 5 | One fact has **two sources that disagree** | A genuine source conflict; settle the source of truth before acting |
| 6 | One change **touches more than one variable** | You cannot separate cause from effect and learn nothing from success or failure |
| 7 | You start **adding budget / adding time** | This signals "the direction of effort is wrong", not "you are not trying hard enough" |

> Pressing one gourd down and the ladle pops up has exactly one root cause: **you fixated on the one spot in front of you and never looked at system coupling**.
> So before any change lands, ask: **"What else will this move?"**

## 2. Irreversibility check (**if the direction is wrong, no amount of later bending brings it back**)

Before starting, sort decisions into two classes and **treat them differently**:

| Type | Criterion | Examples (cross-domain, not exhaustive) | Rule |
|---|---|---|---|
| **Irreversible (directional)** | Getting it wrong means rebuilding the main body; rework cost ≈ starting over | Delivery form (document / interface / page / data), core method (build / buy / manual / automated), target spec (duration / precision / coverage), external commitments | **You must first verify it once at minimum cost** (1 item / 1 page / 1 interface / 1 sample) before scaling up |
| **Reversible (parametric)** | Changeable at any time, cost ≈ 0 | Style, wording, ordering, font, volume, naming, bitrate | Do not agonize over it before starting; it can change at any time |

**The most common crash is treating reversible items as irreversible and agonizing over them repeatedly, while treating irreversible items as reversible and scaling straight up.**

## 3. Universal fallback (**one must already be prepared before you start**)

> **Universal fallback = degraded delivery**: step the goal down from "the ideal form" to "the minimum usable form", and **write it down before starting**.

Three levels of degradation — copy them onto the work order:

1. **Form degradation**: ideal form → simplified form (e.g. full version → condensed version; long document → bullet list of key points; dynamic demo → static explanation)
2. **Scale degradation**: full set → sample (e.g. whole package → build a sample first; site-wide redesign → single-page pilot; full data → sampled data)
3. **Path degradation**: expensive / fragile / restricted path → stable path (e.g. paid cloud generation → tools already available locally; new platform → familiar platform; custom development → off-the-shelf solution)

**Final backstop**: **recombine existing material / existing assets — change only the organization, not the material itself** — under any circumstance this still yields a passing version.

The test is hard: **"If every external means failed, could I still deliver something?"** If you cannot answer, you have not prepared a fallback.

## 4. Already stuck: first ask "is this even the problem" (four questions)

If any one question hits, the earlier conclusion is void and the problem must be redefined:

| Question | Typical hit (illustration, cross-domain) |
|---|---|
| **Is my query / assumption wrong, or is this how it really is?** | Three rounds of "not found" in a row — **my search method is wrong** (e.g. the target name does not contain the keyword I assumed) |
| **Is this path blocked, or is the target unreachable?** | One path being blocked ≠ impossible (e.g. a class of input is rejected by an upstream rule → switch to another input form and it passes) |
| **Did it really fail, or did the signal lie to me?** | The report says "pass" while not a single item was executed (the criterion reads 0) |
| **Is capability missing, or configuration missing?** | It stops with an error — **one parameter was simply not configured** |

## 5. Once it is confirmed to be a problem, list at least three paths of **different kinds**

Three retries of the same kind of change do not count as three paths:

| What you change | Example |
|---|---|
| **Change the input** | Input content / way of describing it / parameters / wording / sample |
| **Change the path** | Raw input → plain text description; multi-step composition → one step; external service → local tool |
| **Change the source of truth** | Rate card / document / list → **actual measurement** |
| **Change the tool** | When the tool's gate blocks a capability the layer below already has, **change the gate**, do not bypass the tool |
| **Shrink the scope** | Validate 1 item / 1 page / 1 copy first, then scale up |

## 6. Handle the variable with the invariant: five methodologies

These are not aphorisms; each comes with a **landing action**:

| Methodology | Source | Landing action |
|---|---|---|
| **Secure victory before seeking battle** | Sun Tzu, *The Art of War*, "Forms" | Confirm "this can win" before starting: verify irreversible items first, **run the free probe first** (wrong parameters, insufficient permissions and rule rejections are mostly blocked before execution and cost nothing) |
| **Engage with the orthodox, win with the unorthodox** | Sun Tzu, *The Art of War*, "Momentum" | The main path delivers, the unorthodox path catches failures — **every plan must carry a backup path**; a plan without a backup path is not a plan |
| **Grasp the principal contradiction** | *On Contradiction* | A problem drags a string of others behind it but only one is decisive: first ask **"which one, if left alone, makes all the rest pointless?"** |
| **Know the other and know yourself** | Sun Tzu, *The Art of War*, "Attack by Stratagem" | Probe the environment before fixing the plan: before integrating any external dependency, run a **capability probe** (what really works / the real unit price / hidden limits) |
| **See things in development** | Dialectical materialism | Today's correct answer expires (prices move, services go offline, rules tighten): **re-assess key parameters periodically and never treat the current conclusion as permanent fact** |

**Landing action for looking at a problem dialectically**: **the strength of every plan is also its weakness**; when listing a plan, list its cost at the same time —
custom = closely fitted / but expensive, slow, heavy to maintain; off-the-shelf = fast, cheap / but bounded by someone else's limits; all at once = fast delivery / but expensive rework; in batches = controllable / but high coordination cost.
**A plan that lists only advantages defers its cost to delivery time.**

## 7. Trial-and-error discipline

1. **Try the free options first**: failures blocked by pre-checks (wrong parameters, insufficient permissions, rule rejections) mostly cost nothing — the cheapest probe.
2. **Change only one variable at a time**, otherwise you cannot tell which change took effect.
3. **Try reversible things first; ask before irreversible ones.**
4. **Set a cost ceiling for every attempt**; stop and report at the ceiling, never raise it on your own.
5. **Keep failures verbatim**: copy error text as-is, do not paraphrase — conflating "blocked by an upstream rule" with "invalid parameter" guarantees the wrong fix next time.

## 8. Anti-patterns (each one has already been paid for)

| Anti-pattern | Symptom | Cost |
|---|---|---|
| Walking one road until it goes black | The same query rewritten three ways, all failing | Two wasted rounds |
| Treating a tool limit as an unreachable target | "The script does not support this mode" → conclude it cannot be done | Give up one step short |
| Trusting a single signal | The report says "pass" so it passed | The deliverable is judged unacceptable |
| Adding budget / time on failure | Instead of changing the approach | Once overran by <N>% |
| Treating "no error" as "no problem" | The script exits silently, the artifact was never written, and you still report "done" | One round of lessons lost |
| Solving the head, ignoring the tail | Fix only the spot in front of you, never check what it moves | Fix one, two pop up |
| Verifying "pass" but never verifying "blocks" | The checker returns ok and you relax; you never fed it one known-bad input | False green, defects flow into the final cut |

> ⚠️ **Landing point (added after a past review)**: this anti-pattern has recurred several times in a row — proof that "a row in a table" does not take effect.
> **Hard action**: before any repair action, write down "what will this make worse" plus one **measurable criterion**; after the repair, run both criteria together.
> Full rules in `memory-compounding` §4, "Repair Gate".

> ⚠️ **A verifiable acceptance action (added after a past review)**: before any checker / gate / validation script goes live, you must **feed it one known-bad input** and confirm it reports the error.
> Observed once: `hook_bridge_check` first judged a final cut "ok", when in fact the frame extraction used fast seeking and grabbed the frame **before** the cut point (the check compared beach against beach); only after shifting all subtitles back 9 seconds did it show that it can actually block (it reported 12 blockers).
> **"It can block one known-bad input" is the evidence that a checker works; "it returned ok" is not.**

## References

- [references/methodology.md](references/methodology.md) — the full expansion of the philosophy / military strategy / experience layers, with sources
- [references/cases.md](references/cases.md) — 10 real cases (including verbatim error text and the reasoning process); the cases come from specific domains and **serve only as pattern illustrations, never as premises for a rule**