Pull One Thread

Pull One Thread

Here is one prompt spec, broken into clauses — a reader, a task, a tone, a format, an example, some jargon, and a couple of decorations. Pull any one clause and the playground shows you the truth most specs hide: some clauses silently re-read when a thread they depend on changes, and some never move at all. The moat is what it exposes — the transitive dependents, the clauses that shifted without ever naming the thing you pulled. That is the exact failure mode that quietly breaks prompts, requirements, and design tokens in production. Runs entirely in your browser (0 uploads, works offline).

How to use it

1. Read the prompt spec — each [bracketed clause] is a live token you can pull.
2. Click a clause, or use a preset — Pull a load-bearing clause or Pull a cosmetic clause.
3. Watch the spec light up: the clause you pulled, the clauses that re-read (amber), and the ones that stayed put (dimmed).
4. Open the X-ray to see which movers depend on your clause directly and which moved through a hidden, transitive chain.
5. Copy or share the result — the count of clauses that moved without naming what you touched is the number worth arguing about.

What this clears up (the fundamentals)

• A change ripples along dependencies, not along the words — a clause can move because something it depends on moved, even if it never mentions what you changed. Following the text misses these; following the graph catches them.
• Load-bearing vs. cosmetic is measurable — pull a token and count the transitive dependents. Two or more and it is load-bearing; zero and it is decoration. "This one is important" becomes a number.
• The dangerous dependents are the invisible ones — the direct dependents are obvious; the two-hop ones (the example that depends on the format that depends on the reader) are where drift hides. One pull outs every one of them.
• A single source of truth beats a hardcoded copy — every clause that references a token moves with it; every clause that hardcoded a value silently does not. That gap is the token-drift bug.

Where it's used

A top-of-funnel design-systems and prompt-engineering check — the fastest way to feel why "just change this one value" is never just one value. It is a miatz build-lab concept playable: play it here, then learn to build the dependency graph, the reverse-BFS, and the structural reveal yourself in the module Design Systems an Agent Can Read.

FAQ

What does "pulling a thread" actually mean?

You change one token in a spec. The engine then walks the reverse-dependency graph to find every other clause whose meaning depends on it — directly or through a chain — and marks the rest as unaffected. Nothing is edited; it is a what-if trace.

Why did a clause move when it never mentions the token I pulled?

Because it depends on something that depends on your token. If the example depends on the format, and the format depends on the reader, then changing the reader re-reads the example — two hops away. Those transitive movers are the whole point of the playground.

What makes a clause "load-bearing" versus "cosmetic"?

Pull it and count the transitive dependents. Two or more moved clauses and it is load-bearing; zero and it is cosmetic. A cosmetic token (an emoji, a title) can be edited freely because nothing reads it.

Is anything uploaded?

No. The spec, the dependency graph, and the whole trace live in your browser — nothing is transmitted, stored, or logged. Turn off your Wi-Fi and it still works.

Limits

A teaching model with one fixed spec and a hand-built dependency graph — it shows the shape of token dependency and prompt sensitivity, not a linter for your real prompts or design tokens. Production graphs are larger, cyclic-adjacent, and messier. The lesson it names — trace dependencies, not words, and treat a token as a single source of truth — is exactly the real practice.

Related

Part of the miatz playgrounds. Explore the rest from the playground catalog.

Bookmark this page (Ctrl+D, or ⌘D on Mac) — it works offline the next time you need it.