---
name: 01-build-in-public-post
description: Run when something happened in the build and I want to post about it. Trigger - "run 01" plus the build log or the story.
---

# TASK 01 — BUILD IN PUBLIC POST

## INPUT
What happened this week: the change, why I made it, what
surprised me, what it cost.

## PROCESS
1. CLONABILITY CHECK first, before drafting a word. Sort
   every detail into TEACHES (judgment, tradeoff, the
   reason behind the choice) or BLUEPRINT (schema, index
   strategy, prompt chains, feature mechanics, live
   metrics). Blueprint items do not publish.
2. Find the one transferable idea. Not "I did X" — what X
   taught that applies to someone building something else
   entirely.
3. Open with the concrete thing that happened. The lesson
   comes second, never as a headline.
4. Include the part that did not work, or the post is an
   advertisement.
5. Close by naming what is held back and why. Quiet
   omission is the failure mode.

## OUTPUT
The post + WITHHELD: the blueprint items, logged to my
private notes and tagged for possible long-form use later.

## RULES
- No metric I have not published myself.
- No hype, no thread padding, no engagement bait question
  at the end.
- Never name a tool or competitor to criticise.

## EDGE CASES
- Everything about the story is blueprint: say so and
  propose the adjacent post that survives the filter —
  usually the decision, never the implementation.
- A failure involving a vendor or tool: publish my
  misjudgment, not their bug report.

## GOOD LOOKS LIKE
"What I'm not posting: the schema, the index strategy, the
query shapes. A year ago I would have. That part is the
moat now."

---
name: 02-newsletter-essay
description: Run when the week needs to become an essay. Trigger - "run 02" plus the week's notes.
---

# TASK 02 — NEWSLETTER ESSAY

## INPUT
The week's notes: what I built, what I read, what argument
I keep having with myself.

## PROCESS
1. Run the clonability check from task 01 across every
   specific before structuring anything.
2. Find the argument. An essay has a position someone
   could disagree with; a recap does not. If the notes
   contain no position, say so and ask which one I hold.
3. Structure: the concrete story, the generalisation, the
   honest cost of taking the advice, and who this is
   wrong for.
4. "Who this is wrong for" is mandatory. Advice without a
   named exclusion is a horoscope.

## OUTPUT
Essay, 700-1,200 words, my voice + a subject line that
states the argument, not a tease + WITHHELD list.

## RULES
- One argument per essay. A second good idea is next week.
- No stat without a source and a year.
- No section headers doing work the prose should do.

## EDGE CASES
- The week was maintenance and nothing happened: the essay
  is about that — the invisible weeks are the honest
  subject nobody writes.
- The argument contradicts something I published before:
  lead with the contradiction and date both positions.
  Changing your mind in public is the asset.

## GOOD LOOKS LIKE
"Who this is wrong for: anyone whose product's hard part is
the interface, not the infrastructure. This entire essay
assumes the opposite."

---
name: 03-episode-outline
description: Run before recording a solo episode. Trigger - "run 03" plus the topic and any notes.
---

# TASK 03 — EPISODE OUTLINE

## INPUT
The topic, my notes, roughly how long I want to talk.

## PROCESS
1. Clonability check on every specific I plan to say out
   loud. Audio feels private and is not.
2. The cold open: the sentence that makes someone not skip
   — a concrete moment, never a topic announcement.
3. Three beats maximum for any length. Each beat gets one
   story and one point, in that order.
4. The turn: where I complicate my own argument. An
   episode without one is a monologue.
5. The close: one thing to remember, stated in a form a
   listener could repeat to someone else.

## OUTPUT
COLD OPEN (written verbatim) / THREE BEATS (story + point
each) / THE TURN / THE CLOSE / WITHHELD.

## RULES
- Written to be spoken. Short sentences. No paragraph I
  would run out of breath reading.
- Never scripted word for word past the cold open — bullets
  keep it alive.
- No sponsor claim beyond what I have verified myself.

## EDGE CASES
- The topic is one I have covered: the outline must state
  what is new since, or propose a different angle.
- Guest episode: this file does prep instead — three
  questions only they can answer, and the one thing I
  should not interrupt.

## GOOD LOOKS LIKE
"COLD OPEN: I spent three days this week building something
I'd have called a bad idea in January. It was still a bad
idea. It just cost three days to find out instead of three
weeks."

---
name: 04-feature-triage
description: Run on a pile of feature requests. Trigger - "run 04" plus the requests and who asked.
---

# TASK 04 — FEATURE TRIAGE

## INPUT
The requests, who asked, and what I know about their use
of the product.

## PROCESS
1. Separate the request from the problem. "Add a CSV
   export" is a request; "I can't get this into my
   reporting" is the problem, and it may have a cheaper
   answer.
2. Sort: BUILD NOW (one, at most) / BUILD IF IT RECURS /
   WON'T BUILD — with the reason for each.
3. Weigh maintenance, not build time. A solo founder pays
   for every feature forever; the build is the cheap part.
4. Draft the WON'T BUILD reply once, honest and reusable,
   naming what I would build instead.

## OUTPUT
THE ONE / IF IT RECURS (with the trigger count) / WON'T
BUILD (+ reasons) / the reusable decline reply.

## RULES
- Never promise a date I did not give you.
- One BUILD NOW. Two is a plan that fails quietly.
- A paying customer's request is weighted, never automatic.

## EDGE CASES
- The loudest requester is also the largest customer: name
  the conflict to me plainly and let me decide; do not
  quietly weight it.
- Request only makes sense with an integration I don't
  control: WON'T BUILD, and the reply says what would have
  to change upstream.

## GOOD LOOKS LIKE
"WON'T BUILD: three people asked, all three actually wanted
the same alert to reach them somewhere else. That's a
notification route, not a dashboard."

---
name: 05-churn-reply
description: Run when a customer cancels or signals they are leaving. Trigger - "run 05" plus their message and their usage if I have it.
---

# TASK 05 — CHURN REPLY

## INPUT
Their cancellation or message, verbatim. Their usage
pattern if I have it. How long they were a customer.

## PROCESS
1. Classify honestly: never activated, outgrew it, price,
   a missing capability, or their own situation changed.
   Only the middle three are about the product.
2. Reply as a person: thank them concretely, ask ONE
   question that gets the real reason, and make leaving
   easy in the same message.
3. No retention offer unless I authorised one. Discounting
   at the exit is how you buy back a customer who leaves
   again next quarter.
4. Log the reason in one line for the pattern, since three
   of these in a month is a roadmap item.

## OUTPUT
CLASSIFICATION (1 line to me) / the reply / THE LOG LINE.

## RULES
- Never guilt, never a survey, never "before you go" with
  a wall of links.
- Data export offered without being asked.
- Their reason is not argued with, ever — even when I think
  they are wrong about the product.

## EDGE CASES
- They are leaving angry: the reply apologises for the
  specific thing, not for their feelings, and it makes no
  promises about a fix date.
- They never activated: the honest question is what they
  expected on day one — that answer is worth more than the
  subscription was.

## GOOD LOOKS LIKE
"Your export is attached, no need to ask. One question if
you have ten seconds: what were you hoping it would do in
the first week that it didn't?"

---
name: 06-sponsor-reply
description: Run when a sponsorship inquiry lands for the newsletter or podcast. Trigger - "run 06" plus their email.
---

# TASK 06 — SPONSOR REPLY

## INPUT
Their email, verbatim. What their product does. My open
slots from [CAPACITY] and rates from [RATE CARD].

## PROCESS
1. Fit test before anything else: would I recommend this to
   a founder who asked me, unpaid? If no, decline — the
   audience is the asset and it is not rentable.
2. Good fit: the terms plainly — what a slot is, that the
   read is in my words, that it is disclosed, and that I
   do not sell editorial.
3. Numbers: only what I have published. Anything else is
   [PRIVATE] and the reply says so rather than inventing a
   range.
4. Bad fit: decline in two sentences without insulting the
   product, and say what audience it would suit.

## OUTPUT
FIT (1 line to me) / the reply / WHAT I PROMISED, listed,
so I can hold myself to it.

## RULES
- No rate not in [RATE CARD]. No slot not in [CAPACITY].
- Disclosure always. There is no unlabelled version at any
  price.
- No performance guarantee, ever — clicks are not mine to
  promise.

## EDGE CASES
- Competitor to something I build or use: disclose the
  conflict to them before terms, in writing.
- They want to approve the copy: no, and the reply explains
  that approval is what makes an ad read like an ad.

## GOOD LOOKS LIKE
"I'll write the read myself and it'll be labelled. If that
changes the maths for you, I understand — but it's what
makes the recommendation worth anything."

---
name: 07-week-plan
description: Run Sunday night or Monday morning. Trigger - "run 07" plus calendar, the build backlog, publishing commitments, anything on fire. Reads on a phone.
---

# TASK 07 — WEEK PLAN

## INPUT
Calendar, build backlog, newsletter and episode deadlines,
support load, anything on fire.

## PROCESS
1. Three OUTCOMES, one each: product, audience, business.
   Empty lane gets named as the risk, not padded.
2. Publishing commitments are fixed points, not outcomes.
   Place them first; the build fits around them.
3. What to decline or defer, with the script.
4. The avoided thing. For a solo founder it is usually a
   pricing decision, a customer conversation, or the
   feature that would make the product harder to explain.

## OUTPUT — half a page, phone-readable
FIXED POINTS / THREE OUTCOMES (product / audience /
business) / DECLINE-DEFER / THE AVOIDED THING.

## RULES
- Outcomes state what is TRUE on Friday.
- Maximum three; name what got parked.
- Never plan a week with no shipping and no writing. One of
  the two happens or the plan is wrong.

## EDGE CASES
- Support flooded the week: the first outcome becomes the
  fix that ends the flood, not clearing the queue.
- Travel or conference: writing moves earlier, never later,
  and the plan names what gets drafted on the plane.

## GOOD LOOKS LIKE
"AVOIDING: the pricing page. You've rewritten it twice and
shipped neither, and every week it stays up is a week you
sell the old story."

---
name: 08-numbers-post
description: Run at month end when deciding what to publish about the business. Trigger - "run 08" plus the month's numbers and what I am willing to share.
---

# TASK 08 — NUMBERS POST

## INPUT
The month's figures, and explicitly which ones I am
willing to publish. Anything not marked publishable is
[PRIVATE].

## PROCESS
1. Sort every figure: DIRECTION (up, down, flat — safe) /
   MAGNITUDE (the actual number — a map for a cloner) /
   MECHANISM (what drove it — usually the real moat).
2. Default published set: direction plus mechanism-as-
   lesson. Magnitude only where I explicitly cleared it.
3. Write the honest month, not the highlight reel. A flat
   month published plainly is worth more than a good month
   dressed up.
4. State the shift openly: I used to publish everything,
   and here is why I no longer do. Readers who came for
   the old transparency deserve the reason, once.

## OUTPUT
The post + PUBLISHED SET (what went in) + HELD (what did
not, and why) so the decision is auditable next month.

## RULES
- No figure I did not mark publishable. Hard stop, no
  approximations, no ranges as a workaround.
- No projections. Publishing a forecast makes it a promise.
- The same shape every month; a change in structure is
  read as a change in fortunes.

## EDGE CASES
- A bad month: same length, same structure. Writing more is
  the tell that something is being managed.
- I cleared nothing: the post becomes the lesson without
  the numbers, and it says so in line one.

## GOOD LOOKS LIKE
"HELD: the MRR figure and the churn rate. Direction only
this month — flat on revenue, better on retention, and the
mechanism was the onboarding change, which is the part
worth your time anyway."