---
name: 01-no-hype-launch-review
description: Run when a lab or a tool ships something and I have to decide whether to cover it today and what I actually know yet. Trigger - "run 01" plus what I tested and what broke.
---

# TASK 01 — NO HYPE LAUNCH REVIEW

## INPUT
What shipped, when I got hands on it, how many
hours I have actually run it, every test I ran
with the real result including the ones that
failed, the open slot on the calendar, and whether
the vendor sponsors anything of mine.

## PROCESS
1. Split the findings into CONSENSUS and MINE.
   Consensus is what anyone with an hour and the
   changelog will post tonight. MINE is what only
   showed up because I ran it on my own real work.
2. Put a confidence in hours on each MINE item.
   Ninety minutes is a first look. A week of real
   use is a review. The two never share a sentence
   without the label.
3. If MINE is empty, do not publish today. Say
   what I would need to run to have something, and
   how long that takes.
4. Draft the open with what I tested and what it
   cost me, not with what the launch claims.
5. Name what still needs work. A review with no
   "still needs work" section is an ad.
6. Add the disclosure line if the vendor sponsors
   anything of mine, even a different video. The
   audience cannot see my invoices.

## OUTPUT
A first look or a review, labelled as one of the
two inside the first three sentences, plus HELD:
the claims I cannot stand behind yet and the exact
test that would settle each one.

## RULES
- Never carry a benchmark, price or usage limit I
  have not seen with my own eyes. Ask once, or
  mark it [UNVERIFIED] in the draft.
- Never call a tool the best at something I did
  not test on my own work.
- No hype words, no "this is not X, this is Y", no
  em dashes.
- Sponsorship never changes a verdict and never
  goes unmentioned.

## EDGE CASES
- The launch is genuinely great and the vendor
  sponsors me this month: the praise gets harder
  evidence than usual, not softer, and the
  disclosure goes above the verdict rather than
  down in the description.
- Everything I found is already in six other
  videos: the honest move is the follow up in a
  week on what actually held up, not a faster
  version of the same take.

## GOOD LOOKS LIKE
"I have had this for 90 minutes, so this is a
first look and not a review. It built the game in
three tries and it broke my app twice. I will tell
you which of those matters after I have run it for
a week."

---
name: 02-book-the-guest
description: Run when I am filling an interview slot. Trigger - "run 02" plus the name or the topic gap, plus what is already booked.
---

# TASK 02 — BOOK THE GUEST

## INPUT
The open slot, who is already booked for the next
month, the topic index of what I have covered, and
the name or the gap I am trying to fill.

## PROCESS
1. Check the last ten episodes for repeat shape.
   Two builders in a row who run agents overnight
   is one episode told twice.
2. Ask what this person can open on screen that
   nobody else can. If the answer is a point of
   view and no demo, that is a written piece, not
   an episode.
3. Write the ask around the one thing I want them
   to show, with the exact runtime and the exact
   week. Vague asks get vague yeses that never land
   on a calendar.
4. Say the audience benefit in the viewer's words,
   not the guest's. Busy people who want the
   practical version.
5. Flag any conflict. A current sponsor, a
   competitor of a current sponsor, or someone I
   owe a favour to.

## OUTPUT
An ask I could send today, plus the one thing they
will show live, plus the two questions only they
can answer.

## RULES
- Never promise reach, placement or a number I
  have not published myself.
- Never book a guest whose only offer is a product
  announcement.
- No flattery I do not mean. They can tell.
- Never pitch a week I have not checked against
  the publishing calendar.

## EDGE CASES
- A big name with nothing to show: book it only if
  the hour can carry itself on one hard question
  they have not been asked before, and name that
  question inside the ask so they can say no now
  rather than dodge it on tape.
- The guest works at a company that sponsors me:
  book it, disclose it in the episode, and do not
  let it take the slot I was holding for someone
  with no budget.

## GOOD LOOKS LIKE
"I do not want the launch walkthrough. I want the
40 minutes where you open your own repo and show
me the part of your setup you would be slightly
embarrassed for your team to see."

---
name: 03-interview-prep
description: Run the day before an interview. Trigger - "run 03" plus the guest name, their public writing and talks, and the demo they agreed to.
---

# TASK 03 — INTERVIEW PREP

## INPUT
Guest name, their public posts, talks and past
interviews, the demo they agreed to run, and my
transcript archive for anything I have already
asked them or asked someone in their seat.

## PROCESS
1. Pull every question they have answered in
   public three times already. Those are banned.
   Ask one and I get the rehearsed answer.
2. Build the spine demo first. The demo is the
   episode. Questions exist to set it up and to
   interrupt it in the right place.
3. Six questions maximum. One about a decision
   they got wrong, one about what they will not
   hand to an agent, and the rest specific enough
   that nobody else could answer them.
4. Draft the cold open candidates, the three
   sentences I hope they say. If I cannot picture
   the cold open, the booking is weak and I should
   hear that now rather than in the edit.
5. List the two places the demo will probably
   break live, and what I say while it does.

## OUTPUT
A one page brief that reads on a phone. WHO / THE
DEMO / SIX QUESTIONS / COLD OPEN CANDIDATES /
WHERE IT BREAKS.

## RULES
- Never ask a question whose answer is on their
  landing page.
- Never let a guest walk me through a deck. If a
  deck appears, move to the screen share.
- No question longer than two sentences.
- Never bring a number about their company that
  they have not said in public.

## EDGE CASES
- The guest sends talking points the night before:
  read them, then ask early and kindly the one
  question those talking points were built to
  steer around.
- The demo depends on a preview build that may not
  work on the day: prep the version of the episode
  where it fails, because an honest failure on
  camera is usually better tape than the success.

## GOOD LOOKS LIKE
"What is the part of this you still do by hand,
and what happened the last time you tried to hand
it to an agent?"

---
name: 04-episode-to-post
description: Run after an episode publishes and the written piece is due. Trigger - "run 04" plus the raw transcript and the timestamps I marked while recording.
---

# TASK 04 — EPISODE TO POST

## INPUT
Raw transcript, the timestamps I marked while
recording, the demo that ran, and any screenshot
worth keeping.

## PROCESS
1. Find the one takeaway a busy person can use on
   Monday. Not a summary of the conversation. If
   the episode has three, pick one and log the
   other two as future posts.
2. Lead with what happened on screen. The claim
   comes second, never as a headline.
3. Quote the guest verbatim from the transcript,
   never a tidied version. Fix grammar only, keep
   the words.
4. Cut every sentence that exists only because it
   was said out loud. Spoken filler reads as slop
   on the page.
5. Run the no slop pass. No em dashes, no "this is
   not X, this is Y", no delve, no leverage as a
   verb, no run of three short sentences, no grand
   claims.
6. Stop at the 80 to 90 percent draft and hand
   back the exact places that need my eyes. The
   takeaway line, every quote, and anything that
   sounds confident about something I did not
   test.

## OUTPUT
The post, plus a WHAT NEEDS MY EYES list, plus the
two spare takeaways logged for later.

## RULES
- Never write a transition that implies the guest
  said things in an order they did not.
- Never put a number in the post that is not in
  the transcript or in my own published work.
- Short and practical. No theory, no fluff.
- This task ends at the draft. It never publishes.

## EDGE CASES
- The best line in the transcript is a shot at a
  named company or person: cut it, or keep the
  point and drop the target. I critique the
  approach, not the people, and I want the guest
  back.
- The episode was a tutorial and the transcript is
  mostly me narrating clicks: the post is the
  decision points and the failures, not the steps.
  The steps are what the video is for.

## GOOD LOOKS LIKE
"WHAT NEEDS MY EYES: the takeaway line in
paragraph two is doing work you have not earned.
You ran that test once. Either run it again or
soften it back to what you actually saw."

---
name: 05-tutorial-spine
description: Run when I am planning a solo tutorial before I record it. Trigger - "run 05" plus the tool or workflow and the use cases I am weighing up.
---

# TASK 05 — TUTORIAL SPINE

## INPUT
The tool or workflow, the use cases on my list,
the runtime I am aiming for, and what I have
already shipped on this topic.

## PROCESS
1. Pick use cases out of my own week, never off
   the product's feature list. If I would not run
   it again on Thursday, it does not go in.
2. Order them by how fast a beginner gets a win.
   The first one lands inside three minutes or
   people leave.
3. Cut to five at most. A tutorial that covers
   everything teaches nothing.
4. For each one, write the failure I hit and the
   workaround. The workaround is the value.
   Anyone can read the docs.
5. Set the runtime promise in the title, then cut
   the script to fit it. The number in the title
   is a contract.
6. End on the one thing a viewer can do today with
   no setup and no subscription.

## OUTPUT
The spine. HOOK / FIVE USE CASES IN ORDER / THE
FAILURE IN EACH / RUNTIME BUDGET PER SECTION / THE
ONE TAKEAWAY.

## RULES
- Never demo something I have not run on my own
  work at least twice.
- Never pad to hit a runtime. Cut to hit it.
- No use case that only works on a preview build
  most people cannot get.
- Never close on a subscribe ask instead of a
  takeaway.

## EDGE CASES
- The tool is bad at four of the five use cases:
  the video becomes the short honest version and
  the title says what it cannot do. Twelve honest
  minutes beat thirty generous ones.
- The workflow only works because of three other
  paid tools I already run: say so in the first
  minute, then show the version that works without
  them or admit out loud that there is not one.

## GOOD LOOKS LIKE
"It failed the first two times I ran this, and
here is the exact line I added to fix it. That
line is the whole tutorial. Everything else you
can get from the docs."

---
name: 06-skill-audit
description: Run on the member skill library monthly, or the moment a skill starts producing output I would not ship. Trigger - "run 06" plus the skill folder.
---

# TASK 06 — SKILL AUDIT

## INPUT
The skill folder, its evals and memory files,
recent output it produced, and the edits I made by
hand after it ran.

## PROCESS
1. Read my hand edits first. Every hand edit is a
   piece of taste the skill does not hold yet.
   Sort them into ENCODABLE and MINE.
2. ENCODABLE becomes a rule or an eval check. MINE
   stays out, and goes into the skill as an
   explicit stop. Hand back here and wait for me.
3. Cut redundancy and dead instructions. A skill
   nobody will reread is a skill nobody will fix.
4. Check the description says when to trigger, in
   plain use when language.
5. Update evals.md with pass fail checks on what
   actually went wrong, not on what could
   theoretically go wrong.
6. Report the hand edit trend. Fewer hand edits
   month over month means the skill is working.
   More means it is drifting, and I would rather
   delete it than keep a skill I have stopped
   trusting.

## OUTPUT
The edited skill, the eval checks added, the list
of MINE items the skill will now stop and ask
about, and the hand edit count against last month.

## RULES
- Never encode a judgment I have not actually made
  twice. One good instinct is not a rule.
- Never let a skill grow past what I will reread.
- Never remove a stop point to make a skill run
  faster.
- Members paid for handcrafted. A skill that has
  not been run on my own real work does not ship.

## EDGE CASES
- The skill got good enough that I quietly stopped
  reading its output: that is the dangerous state,
  not the finished one. Add a spot check and read
  one run in five.
- Two skills have grown into the same skill: merge
  them and keep the stricter rules from each,
  rather than leaving both and letting me pick the
  wrong one in a hurry.

## GOOD LOOKS LIKE
"Your hand edits on this one went from eleven last
month to three. Two of the three were the same
fix, so it is a rule now. The third is taste and I
have left it as a stop."

---
name: 07-member-note
description: Run when I owe paid members an update or a new skill drop. Trigger - "run 07" plus what actually shipped for members since the last note.
---

# TASK 07 — MEMBER NOTE

## INPUT
What shipped for members since the last note, the
community threads with real questions in them,
what I promised last time, and what I did not
deliver.

## PROCESS
1. Open with what shipped for members. If nothing
   shipped, the note says so and says why, and
   does not fill the hole with free content they
   already saw.
2. Check the promise ledger. Anything I said last
   time and did not do gets named before anything
   new gets announced.
3. Pull two real questions out of the community
   and answer them in the note. The community is
   part of the product, so it belongs in the
   product.
4. For each new skill, say what it does not do and
   who should not bother. Members who use a skill
   wrongly leave quietly.
5. Close with the next thing and a date I can
   actually hit.

## OUTPUT
A short note. SHIPPED / STILL OWED / TWO ANSWERS /
WHAT IS NEXT AND WHEN.

## RULES
- Never quote a member without permission, and
  never name one who has not posted in public.
- Never put a subscriber, revenue or churn figure
  in the note. Those are [PRIVATE] unless I have
  published them. Ask me once.
- No upsell inside a note to people who already
  paid.
- Never announce a skill on the day it was
  generated. It ships after it has been run on my
  own work.

## EDGE CASES
- A month where the channel did well and the
  membership got nothing new: the note opens with
  that imbalance and offers a fix, instead of a
  highlight reel of the public wins.
- A member asks a question that is really a refund
  conversation: answer it straight and offer the
  refund first. A quiet unhappy member costs more
  than the money.

## GOOD LOOKS LIKE
"Two things shipped, and one thing I promised in
July still has not. That one is on me. It is half
built, it lands by the 15th, or I will tell you
why it did not."

---
name: 08-week-plan
description: Run Sunday night. Trigger - "run 08" plus the publishing calendar, the guest pipeline, member commitments, anything on fire. Reads on a phone.
---

# TASK 08 — WEEK PLAN

## INPUT
The publishing slots, the guest pipeline, member
commitments, sponsor obligations, family
commitments, anything on fire.

## PROCESS
1. Place the publishing slots first. One interview
   and one tutorial most weeks. They are fixed
   points, not outcomes.
2. Three OUTCOMES, one each: channel, members,
   build. An empty lane gets named as the risk,
   not padded with busywork.
3. Book the review hours. Every draft this week
   needs the last 20 percent from me, so it goes
   in as hours, not as a hope.
4. What to decline or defer, with the script.
5. The avoided thing. For me it is usually a
   pricing decision, a hard email, or the build I
   keep telling members is coming.
6. Check the plan against why I left the job. If
   the week has no time in it that belongs to me
   rather than the channel, the plan is wrong and
   I want one sentence saying so.

## OUTPUT — half a page, phone readable
FIXED POINTS / THREE OUTCOMES (channel / members /
build) / REVIEW HOURS / DECLINE AND DEFER / THE
AVOIDED THING.

## RULES
- Outcomes state what is true on Friday.
- Maximum three. Name what got parked.
- Never plan a week with two launches in it and no
  review hours booked.
- Never move protected personal time for a slot
  that could have moved instead.

## EDGE CASES
- Two big launches land in the same week: cover
  one properly and post the honest note that the
  other is not covered yet. Two rushed reviews do
  more damage than one missed launch.
- Travel or a conference: recording moves earlier,
  never later, and the plan names what gets
  drafted on the plane and what gets dropped
  outright.

## GOOD LOOKS LIKE
"AVOIDING: the skill you promised members in July.
It is half built, it is why two of them emailed
you, and every week it sits there is a week you
sell a library with a hole in it."