firehose> #llmops
video youtu.be Watch ↗

The whole flow, end-to-end: the smart zone is the unit of work

TL;DR

Matt Pocock's first actual tutorial for his skills repo answers the question people kept asking — what sequence do I use these in? — and in doing so reveals that the pipeline the vault already documents (grill-with-docs → to-spec → to-tickets → implement → code-review) is not really a planning methodology at all: it is machinery for doing work that is bigger than one context window's usable region. He calls that region the smart zone, puts it at ~140k, and — this is the load-bearing detail — is running a model the harness reports as Opus 4.8 (1M context), so he is deliberately planning against about a seventh of the window he has. Everything follows from that one limit. The fork after grilling is decided by it ("we've got 100k of budget here to remove 10 commands — that seems super easy" → skip steps 2 and 3, go straight to /implement); /to-spec exists to compress a 46.1k grilling session into a durable artifact when the work won't fit; a ticket is defined as "the size of a single context window"; you /clear between tickets. So specs and tickets are revealed as pure overhead on work that fits the zone — which is a sharper and more useful rule than "always spec first." Two other ideas earn their own pages: the skills reach backends through a repo-local binding document whose headings are the skill's own verbs (## When a skill says "publish to the issue tracker" → write a file under .scratch/), which is why "how do I make this work with Jira?" is answered "it already does"; and /code-review runs in spawned sub-agents with fresh context windows, because "agents are often really bad at improving code they've just written — they wrote it, so they think that's fantastic, that's fine." That last one sits in productive tension with the vault's Cross-Model Independence, which holds that same-model review is an echo chamber no prompt can fix.

Concepts introduced

Held, not dropped (touched, but not warranting a page yet):

Key claims

Why this builds on the existing graph

Same author, same system, same pipeline the vault already documents from his v1.1 release (Skills v1.1: Wayfinder, the SDLC flow, and naming the artifact right) — so the dominant stance is builds_on. But it is not a duplicate, and the reason is a change of altitude: the v1.1 video documented what the flow is; this one documents what the flow is for. The five steps were already on the page. The fact that steps 2 and 3 exist only to survive a ~140k attention ceiling — and that their own author skips them when the work fits — was not, and it converts a methodology into a conditional.

The tension worth keeping: Context-Independent Review vs Cross-Model Independence

This is the one place the capture pulls against an existing vault claim, and it is worth stating as a tension rather than resolving.

Cross-Model Independence holds — sharply, and as a principle — that "a model cannot be trusted to grade work it authored: its blind spots are properties of the model, so same-model review is an echo chamber that no prompt, persona, or adversarial instruction removes." This video asserts that a same-model, same-lineage sub-agent with a fresh context window does "a much better job" reviewing — and structures its whole review stage on that assertion.

Both can hold, because they name different failures. The vault's page is about blind spots (what the model cannot see at all); this video is about authorship anchoring (what the model will not look at because it just produced it). Clearing the context removes the second and leaves the first entirely intact. But the two claims will read as interchangeable to anyone skimming — "don't let it grade its own work" — and they buy very different things at very different prices. The distinction to carry forward: context independence is nearly free and removes commitment; lineage independence is expensive and removes correlation. A fleet that has bought the first and believes it has bought the second is exactly the failure Cross-Model Independence exists to name. Neither source measured its claim; both are held as attributed hypotheses.

Secondary stances: corroborates toward Spec-Driven Development, Skill Invocation Trigger, and Map-First Planning (same-author, so weak corroboration); novel for the three new pages.

Illustrated walkthrough

Visual coverage is low confidence (sampler audit): the largest un-illustrated stretch is ~30 s, and the last third of the video (t≈720 s → end, covering the real multi-ticket spec, implementation, and code review) is carried entirely by coverage-floor frames on a fixed 30 s grid — i.e. sampled by the clock, not by anything changing on screen. Terminal output and file edits in those windows were not sampled, and the absence of a frame there is not evidence that the screen was static; this sampler is known to miss text-on-solid-background changes, which is most of what a terminal is. Read the walkthrough below as keyed to the frames I could actually read.

Linked from