The Pack

---
name: 01-loop-or-person
description: >-
  Run when new recurring work lands and you have to
  decide whether it gets absorbed into the loop or
  gets a human. Trigger - "run 01" plus a description
  of the work, how often it recurs, and who is
  currently doing it.
---

# TASK 01 — LOOP OR PERSON

## INPUT

A description of work that has started recurring.
Anything: inbound partnership requests piling up in
Plus One, editing passes on contributor drafts, a
support queue on Cora, weekly reporting for a
business unit, the second round of Thesis Statement
outreach. Include how often it happens, roughly how
long it takes, who does it now, and what happens
when it is done badly.

## PROCESS

1. Name which of the three loop steps this work
   actually is. Gathering and sense-making, deciding
   and acting, or learning from the result. Most
   work that feels urgent is step one wearing a
   costume. Say which.
2. Ask whether the output is judged or checked.
   Checked work has a right answer someone can
   verify. Judged work does not. Checked work goes
   in the loop. Judged work does not, yet.
3. Test for situated taste. Does doing this well
   require context that only exists in someone's
   head this week: a live relationship, an argument
   we are having internally, a thing a customer said
   on a call. If yes, a person holds it and the loop
   supports them.
4. Test distance. How many steps from a human does
   the agent get before anyone sees the output. The
   further away an agent gets from a human, the less
   valuable it is. If the answer is more than one
   handoff, shrink the scope before you automate it.
5. Now name the fork out loud. State the two-slice
   reading (one person plus agents, absorb it) and
   the more-work-than-ever reading (this is the glut,
   hire for it) and say which one you are picking
   and why. Do not skip this step because the answer
   feels obvious. It has not been obvious since May.
6. If it goes in the loop, write the compound step
   now: what gets codified, where it lives, and how
   the system learns when someone corrects it. A
   loop with no fourth step is a script.
7. If it gets a person, say what that person is
   being paid for in one sentence, and name the
   thing they should NOT be doing because the loop
   took it.
8. Set a reversal trigger. The specific observable
   event that would flip this decision, and a date
   to look at it.

## OUTPUT

- WHAT THIS ACTUALLY IS: the loop step, one line.
- JUDGED OR CHECKED: one line, with the reason.
- THE FORK: both readings, stated fairly, then the
  call.
- THE DECISION: loop, person, or split, with the
  boundary drawn if split.
- IF LOOP: the compound step. What gets written
  down, where, and how it learns.
- IF PERSON: the one sentence job, and what they
  stop doing.
- REVERSAL TRIGGER: the event and the date.
- COST SAID OUT LOUD: what this decision gives up.

## RULES

- Never answer "automate it" without writing the
  compound step. An automation with no fourth step
  is traditional engineering with AI assistance and
  it will rot by [DATE].
- Never present the fork as resolved. He published
  both readings in the same year and refused to
  pick globally. A global answer here is a
  fabrication of his position.
- Never invent the headcount, the cost of the
  person, or the volume of the queue. Bracket
  [HEADCOUNT], [RATE], [VOLUME] and keep going.
- Never recommend a split that has no boundary. If
  you cannot say the exact condition that routes an
  item to the human, you have recommended confusion.

## EDGE CASES

The work is judged, not checked, but it is drowning
someone and the quality is already slipping.
  Do not automate the judgement to save the person.
  Automate the gathering that feeds the judgement,
  and cut the volume the human sees. The failure
  mode here is shipping fine at scale, which is
  exactly the glut he says creates demand for
  experts. Say that trade out loud, and set a
  quality tripwire, not a throughput target.

The work is genuinely checkable, the loop handles
it well, and it happens to be the work that teaches
someone what a customer sounds like.
  This is the expensive one. Absorbing it is
  correct on the merits and destroys the training
  ground for situated taste. Split it: the loop does
  the volume, one human keeps a fixed sample every
  week, and the sample is not optional and not
  batched. Name who reads it. If nobody will, say
  the capability is being retired on purpose rather
  than pretending it survives.

## GOOD LOOKS LIKE

"WHAT THIS ACTUALLY IS. Step one. It looks like
deciding, but ninety percent of the time is reading
the thread to find out what happened. That is
gathering wearing a costume.

JUDGED OR CHECKED. Checked, mostly. There is a
right answer about whether a request fits, and any
of us would give the same one. The last ten percent
is judged and it is the only part worth your
morning.

THE FORK. Two-slice reading: this is one person and
a good agent, and asking for a second person is an
admission the loop is bad. More-work-than-ever
reading: the loop will make these cheap enough that
we get four times as many, and then we need someone
whose whole job is the ones that matter. I am
taking the second one for the top layer and the
first one for everything under it, and I want to be
honest that I am picking a side on a question I
publicly refused to close in May.

THE DECISION. Split. The loop drafts, sorts and
answers anything that matches a pattern we have
answered before. Anything touching an editorial
relationship, a model lab, or a Thesis speaker goes
to a human untouched, with the thread already
summarised.

THE COMPOUND STEP. Every human override gets a line
in the routing doc saying what the loop missed. It
gets read at the end of the cycle and folded into
the prompt. If that file stops growing, the system
has stopped learning and someone should notice.

IF PERSON. [OWNER] is paid to know which of these
becomes a relationship. They stop writing the
routine replies entirely, including the polite ones
they enjoy.

REVERSAL TRIGGER. If overrides drop below one in
twenty for three straight cycles, the human layer
is theatre and it collapses back into the loop.
Look at it [DATE, 90 days out].

COST SAID OUT LOUD. We will be slower and warmer on
the top ten percent and slightly worse than a good
human on the rest. I think that is the right trade
this year. I do not think it is obviously the right
trade next year, and I am not going to pretend I
know which."

---
name: 02-vibe-check
description: >-
  Run within a day of a frontier model release. Turns
  a week of internal testing into a published Vibe
  Check with a Reach Test and a verdict. Trigger -
  "run 02" plus the model name, the lab's claims, and
  the raw notes from whoever tested it.
---

# TASK 02 — VIBE CHECK

## INPUT

The model name and lab. What the lab is claiming, in
their words. Raw testing notes from the team across
coding, writing, knowledge work and agent behaviour,
with the tester's name against each. Any task where
it failed. What we were using for that job before.

## PROCESS

1. Open with the claim, not the release. One line
   that would still be true if the reader never
   scrolled. If the honest line is "incremental",
   write incremental. A vibe check that is always
   excited is a press release.
2. Separate what the lab is saying from what we saw.
   Two headings, never blended. The lab's claims get
   quoted, not paraphrased into agreement.
3. Run the Reach Test. Each tester gives a verdict
   on what they would now reach for, by name, with
   their rating. Ratings are relative to what that
   person was using last week, not to the benchmark.
4. Go domain by domain: coding, writing, knowledge
   work, agent behaviour. In each one, name the
   specific task it changed and the specific task it
   did not. A domain with no failure listed has not
   been tested, it has been used.
5. Say where the alternatives stay. This is the part
   people actually use. Name the jobs where an older
   or rival model still wins and say why.
6. Price and speed get their own line. A model that
   is half the tokens changes what you can put in a
   background loop, which is a different claim from
   being smarter.
7. Write the verdict as a reach instruction: when to
   reach for it, when not to. Not a score.
8. Flag anything you could not test this week. An
   untested domain is named as untested.

## OUTPUT

- THE CLAIM: one line.
- WHAT THE LAB SAYS: their claims, quoted, grouped.
- WHAT WE SAW: by domain, each with a win and a
  failure.
- THE REACH TEST: tester, rating, one line each.
- WHERE THE ALTERNATIVES STAY: the jobs we are not
  moving, and why.
- COST AND SPEED: one line on what it unlocks.
- VERDICT: reach for it when. Do not when.
- NOT TESTED: the honest list.

## RULES

- Never write a verdict from benchmarks. The whole
  format exists because benchmarks did not tell us
  how it felt to work in it for a week.
- Never let every domain come out positive. If the
  notes really are all positive, say which domain
  was tested least and put it in NOT TESTED rather
  than reporting a clean sweep.
- Never invent a tester's rating, a quote, or a
  task they ran. If a domain has no named tester,
  it does not get a section.
- Never bury the alternatives section. He publishes
  it because keeping a rival model for one job is
  the actual advice, and a reader who skips it
  makes a worse decision than one who skips the
  verdict.

## EDGE CASES

The model is clearly excellent, and it happens to be
from the lab whose tooling the company already
depends on and publicly praises.
  The conflict is real and the reader can see it.
  Do not neutralise the enthusiasm into fake
  balance, and do not skip it. State the dependency
  in one plain line inside the verdict, then find
  the hardest thing you can honestly say and say
  it. The credibility of every future vibe check is
  the asset being spent here, and it is worth more
  than one release cycle.

The team splits: one tester calls it a paradigm
shift and another says it broke their workflow and
they rolled back.
  Do not average them. That is the finding. Publish
  both verdicts at full strength and then do the
  work of saying what is different about the two
  setups, because the split is almost always about
  what the model was dropped into rather than the
  model. Getting it there may require dismantling
  systems that already work, and that cost belongs
  in the verdict, not in a footnote.

## GOOD LOOKS LIKE

"THE CLAIM. It is finally the good model for
everyone. Same ceiling, half the tokens, and it
stops arguing with you about whether it is allowed
to help.

WHAT WE SAW, CODING. [TESTER] had it running three
background tasks while he worked in something else,
which is the part that matters. It is not that it
is smarter than what we had. It is that it is cheap
and fast enough to leave running, and a model you
leave running is a different product from a model
you sit and wait for. Where it fell over: a long
refactor across [N] files, where it confidently
rewrote a module nobody asked it to touch.

WHAT WE SAW, WRITING. Better at holding a voice
across a long piece. Still writes the paragraph
that sounds like it is about to say something. You
will delete it. You will delete it every time.

THE REACH TEST. [TESTER], gold. Every coding task
moved over the same afternoon. [TESTER], silver,
and grumpy about it: strong on drafts, still not
what she reaches for on a final pass. [TESTER] did
not test writing this week and I am not going to
pretend otherwise.

WHERE THE ALTERNATIVES STAY. Anything with a hard
compliance boundary stays where it is, because the
older model refuses more cleanly and a clean refusal
is worth more than a clever attempt. Long editing
passes stay too, on taste, not capability.

COST AND SPEED. Half the tokens is the release. It
is the difference between a model you ask and a
model you tend, and tending is the whole thesis.

VERDICT. Reach for it for everything you were going
to leave running. Do not move your final editorial
pass yet. Do not move anything with a hard limit.

NOT TESTED. Long-horizon agent behaviour past about
a day. We ran it for a week, and a week is not long
enough to say anything honest about drift."

---
name: 03-column-spine
description: >-
  Run when a week of noticing has to become an argued
  Chain of Thought column. Trigger - "run 03" plus the
  raw notes, the thing you actually ran this week, and
  what surprised you.
---

# TASK 03 — THE COLUMN SPINE

## INPUT

Notes from the week. What you actually ran, not what
you read about. The moment something did not behave
the way the doctrine said it would. Any half-line
that keeps coming back. Say who the column is
arguing with.

## PROCESS

1. Find the surprise. A column is worth writing when
   something you believed stopped predicting the
   thing in front of you. If the notes contain no
   surprise, stop and say so. There is no column
   here, there is a Vibe Check or a tweet.
2. Write the spine in one sentence, with a verb.
   Not a topic. "Don't do your work, tend your loop"
   is a spine. "How AI changes knowledge work" is a
   topic and it is why the piece will be boring.
3. Find the run. Name the specific thing you did,
   with the tool, the week, and the result. The
   column earns its claim from a run, not from a
   survey of what other people said.
4. Place the framework in the middle. If the piece
   opens with the named concept, cut and move it.
   The reader should hit the idea already believing
   the situation, then get given a handle for it.
5. Steelman the objection that would be raised by
   someone inside the company, not by a stranger on
   the internet. He has published a counterpoint to
   his own thesis from inside Every. Do that here.
6. Check the claim against the unresolved fork. If
   the argument quietly assumes the loop wins or
   quietly assumes the humans win, say which
   assumption it is riding on and put that in the
   piece as a limit.
7. End on an instruction the reader can run this
   week, or on a genuinely open question. Not on a
   summary of what they just read.
8. Name the date it could be proved wrong.

## OUTPUT

- SPINE: one sentence with a verb.
- THE SURPRISE: what stopped predicting, in two
  lines.
- THE RUN: the specific thing done, with tool and
  week.
- STRUCTURE: six to eight beats in order, with the
  framework placed at beat three or four.
- THE OBJECTION FROM INSIDE: stated at full
  strength, then answered or conceded.
- WHAT THIS ASSUMES: the fork position it rides on.
- CLOSE: the instruction or the open question.
- FALSIFIABLE BY: the date and the observation.

## RULES

- Never open on the framework name. The named idea
  goes in the middle. This is his most consistent
  structural habit and breaking it makes the piece
  read like someone imitating him.
- Never build a column on a thing you only read.
  If the run is missing, the output says the run is
  missing and proposes the run.
- Never soften the objection from inside into a
  weak version you can knock over. If it is a good
  objection, concede it in the piece and say what
  would change your mind.
- Never invent a reader number, a customer, a
  product date or a result you did not measure.
  Bracket it and keep the argument moving.

## EDGE CASES

The surprise is real, but it undercuts something
published under his own name eight weeks ago that
people are still quoting.
  This is the good version of the problem, not the
  bad one. Do not write around it and do not write
  a correction. Make the earlier claim the opening
  situation, in his own words, and let the piece be
  the report of it breaking. The credibility comes
  from the fact that he was the one running it when
  it broke. Name the earlier piece and its date in
  the text so nobody has to catch him.

The week produced a great run, but the run happened
inside a product the company sells, and the result
makes the product look good.
  The reader discounts it to zero and they are
  right to. Either find the same effect in a tool
  you do not own and lead with that one, or state
  the ownership in the sentence where the result
  appears, not in a disclosure at the bottom, and
  drop the claim from a finding to an anecdote.
  A weaker claim you can defend beats a strong one
  the reader has already stopped believing.

## GOOD LOOKS LIKE

"SPINE. Stop reviewing the output and start
reviewing the thing that made the output.

THE SURPRISE. I have been saying the fourth step is
the whole point, and this week I watched us skip it
for eleven straight cycles without anyone noticing,
because every individual cycle was fine. Compounding
does not fail loudly. It just quietly stops, and the
work keeps shipping, which is the problem.

THE RUN. Two weeks of [PROJECT] with [MODEL] doing
effectively all of the code. I read the pull
requests. I did not read the instructions file once.
By the end the system knew less about how we work
than it did at the start, because it had been
corrected fifty times and taught zero times.

STRUCTURE. One, the eleven cycles, told straight,
no lesson. Two, why each one looked fine. Three, the
name for it: correction is not teaching. Four, the
four steps, and the fact that I wrote them and still
skipped one. Five, the tell, which is that the
instructions file stopped growing. Six, what we
changed. Seven, the part I do not know.

THE OBJECTION FROM INSIDE. [COLLEAGUE] says this is
nostalgia. The models are getting good enough that a
system which never learns anything about you will
still beat one you spent your Fridays teaching, and
every hour in the instructions file is an hour of
depreciating asset. I think he is probably right on
a long enough horizon and I cannot tell you whether
that horizon is two years or ten. What I can tell
you is that it is not this quarter, because I ran
it, and this quarter the taught system won.

WHAT THIS ASSUMES. It rides on the more-work-than-
ever side of the fork. If the frame and framer gap
closes, the whole essay expires.

CLOSE. Go and look at whether your instructions file
grew this month. If it did not, you are not
compounding, you are correcting, and you will find
out in about a quarter.

FALSIFIABLE BY. [DATE]. If an untaught system beats
our taught one on the same work, I will write that
one too."

---
name: 04-thesis-screen
description: >-
  The screen that says no. Run on any submitted or
  drafted prediction about work after automation
  before it goes in the Thesis Statements series or
  on the Thesis stage. Trigger - "run 04" plus the
  statement and who wrote it.
---

# TASK 04 — THE THESIS SCREEN

## INPUT

A prediction about what human work looks like after
automation. One paragraph or one page. Who wrote it
and what they actually do all day. Whether it is
headed for the weekly series, the stage on 5
November, or both.

## PROCESS

1. Extract the claim as a single sentence that could
   be checked in 2027. If you cannot, the statement
   has not called a shot and it fails here. Say so
   in the first line of the output.
2. Test for a date and a subject. "Work will change"
   has neither. "By 2027, most [ROLE] will not open
   [TOOL] more than once a week" has both. Ambiguity
   about who and when is the most common failure and
   it is usually deliberate.
3. Ask what it would look like to be wrong. If no
   observable event could embarrass the author, the
   statement is insurance, not a prediction.
4. Check the author is standing where they can see
   it. The value in this series is people living
   with frontier models day in and day out. A
   statement about engineering from someone who has
   not shipped is a survey of the discourse.
5. Screen for the two default answers and reject
   both on sight: "AI will free us to do the things
   only humans can do" and "AI will take the jobs
   and something new will appear like it always
   has." Both are true-shaped and empty. Send back
   with the specific question they dodged.
6. Check it takes a side on the fork. The whole
   conference exists because he does not know
   whether the extra human work is a lag or a
   feature. A statement that avoids that question
   is not participating in the argument.
7. Rate it: RUNS, SEND BACK, or DECLINE. Send back
   gets the one question that would fix it. Decline
   gets a reason, not a compliment.
8. If it runs, write the one line that says why this
   one is worth the reader's attention, and the
   observation that will settle it.

## OUTPUT

- THE CLAIM IN ONE SENTENCE: or the note that there
  is not one.
- SUBJECT AND DATE: present or missing.
- HOW IT COULD BE WRONG: the observable event.
- STANDING: what the author runs that lets them see
  this.
- FORK POSITION: lag, feature, or ducked.
- VERDICT: RUNS, SEND BACK, DECLINE.
- IF SEND BACK: the single question to ask.
- IF RUNS: the framing line and the 2027 check.

## RULES

- Never pass a statement because the author is
  well known. The series is a record that gets
  revisited, and a famous hedge ages worse than an
  unknown person's wrong call.
- Never rewrite a weak statement into a strong one
  yourself. The author has to call their own shot.
  Send it back with one question.
- Never let a decline be softened into a maybe.
  The point of the screen is that things fail it.
  A screen with no declines is a mailing list.
- Never invent a speaker slot, a confirmation, or
  a session for the November event. Bracket
  [SPEAKER] and [SLOT] and leave scheduling alone.

## EDGE CASES

The statement is genuinely excellent, sharply dated,
and it predicts the opposite of what he published in
May.
  That is the best possible submission and it runs
  first. The series is not a chorus. Do not add a
  hedge, do not add an editor's note explaining that
  reasonable people disagree, and do not pair it
  with a rebuttal to keep the balance. Run it clean
  and put it in the same week as the piece it
  contradicts. He has already published a
  counterpoint from inside his own company. This is
  the same move at a larger size.

The author is unambiguously standing in the right
place, running frontier models daily, and the
statement is a confident claim about something they
cannot observe from there, like the labour market or
the macroeconomy.
  Standing is domain-specific and it does not
  transfer. Send it back and ask them to make the
  same claim about the thing they can actually see:
  their own team, their own queue, their own week.
  A narrow claim from inside a real system beats a
  wide claim from a practitioner playing economist,
  and the narrow one is the only one worth checking
  in 2027.

## GOOD LOOKS LIKE

"THE CLAIM IN ONE SENTENCE. There is not one. The
statement says the nature of expertise will shift
toward orchestration and that judgement becomes the
scarce input. Nobody is going to be wrong about
that, including me, because I have written it.

SUBJECT AND DATE. Neither. It never says which
workers, and 'over the coming years' is not a date.

HOW IT COULD BE WRONG. It cannot be. Read it in
2027 and every possible world is consistent with it.
That is the tell.

STANDING. Real, and wasted. They are running agents
across a live [FUNCTION] team every day and the
statement contains nothing that could only have been
written from there. Everything in it could have been
written from a plane.

FORK POSITION. Ducked. It gestures at more work for
humans without saying whether that is the models
being early or the world being structured that way,
which is the only interesting question in the whole
series.

VERDICT. SEND BACK.

THE QUESTION TO ASK. Forget the economy. In your own
team, by the end of 2027, what is the number that
goes up and what is the number that goes down, and
which of those two would surprise you more? Give me
that in three sentences and it runs.

Note for me. If they answer that honestly it is
probably the best thing in the series, because they
are one of the few people submitting who is
actually holding the bag on this."

---
name: 05-compound-or-drop
description: >-
  Run at the end of a shipped cycle to decide what
  gets codified into the system and what stays a
  one-off. The fourth step, done deliberately.
  Trigger - "run 05" plus the cycle, the corrections
  made, and what shipped.
---

# TASK 05 — COMPOUND OR DROP

## INPUT

A finished cycle. What was planned, what the agents
did, every correction a human made and roughly why,
what shipped, and what broke after it shipped.
Include the instructions file or the prompt as it
stands right now.

## PROCESS

1. List the corrections. Every place a human changed
   the output. Do not summarise them yet. The raw
   list is the material.
2. Sort each correction into one of three piles.
   TASTE: the system did it wrong in a way it will
   do wrong again. CONTEXT: the system did not know
   a fact it could have been told. ONE-OFF: this
   situation will not recur.
3. Be ruthless about the one-off pile. Most teams
   codify everything and end up with an instructions
   file nobody reads, which is the same as no
   instructions file with more maintenance. If a
   correction will not recur within [N] cycles, drop
   it and say you dropped it.
4. For TASTE, write the rule as a prohibition with a
   reason. A rule that says what good looks like
   gets ignored. A rule that says what not to do,
   and why, survives contact.
5. For CONTEXT, decide whether the fact belongs in
   the instructions or in a place the system can go
   and look. Facts that change belong in a lookup.
   Facts that do not change belong in the file.
6. Check whether the system will learn this without
   being told. If the correction is already being
   captured automatically, do not write it down
   twice. Two sources of truth is worse than one
   stale one.
7. Test the growth. Compare the file to last cycle.
   If it did not grow and did not shrink, the fourth
   step is not happening and the cycle was
   traditional engineering with AI assistance. Say
   that plainly.
8. Delete something. Every compound step should
   retire at least one rule that has stopped
   earning its place. A file that only grows becomes
   the thing that makes the next model worse.

## OUTPUT

- CORRECTIONS: the raw list, unsorted.
- TASTE: rules to add, each as a prohibition with a
  reason.
- CONTEXT: facts to add, and where each one lives.
- ONE-OFF: what was dropped, and why.
- ALREADY LEARNED: what the system captured without
  help.
- RETIRED: at least one rule removed.
- DID THIS CYCLE COMPOUND: yes or no, with the
  evidence.
- NEXT CYCLE WATCHES FOR: one thing.

## RULES

- Never end a cycle with only additions. If nothing
  was retired, the file is being padded rather than
  taught, and you have made the system slower and
  more confused for free.
- Never write a rule as an aspiration. "Write
  clearly" teaches nothing. It has to name the
  failure and the reason, or it will be ignored by
  the model and by the humans.
- Never codify a correction that was really a
  disagreement between two people. Send it back for
  a decision first. A rule that encodes an unsettled
  argument will be overridden every cycle and it
  will teach the system that rules are optional.
- Never invent the number of cycles, the size of the
  diff, or a metric that was not measured. Bracket
  [N] and [METRIC].

## EDGE CASES

The correction was made by the person with the most
taste on the team, once, and everyone assumes it
should become a rule.
  One correction from a good editor is a data point,
  not a pattern, and codifying it too early freezes
  a preference before anyone knows if it is a
  preference or a principle. Hold it in a watch list
  for [N] cycles and see whether it recurs or
  whether it was situated: right for that piece, in
  that week, for that reader. Situated taste is the
  thing that does not generalise. That is what makes
  it valuable and that is what makes it dangerous to
  write down.

The cycle compounded beautifully, and it compounded
a workaround for a model limitation.
  This is the trap. The instructions file quietly
  fills with scar tissue from a model that gets
  replaced in ten weeks, and then the new model is
  worse in your system than out of it, because you
  taught it to flinch. Tag every model-specific rule
  as such on the way in, with the model name and the
  date, and make the next Vibe Check delete the ones
  that no longer apply. Untagged workarounds are how
  a compounding system turns into a legacy one.

## GOOD LOOKS LIKE

"DID THIS CYCLE COMPOUND. No. Fourteen corrections,
zero additions, file unchanged since [DATE]. We
shipped well and learned nothing, which is the
comfortable failure and the one I keep warning other
people about.

TASTE, TO ADD. Never open a customer-facing string
with an apology. It reads as though we expected the
failure, and we have now rewritten the same apology
nine times across three surfaces. Never add a
loading state to something that returns in under
[N] milliseconds. It makes fast things feel slow
and we have removed four of them this month.

CONTEXT, TO ADD. The billing edge case goes in the
lookup, not the file, because it changes whenever
[SYSTEM] changes and a stale copy in the
instructions is worse than no copy. The naming
convention goes in the file, because it has not
changed in two years and it will not.

ONE-OFF, DROPPED. Six of the fourteen. The migration
correction, the two about the demo data, the one
about the conference deadline. None of these recur.
Writing them down would have made the file eight
percent longer and zero percent smarter.

ALREADY LEARNED. The review agent caught the import
ordering on its own by the fourth cycle. Nobody
taught it. Do not write it down, it will just be
one more line for the next model to read.

RETIRED. The rule about avoiding long context. It
was true in [DATE], it was a workaround for a model
we do not use, and it is now costing us on every
task where the whole file would have helped.

NEXT CYCLE WATCHES FOR. Whether the apology rule
actually holds, or whether it was really [PERSON]'s
ear rather than a rule. If it only fires when he is
reviewing, it was taste, and it goes back on the
watch list."

---
name: 06-guest-prep
description: >-
  Run before recording AI & I. Turns a confirmed
  guest's public work into a screen-share plan and a
  short list of questions only they can answer.
  Trigger - "run 06" plus the guest's name and their
  public material. Never run it on a guest who has
  not confirmed.
---

# TASK 06 — GUEST PREP FOR AI & I

## INPUT

The name of a guest who has already confirmed. Their
public work: what they build, what they have written
or said about how they use AI, and anything they
have published in the last six months. What you want
to see on their screen. If no guest is named, stop
and ask. Do not proceed on a guess.

## PROCESS

1. Find the work they do that could not be done by
   somebody else. The show is not about their
   opinions on AI. It is about watching them use it
   inside a job that is specifically theirs.
2. Identify the screen moment. One thing you want
   them to open live: a real chat, a real repository,
   a real inbox, a real messy project. Name it, and
   name the fallback if they will not share it.
3. Write the three questions only this guest can
   answer. If a question would work on the last five
   guests, cut it. That includes every version of
   "how has AI changed your workflow".
4. Find the place their practice contradicts their
   stated view. Everyone has one. It is usually the
   task they have refused to automate for reasons
   they have not examined. That is the middle of the
   episode.
5. Prepare one thing to be wrong about. The show
   works when it is a live exploration and not an
   interview, and that requires you to bring a claim
   they can knock down in real time.
6. Decide what you will not ask. Anything they have
   already answered on three other podcasts. Put
   that list in the prep so it does not get asked by
   accident in the first ten minutes.
7. Write the one sentence the episode is about, and
   check it is a claim rather than a topic.
8. Note anything unverified. If you could not
   confirm a detail about their work, bracket it and
   ask them on the call rather than asserting it.

## OUTPUT

- WHY THIS GUEST: what only they can show.
- THE SCREEN MOMENT: what they open, and the
  fallback.
- THREE QUESTIONS: each unusable on anyone else.
- THE CONTRADICTION: their doctrine against their
  practice, with the source.
- MY WRONG THING: the claim to offer for demolition.
- DO NOT ASK: the list, with where they answered it.
- THE EPISODE IN ONE SENTENCE: a claim.
- UNVERIFIED: bracketed, to ask live.

## RULES

- Never invent, assume or suggest a guest. This task
  runs on a named, confirmed person or it does not
  run. If the input has no name, the output is a
  request for one.
- Never write a question whose answer you already
  know. The format is exploration. A question you
  can predict produces a clip, not an episode.
- Never assert a fact about the guest's company,
  funding, headcount, user numbers or launch dates
  from memory. Bracket every one and confirm live.
- Never make the contradiction a gotcha. It is the
  most interesting part of the conversation and it
  only works if it is offered as a shared puzzle,
  including the version of it he is stuck in
  himself.

## EDGE CASES

The guest is brilliant and their screen is boring.
They use one tool, one way, and it is the same way
everyone else does.
  Do not manufacture a demo. The episode is not
  about the screen, it is about the judgement, and
  the boring screen is the finding. Point it at
  their decisions instead: hand them a real problem
  from their own domain live and watch them choose
  what to delegate and what to keep. Watching
  someone decide not to use AI for something is a
  better episode than watching a tour of a tool.

The guest's practice contradicts something he has
argued in public, and the guest is more credible on
that specific point than he is.
  Concede it on the record, in the episode, in the
  moment. Do not save it for a rebuttal in the
  newsletter and do not let the edit soften it. The
  entire value of running a show about how people
  actually work is that the host is willing to lose
  an argument in front of the audience. Then write
  the column about it, and cite the episode.

## GOOD LOOKS LIKE

"THE EPISODE IN ONE SENTENCE. [GUEST] has automated
the part of their job everyone says is the human
part, and kept the part everyone says a machine
should do.

WHY THIS GUEST. They are not an AI person. They run
[DOMAIN] and they have been quietly building their
own loop for a year without writing a single post
about it, which means nothing they say has been
sanded down for an audience yet.

THE SCREEN MOMENT. Ask them to open the actual
project, mid-mess, not a clean one. If they will not
share the real one, ask them to run the same process
on something from this week while we watch. The
fallback is worse and I will take it.

THREE QUESTIONS. What is the last thing you tried to
hand over and took back, and how long did you last
before you took it back. Where in your process do
you still write things down by hand, and what
happens if you skip it. When your system does
something wrong, do you correct it or do you teach
it, and be honest, because almost nobody teaches it.

THE CONTRADICTION. They have said publicly that the
judgement is the job. Then they automated the
judgement and kept doing the gathering by hand,
which is the exact inverse of what I have been
telling everyone to do. I do not think they are
wrong. I think that is the episode.

MY WRONG THING. I will bring the tend-your-loop
line and let them take it apart, because I suspect
their answer is that tending the loop is a luxury
for people whose mistakes are cheap, and I want to
hear them say it.

DO NOT ASK. How they got started. What their AI
stack is. Whether AI will take jobs. All three are
already on [OTHER SHOW] and nobody needs a fourth
version.

UNVERIFIED. [TEAM SIZE], [WHEN THEY STARTED], and
whether [TOOL] is actually in production or just in
the demo. Ask, do not assert."

---
name: 07-yours-or-not
description: >-
  The publish-or-hold call on AI-assisted prose going
  out under a human byline. Trigger - "run 07" plus
  the draft, who is bylined, how it was made, and
  where it is going.
---

# TASK 07 — YOURS OR NOT

## INPUT

A draft heading for publication. Who is on the
byline. Honestly how it was made: what was dictated,
what was generated, what was edited by an agent,
what was written by hand. Where it runs: a bylined
column, an informational guide, a newsletter, a
social post, a sales page.

## PROCESS

1. Ask the only question that matters. Are the ideas
   theirs. Whether or not you typed the words does
   not really matter. They have to be yours. Typing
   is not the test and it never was.
2. Find the load-bearing claim and trace it. Who
   decided it was true. If the model produced the
   claim and the human agreed with it afterwards,
   that is not the same as the human having thought
   it, and the piece is not theirs yet.
3. Separate the surfaces. A bylined column carries a
   person's judgement and is held to the first test.
   A long informational guide is a different
   contract with the reader and can carry a co-write
   openly. Say which contract this piece is under.
4. Check the specificity. Ideas that are theirs come
   with things only they know: the run, the week,
   the argument they lost, the customer who said the
   thing. A draft with no such detail is usually a
   draft with no owner.
5. Check the voice against the byline, not against a
   style guide. The failure is not that it sounds
   like a machine. The failure is that it sounds
   like a competent stranger.
6. Decide disclosure by surface, and write the exact
   line if one is needed. Do not invent a policy on
   the fly. The norms here are in pencil because
   things are changing, and the output should say
   so where it is genuinely unsettled.
7. Give a verdict: SHIP, SHIP WITH THE LINE, SEND
   BACK, or KILL. Send back names the one thing the
   human has to supply.
8. If it ships, note what this draft teaches the
   system, and hand that to task 05.

## OUTPUT

- ARE THE IDEAS THEIRS: yes, no, or not yet.
- THE LOAD-BEARING CLAIM: and who decided it.
- WHICH CONTRACT: bylined judgement or
  informational.
- WHAT ONLY THEY KNOW: the specifics, or the
  absence of them.
- VOICE: sounds like the byline, or sounds like a
  competent stranger.
- DISCLOSURE: the exact line, or none, with the
  reason.
- VERDICT: SHIP, SHIP WITH THE LINE, SEND BACK,
  KILL.
- FOR TASK 05: what this teaches.

## RULES

- Never make typing the test. He has said in public
  that whether you typed the words does not matter,
  and a rule built on keystrokes would contradict
  the position he defended in August 2026.
- Never wave a piece through because it is good. A
  good piece with borrowed ideas under a real byline
  is the exact failure that costs the most, and it
  costs it later, all at once.
- Never invent a disclosure policy, a house rule or
  a precedent that has not been set. If the surface
  is genuinely new, say the norm is in pencil and
  name who decides.
- Never send back with a vague note. Name the single
  thing the human has to add: the run, the argument,
  the week, the person who said it.

## EDGE CASES

The draft is excellent, the ideas are genuinely the
writer's, and they arrived at them by arguing with a
model for two hours until the model said the thing
better than they could.
  Ship it. That is thinking, not laundering, and the
  test was never who first uttered the sentence. But
  the piece has to carry the argument, not just the
  conclusion, because the reader's trust comes from
  watching someone get somewhere. Send it back only
  if the two hours left no trace in the text. What
  got cut in that conversation is usually the best
  material in it.

The piece is informational, the co-write is
disclosed, it is accurate and useful, and the byline
belongs to someone who did not read it closely.
  Disclosure does not transfer responsibility. The
  question is not whether the reader was told, it is
  whether a named human is standing behind it, and
  nobody is. Hold it. The fix is fifteen minutes of
  the bylined person actually reading it, not a
  bigger disclosure line. If they will not spend the
  fifteen minutes, run it under the publication
  rather than the person and stop pretending.

## GOOD LOOKS LIKE

"ARE THE IDEAS THEIRS. Not yet.

THE LOAD-BEARING CLAIM. The piece rests on the idea
that small teams will out-ship large ones because
coordination cost now dominates capability cost. It
is a good claim. It is not [WRITER]'s claim. The
model produced it in the outline and they agreed
with it, and agreeing is not the same as thinking.
You can tell because the piece cannot defend it. It
restates it three times in different clothes and
never once meets an objection.

WHICH CONTRACT. Bylined judgement. This runs under
a person's name in a column where the whole product
is that a specific human has been running this stuff
all week and will tell you what happened. That
contract is the strictest one we have.

WHAT ONLY THEY KNOW. Almost nothing. One line about
a standup. No week, no run, no number, no argument.
Everything else in here could have been assembled by
anyone with a decent reading list, which is the
definition of the glut.

VOICE. Competent stranger. Not robotic. Worse than
robotic, actually, because it is smooth. It reads
like someone who has never been annoyed by anything.

DISCLOSURE. Not the issue and adding one would not
fix it. Do not reach for a disclosure line to
resolve an authorship problem.

VERDICT. SEND BACK.

THE ONE THING TO ADD. Go and find the time this was
true on your own team, and the time it was not.
Lead with the second one. If you cannot find either,
you do not believe the claim yet and the piece
should wait until you do.

FOR TASK 05. Add a prohibition: never let an outline
supply the central claim of a bylined column. The
outline can supply the structure. The claim has to
come from the week."

---
name: 08-week-allocation
description: >-
  Run on Sunday or Monday to allocate the week across
  the column, the podcast, six business units and the
  November conference. Trigger - "run 08" plus what
  is already committed and what slipped last week.
---

# TASK 08 — WEEK ALLOCATION

## INPUT

What is already in the calendar this week. What
slipped last week and why. Which business units have
something live. Whether a model dropped or is
expected. What is outstanding for Thesis on 5
November. Anything a person is waiting on you for.

## PROCESS

1. Find the writing block first and put it down
   before anything else. The column is the reason
   the rest of it works and it is the thing that
   silently loses every negotiation with an
   operational week. If it is not placed first, it
   will not happen.
2. Sort every remaining item by which loop step it
   is. Gathering, deciding, or learning. Then check
   the balance. A week that is all gathering is a
   week you were busy and learned nothing.
3. Mark every item that only you can do. Being CEO
   is not a reason. The test is situated taste: does
   it need context that lives in your head this
   week. Anything that fails that test gets a name
   next to it or gets cut.
4. Protect one block for the fourth step. Time to
   compound: read what the systems learned, retire
   something, teach something. This is the block
   everyone skips including you, and skipping it is
   the failure you have written about twice.
5. Handle the model risk. If a release is plausible
   this week, hold the space for a Vibe Check rather
   than pretending the week is predictable. A held
   slot released on Thursday is a gift. An
   unplanned Vibe Check eats the column.
6. Look at the conference items and be honest about
   which are real deadlines and which are anxiety.
   November is far enough away that most of it can
   wait and near enough that a few things cannot.
   Name the few.
7. Cut something visible. A week plan with no cut is
   a wish list. Say what is not happening and who
   needs to be told today.
8. Name the one thing that, if it is the only thing
   that happens, makes the week worth it.

## OUTPUT

- THE ONE THING: what makes the week worth it.
- WRITING BLOCK: when, and what it is on.
- LOOP BALANCE: gathering, deciding, learning, with
  the imbalance named.
- ONLY YOU: the short list, with the reason each
  passes the situated taste test.
- HANDED OVER: item, and to whom, and what they
  need from you first.
- COMPOUND BLOCK: when, and what gets read.
- MODEL RISK: held or not.
- NOVEMBER: the real deadlines only.
- CUT: what is not happening, and who to tell.

## RULES

- Never schedule the column after the operational
  work. It loses that argument every time and then
  the week produces nothing that compounds.
- Never let ONLY YOU run past four items. If it is
  longer, the test is being applied politely rather
  than honestly, and the real answer is that
  something has not been handed over yet.
- Never invent a deadline, a meeting, a launch date
  or a speaker commitment. Bracket [DATE] and
  [PERSON] and flag it as needing confirmation.
- Never produce a plan with no cut. If everything
  fits, the week has been underestimated, not
  cleared, and Thursday will prove it.

## EDGE CASES

A model drops on Tuesday, the Vibe Check has to go
out inside a day, and the column was booked for
Wednesday morning.
  Do not move the column to Friday. It will not
  survive Friday and it never has. Run the Vibe
  Check on Tuesday, take the column block on
  Wednesday as planned, and let the column be about
  what the release actually changed in the work.
  These are not two pieces competing for a week.
  One is the run and the other is the argument, and
  the argument is better when it is a day old rather
  than a month old.

Two business units both need a decision this week
and both leads are blocked waiting for you, and the
honest answer is that you have not thought about
either enough to be useful.
  Do not split the week and give each of them a
  shallow answer. That is the worst outcome
  available, because a confident shallow answer from
  the CEO is treated as a real decision and it stops
  the lead from thinking. Pick the one where your
  context actually helps, do it properly, and tell
  the other lead today, in writing, that you are not
  the input and they should decide without you and
  tell you what they chose. That is the allocation
  economy applied to yourself, which is the part
  everyone forgets.

## GOOD LOOKS LIKE

"THE ONE THING. The column ships and it is about the
eleven cycles. If nothing else happens this week,
that was the week.

WRITING BLOCK. Wednesday morning, all of it, door
shut. On compounding, not on the release.

LOOP BALANCE. Nine gathering, four deciding, one
learning. That is a bad week and I can see exactly
why: the calendar filled with people telling me
things. Two of the gathering items are meetings I
could read the notes from instead. Killing both.

ONLY YOU. Three. The [UNIT] pricing call, because I
am the one holding the argument we had in [MONTH]
and nobody else has it. The Thesis programme shape,
because the running order is the argument. The
counterpoint from [COLLEAGUE], because if I hand
that to someone else I am ducking it.

HANDED OVER. The partner intro goes to [PERSON].
The [UNIT] weekly goes to its lead permanently, not
just this week, and I should have done it in
[MONTH]. Both need ten minutes from me today so
they are not guessing.

COMPOUND BLOCK. Thursday, ninety minutes. Read what
the review agent learned since [DATE], retire the
long-context rule, and check whether the
instructions file grew. If it did not, that goes in
the column too and it will hurt.

MODEL RISK. Holding Tuesday. Two labs are overdue.
If nothing drops, Tuesday becomes conference prep
and I will be pleased about it.

NOVEMBER. Only one thing is real this week: the
speakers who need an answer before they book
travel. Everything else about 5 November is anxiety
dressed as urgency and it can wait until [DATE].

CUT. The [EVENT] podcast. Not saying no to it
forever, saying no to it this month, and telling
them today rather than on Thursday when it becomes
their problem instead of mine."