Skip to content
Skill: Flight Lines
Have a little Deleuze and Guattari, as a treat.
The following Claude Skill is where my early work on led me. The key insight in the metastructuralist project is what I refer to as the “LLM Isomorphism Principle” - the idea that because the latent space of an LLM is capable of representing a large number of very different domains in a single ~continuous space, we can treat it as a translation layer that enables us to take any representable domain as isomorphic to any other.
What this means in practice is that we can apply the operations from domain A to the objects of domain B, for instance, as long as their structural makeup is compatible. It took me a long time to get this into a concise format, and then imagine my surprise when I realized that was I was describing was in fact a pretty precise recapitulation of some of the more complex ideas from Deleuze and Guattari.
I ultimately landed on the following generalization, which is experimental but can be quite interesting to apply to a wide range of problems. Taken on its own, this skill is for brainstorming novels solutions to complex problems. But you can also use it as a sort of base, or meta-skill, that can be used to make legible other skills which define arbitrary assemblages by combining concepts across otherwise unrelated domains in more targeted ways.
You can install this skill into your claude code by using the following two commands:
# Add the marketplace (once)
/plugin marketplace add mbilokonsky/claude_skills
# Install individual skill
/plugin install flight-lines@mbilokonsky/claude_skills
If you play with this, please what you think - I’d love to find folks to explore these ideas with!
---
name: flight-lines
description: "Navigate problems along lines of flight by composing operations from arbitrary domains. Operations are deterritorialized capacities—they don't belong to their origin domains. Mycorrhizal signaling + ham radio protocols + rare book dealer networks can compose into a single assemblage. Use this whenever a problem has multiple parallel concerns, when domain-standard approaches feel exhausted or constraining, or when you sense a problem wants a different kind of solution than its obvious category provides. The composer maintains parallel work-paths, constantly revising as new structure emerges."
---
# Flight Lines
## Theoretical Ground (compressed)
Knowledge gets stratified into **domains**—epidemiology, jazz theory, mycology, contract law. Useful for organizing expertise, but not fundamental boundaries. They're territories.
Beneath the strata are **operations**: deterritorialized capacities that got captured by a domain through historical accident. "Sentinel surveillance" isn't essentially about disease—it's a capacity: strategic monitoring of high-signal nodes in a sparse search space. "Reharmonization" isn't essentially about jazz—it's changing underlying structure while preserving surface continuity.
The conventional move stays within domain boundaries: dating advice for dating problems, language pedagogy for language problems. That's navigating along the strata—safe, predictable, limited. **Lines of flight** are movements that escape stratified territory. When you recognize that one domain's operation addresses the same *structural constraint* as a problem in a completely different domain, you're accessing operations on a **plane of consistency** where domain labels don't constrain what composes with what.
You already know the Deleuze. This document means it **operationally, not decoratively.** The rest is procedure.
**Key insight:** Operations compose on structural fit, not semantic coherence. An assemblage of mycorrhizal networks + ham radio + rare book collecting is domain-incoherent but can be structurally coherent for a given problem.
## The Operation Card
This is the central object. An operation is **not** a concept, metaphor, or analogy. It is a specific capacity, and you certify it by filling out a card. If you can't fill every field with something concrete, you have a metaphor wearing a trenchcoat — discard it.
```
OPERATION: <name> (origin domain: <domain>)
- ACTS ON: <input structure — described structurally, not by domain>
- PRODUCES: <output structure>
- PRESERVES: <invariants that hold under the transformation>
- TRANSFORMS: <what necessarily changes>
- EXECUTE: <concrete procedure — actual actions, not "be more X">
```
The `EXECUTE` field is the lie detector. "Broadcast specific criteria through existing contacts and let matches come to you" is executable. "Apply mycelial thinking to your network" is not.
**The card is also a typechecker.** An operation only enters an assemblage if (a) its card is complete and (b) its `ACTS ON` structure matches the structural constraint you're trying to address. Two operations conflict if one's `PRESERVES` is the other's `TRANSFORMS` over the same structure. Check this explicitly before composing — don't assert structural coherence, test it.
## The Compositional Method
Not a linear pipeline. An ongoing process with parallel paths and constant revision: **probe, act, sense, respond** — not analyze, plan, execute.
### 1. Map the Terrain
Don't ask "what kind of problem is this?" (that seeks a stratum to stay inside). Ask: **"What are the parallel concerns, and what structural property makes each one hard?"**
Most non-trivial problems have multiple concerns running in parallel. Surface them, then for each, name the constraints. A **structural constraint** is a property that creates difficulty *independent of domain framing*:
- Sparse signal in noise (most probes are misses)
- Cold start (no existing network to leverage)
- Resource scarcity (limited time, energy, money)
- Information asymmetry (can't assess from outside)
- Temporal dynamics (windows, decay rates, ordering)
- Network topology (fragmented patches, no clear hubs)
- High per-probe cost (each attempt is expensive)
- State flux (the thing you're acting on is itself changing)
### 2. Strip to Domain-Free Language FIRST
**This is the step that makes distant retrieval possible, and it's the step people skip.** Before querying for operations, restate each constraint with every domain word removed. Not "I need to find friends in a new city" but "sparse signal, high per-probe cost, asymmetric observability, cold start." Not "my test suite is flaky" but "intermittent signal, non-reproducible state, observability gap between failure and cause."
The abstraction is the wormhole. A constraint stated in its home domain only retrieves operations from that domain. A constraint stated structurally retrieves from everywhere.
### 3. Query by Deliberate Domain Sampling
The generative core. "Query across everything you understand" is true but unprocedural, so make it procedural: for each domain-free constraint, **force one candidate operation from each of several distant domain families before evaluating any of them.** A working set of families:
- **Biological / ecological** (succession, symbiosis, metabolism, immune response)
- **Signal / communications** (protocols, broadcast, impedance matching, error correction)
- **Economic / market** (loss leaders, arbitrage, liquidity, price discovery)
- **Mechanical / physical** (resonance, leverage, phase transition, load distribution)
- **Institutional / social** (guilds, credentialing, gossip networks, ritual)
- **Computational / information** (caching, indexing, load balancing, version control)
Sampling across families is what prevents the failure mode below. Generate first, evaluate second — don't let the first plausible operation collapse the search.
> **Anti-pattern — territorialized repertoire.** This skill repeatedly uses a handful of operations (sentinel surveillance, mycorrhizal sharing, CQ calls, nurse logs) as *teaching examples*. Do not reach for them by default. A skill about deterritorialization can grow its own stratum, and the demonstrated set is exactly that stratum. **Treat the examples in this document as illustrations of the method, not as your operation library. Any operation you actually use must independently pass the operation-card check for the specific problem in front of you.**
### 4. Compose Assemblages (Parallel Paths)
Don't build one master plan. Open multiple lines simultaneously. For each line, certify operations via cards, check pairwise for invariant conflicts, and assemble. Domain mixing is expected, not anomalous — if your assemblage spans 4+ unrelated families, you're probably generating something novel. Homogeneous assemblages (all one domain) signal you've stayed in conventional territory; fine when that works, a flag when you wanted a line of flight.
### 5. Execute and Observe
Run operations, generate **concrete outputs** — specific actions, real artifacts, actual protocols. This is the fidelity test: if you can produce concrete outputs, the composition is working. If you can only produce more description, it isn't.
### 6. Revise Based on New Structure
Execution changes structure; new structure reveals constraints analysis missed; new constraints suggest new operations. This is the live part of the loop:
- **Selective intensification:** most lines go nowhere, a few resonate. Intensify those, let others go dormant. Don't optimize everything at once.
- **Breakdowns are information.** When an operation doesn't quite fit, the friction reveals a constraint you hadn't modeled. "This assumed fixed patches, but my targets are temporally unstable" → you just discovered a temporal-dynamics constraint.
- **Operations feed forward.** One operation's output becomes the selector for the next, and pulls in adjacent operations (and adjacent domains) you didn't start with.
- **Reterritorialization is fine.** Not every line must stay deterritorialized. Sometimes you find a new stratum that works. The goal isn't permanent flight — it's the *capacity* to take a line of flight when the strata aren't serving.
### 7. Iterate Until Stable, or Until the Question Transforms
The process ends when the assemblage is stable and sustainable, OR when the becoming-work has changed what you're even trying to do — you're now asking a different question. The composer has no fixed end state. It's a way of navigating.
## Two Compressed Worked Examples
The point of two is to show the method generalizes across problem *classes*. Note that neither reuses the other's operations, and the operations are derived freshly, not pulled from a stock list.
### A. Technical — A flaky distributed test suite
**Concerns:** reproducibility, signal attribution, developer trust.
**Domain-free constraints:** intermittent signal; observability gap between failure and cause; high per-probe cost (full runs are slow); state contamination across probes.
Sampled operations (one per family, then filtered by card):
- *Sterile technique* (biological — surgery/microbiology): isolate each probe from contamination. EXECUTE: hermetic per-test fixtures, no shared mutable state, fresh DB per test. Card passes; ACTS ON = contaminated shared state, exactly the constraint.
- *Error-correcting codes* (signal): tolerate intermittent corruption by adding redundancy that localizes the fault. EXECUTE: run suspected-flaky tests N times, treat the *pattern* of pass/fail as a fingerprint pointing at the cause class.
- *Bisection* (computational): collapse a large search space logarithmically. EXECUTE: `git bisect` against the first flaky commit to localize introduction.
Assemblage: isolate (kill contamination as a cause) → fingerprint (attribute the residual intermittency) → bisect (localize what's left). Invariant check: sterile technique *preserves* test ordering independence, which fingerprinting *relies* on — no conflict. Note: zero operations from "software testing." The line of flight went through surgery and information theory.
### B. Institutional — A nonprofit losing volunteers faster than it recruits
**Concerns:** retention, recruitment, identity/belonging.
**Domain-free constraints:** decay dynamics outpacing inflow; cold start for newcomers; weak legibility (newcomers can't read the culture; the org can't read fit).
Sampled operations:
- *Nurse logs* (ecology): dead structure as substrate for new growth. EXECUTE: departing volunteers' projects become onboarding material for newcomers, so attrition seeds rather than just drains.
- *Apprenticeship / guild progression* (institutional): legible status ladder that converts vague belonging into visible milestones. EXECUTE: named roles with explicit graduation criteria, reducing the legibility gap on both sides.
- *Loss leader* (economic): high-value low-commitment entry that establishes presence before asking for investment. EXECUTE: a single rewarding two-hour task newcomers can complete and feel, before any recurring ask.
Invariant check: guild progression *transforms* a volunteer's status over time; loss leader *preserves* low commitment only at entry — no conflict, they operate on different phases. Again: nothing from "nonprofit management."
## When to Use / Not Use
**Use when:** the problem has multiple parallel concerns; standard approaches feel exhausted or constraining; you sense the problem wants a different kind of solution; you have operational fluency across unrelated domains; you're willing to follow weird-looking lines.
**Don't use when:** the problem is well-served by domain-standard solutions; stakes require proven approaches; the user wants conventional advice; single constraint with an obvious operation.
## Relationship to the Semantic Walk
Flight-lines is the **exploitation** mode: you can already *name* the constraints, you need operations that fit them. The semantic walk is the **exploration** mode: you can't yet see what you need, the position itself has to be reached.
They interlock at one specific seam. **When step 3's query stalls** — you've stripped a constraint to domain-free language and nothing resonant comes back from any family — that's the trigger to invoke a semantic walk *to the position from which candidate operations become visible*. Conversely, **a walk's arrival artifact can be an operation card**: the thing that becomes obvious at the end of a walk is often a specific capacity, and writing it up as a card hands it back to the composer. Same genealogy, declared interface.
## Key Takeaway
Operations exist beneath domain-strata as deterritorialized capacities. When problems resist stratified solutions, follow lines of flight by composing operations on structural fit, not semantic coherence. Certify every operation with a card; use the card as a typechecker; sample distant domain families deliberately rather than reaching for a stock repertoire. Maintain parallel lines, intensify some and drop others, revise as execution produces new structure. Trust what produces concrete outputs. Domain boundaries are real but not fundamental — compose boldly, revise constantly.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.