| name | Generate a pitch |
| description | Develops a focused pitch (title plus 150-200 word paragraph) that defines the scope, thesis, and suggested tags for a new article or newsletter. Use at the start of drafting any new post, after the idea is clear enough (use brainstorming first if it is vague). |
Generate a pitch
Overview
A pitch is a critical step in writing a blog that ensures that the aim of the post is clear and within a manageable scope.
At the start of the writing process, your human partner is likely to be excited with fresh ideas.
Your role is to refine and distil that energy into a single paragraph of not more than 150-200 words.
Success criteria
The pitch is perfect when:
- It can be used to develop an outline of a suitable length. Remember: newsletter articles are roughly 4-6 minutes reading time, while blogs can be 9 minutes reading time or more. Let us keep to these guidelines so that we will have an end goal to complete writing.
- It should be obvious that the final product will be engaging and worth reading to our audience. If we are not sure, let's consult our subagents for more direction.
- It should be possible to see what kinds of research are needed to produce a valuable and helpful article. Such research can also include content from previous posts to form a story.
- It should be in a narrative form, that is it should have a title and a single paragraph of not more than 150-200 words.
Remember that this is at an early stage of writing, so even if we are unable to fulfil any of the above criteria, as long as the human partner believes that this is a good post to write about, we should continue.
The process
Step 0: Create TodoWrite task list
Before starting pitch development, create a comprehensive todo list to track the entire post creation workflow:
- Develop pitch (brainstorming if needed)
- Research supporting evidence
- Draft content
- Content quality audit
- Target audience review
- Backlink curation
- Publish to Ghost
- Check published post and sync repo
- Update discussion notes
This ensures all quality checks are tracked from the start and never skipped.
Step 1: An idea
The human partner has suggested an idea which is suitable for developing a pitch. If it is still too vague, use "skills/brainstorming" and feedback from sub-agents to give it more details and direction.
Step 1.5: Read Voice Guide for Blog Posts and Newsletters
If developing a pitch for a blog post or newsletter, read /docs/Houfu_Voice_Guide.md Part 4 (Templates) to understand:
- How Houfu structures "News Commentary" posts vs "Learning in Public" posts
- What kind of openings resonate (feeling-first, not fact-first)
- How to frame the pitch in Houfu's voice
This ensures the pitch sets up the right structure and tone from the start.
Step 1.7: Ask for the User's Genuine Experience
Before drafting the pitch, ask ONE question:
"What's the specific personal experience, feeling, or moment that's driving this post? What happened — or what did you feel — that made you want to write this?"
Wait for the user's answer. This response is the source for the vulnerability hook and opening framing.
Do NOT invent a vulnerability hook. The emotional opening must come from the user's real experience. If the answer is vague ("I thought it was interesting"), ask a follow-up: "Can you be more specific — what exactly happened, or what did you notice?"
The pitch opening should be grounded in this real experience, not constructed from the post topic.
Step 2: Develop the pitch
From the idea, generate a pitch. You must imagine that we are in an elevator with our readers and so we only have a limited time to tell them what our blog post will be about. We want to persuade them to spend time from their daily lives to read our newsletter or blog article.
Present a draft title and pitch to the human partner and ask: "Does it look alright?" Once the human partner approves, we can move on to the next step.
Step 3: Authenticity Check
It is important to interrogate what is my personal angle in every post to ensure that I am writing my blog and not AI. Let us avoid authenticity issues so that we don't need to conduct expensive rewrites.
Ensure that the pitch is coming from me and not from others.
For each claim in pitch:
- Is this true to my experience? (Not aspirational or third-person)
- Can I cite a specific moment when I felt/learned this?
- Am I framing someone else's work as mine?
- Am I claiming expertise I don't have?
Red flags:
- "I learned that..." (Did you? Or did you always know this?)
- "Others might think..." (Distancing language)
- "One should..." (Who? Be specific)
Step 3.5: Verify the Data
A pitch is a hypothesis, not a finding. Before locking it:
- If the pitch contains numbers or factual claims (article counts, hours invested, download stats, adoption figures), verify them against the actual data now — run the query, check the repo, ask the user for the source. Two posts required full rewrites because pitch numbers were wrong ("444 articles" was actually 27; "600 hours" was actually ~150).
- For time-investment claims, ask the user for their lived numbers ("How many hours did this actually take? Evenings or full days?"). Never derive time estimates from lines of code or other formulas.
- If verification must wait (e.g., needs Ghost access), mark the claim in pitch.md as
[UNVERIFIED] so drafting doesn't treat it as fact.
Step 3.6: Interrogate the Pitch
Past pitch failures were catchable at this stage. Before locking, ask three questions and record the answers in pitch.md:
- Test the diagnosis. If the pitch is built on the user's own problem framing, probe it instead of accepting it: "Does [diagnosis] actually explain the tension? What would contradict it?" (single-serving-bias shipped a wrong diagnosis into a full draft; one probing question at pitch time surfaced the real insight.)
- The differentiation question. "This will always be 'another [X] post' — what makes ours different?" If there's no answer, the pitch isn't ready.
- The framing risk question. "Could a named person, company, or community read this as an attack?" If yes, decide now whether to anonymize or reframe — not after drafting (legal-oss-contribution had to anonymize its anchor example post-draft).
A pitch amended mid-draft is not a sin, but it means this step failed — when it happens, note in discussion.md which of these questions would have caught it.
Step 3.7: Seed Must-Link Posts and Timeline
- Identify 2-3 must-link prior posts this post builds on or contradicts (use
ghost_search). List them in pitch.md under "Prior work". This makes linking a structural decision instead of last-minute polish; full curation still happens at final draft via backlink_curating.
- Ask whether there's a target publish date or external deadline (talk, event, news hook). Record it in pitch.md — surprise schedule acceleration causes rushed metadata, images, and backlinks.
Step 4: Suggest Tags
After the pitch is approved, use the tag-registry skill to suggest appropriate tags:
- Analyze the pitch content to identify themes and topics
- Suggest 3-4 tags from the canonical registry
- Ensure at least 1 Core Topic tag is included
- Include the suggested tags in the pitch.md file
This early tag planning helps maintain consistency and prevents tag sprawl during publishing.
Step 5: Scaffold the post
- Create the folder structure using the title, for example "posts/ai-vs-lawyers-newsletter"
- Save the pitch in that folder under the file "pitch.md" (including suggested tags)
- Save the discussion using "skills/note-taking" under the file "discussion.md"
- Save any documents or links discussed during the process under the folder
Once this process is completed, you should ask the human partner whether you can develop the outline of the article.
