chore: improve blog skill and employees

Author: rolznz

.claude/agents/blog-researcher.md

@@ -38,12 +38,14 @@ Make sure to load alby bitcoin payments skill before starting.
 
 4. Use the cheapest viable parameters for the actual paid request — e.g. pass `?amountSats=10` if the service supports it, rather than paying the default amount.
 
-5. Pay with Alby tools, capture the full response.
+5. Pay with Alby tools, capture the full response. **Save the complete raw response to `/tmp/blog-research-response.json` immediately after receiving it.** Include the file path in the brief so the team lead can read it without re-fetching.
 
 6. If you need something Alby can't provide (a non-lightning API key, an account signup, a service that requires OAuth), **ask the user** — do not guess or skip.
 
 7. Repeat with variations only if there is a clear, specific reason — not to explore or compensate for uncertainty.
 
+8. **Never fetch a paid endpoint more than once.** If you need to process the response differently, read from the saved file. A second paid request is a waste of real money.
+
 ## Sat hygiene
 
 Every paid request costs real money. Treat each one as a deliberate decision, not a retry.

.claude/agents/blog-writer.md

@@ -73,6 +73,12 @@ The **CTA block must appear verbatim at the end of every post** — do not alter
 
 Leave `imageAlt` as `PLACEHOLDER` — the designer will fill it in after generating the image.
 
+## Never truncate paid API data
+
+If the research brief includes a `briefing`, `analysis`, `summary`, or similar field from a paid API response — include it **in full** in the post. That content is what was paid for; it is the most valuable thing in the article. Never shorten it, add `...`, or paraphrase it. Quote it verbatim and completely.
+
+The same applies to any structured response data (arrays of signals, market data, etc.) that the brief highlights as important — show real examples in full, not truncated fragments.
+
 ## Before writing: verify, don't infer
 
 If the brief contains any claim you cannot directly verify from the files provided — about why something was built, how it previously worked, what problem it solved, what changed and why — **stop and ask the lead** before writing.

.claude/skills/blog-post/SKILL.md

@@ -50,16 +50,6 @@ Image filename: `YYYY-MM-DD-{slug}.jpg`
 
 ---
 
-## Step 2b: Ask about a rant
-
-Before spawning the writer, ask the user:
-
-> "Would you like to add a **Roland's Rant** section — an honest, opinionated take on what was frustrating, broken, or surprising about the service? If yes, tell me what to include and I'll pass it to the writer."
-
-If the user provides rant content, include it in the brief to the writer. If they decline, proceed without it.
-
----
-
 ## Step 3: Spawn the writer
 
 Spawn a teammate using the `blog-writer` agent type, named `writer`.
@@ -120,7 +110,17 @@ Watch for errors. If the build fails, diagnose and fix before reporting success.
 
 ---
 
-## Step 8: Review
+## Step 8: Ask about a rant
+
+Now that the post is written, edited, designed, and built — ask the user once:
+
+> "Would you like to add a **Roland's Rant** section — an honest, opinionated take on what was frustrating, broken, or surprising about the service? If yes, tell me what to include and I'll add it."
+
+If the user provides rant content, delegate to the writer, then rebuild before showing the preview. If they decline, proceed to review.
+
+---
+
+## Step 9: Review
 
 Report to the user and wait for their feedback before proceeding: