I just built a Distro skill, using Claude, that walks the AI through the sometimes painstaking and tedious job of writing a news story based on a press release.

Press releases are how companies announce things. Reporters rewrite them – pulling the facts, cutting the marketing voice, attributing the company's claims back to the company, and adding context the release leaves out. I've done that work a lot of times, going back to my first newsroom job in the mid-1990s. It's not glamorous. It is, however, a lot of what local and trade journalism actually consists of.

The skill encodes the small judgment calls that experienced reporters make without thinking about them: where the source link goes, how to attribute without parroting, when to break a quote with attribution, which marketing verbs to translate into plain English, what to leave on the cutting-room floor. None of that is in the press release itself. It's in the editing.

Here's how it works (on Claude Desktop, for now):

  1. Tell Claude to use the Distro release-rewrite skill to file a draft to your newslode based on the following url.

  2. Paste the url.

  3. Hit enter. (Claude does the work at this point.)

  4. Once Claude has written the draft, tell it to file the draft to your newslode using the Distro Publisher MCP.

  5. Review the draft and fact-check.

  6. From here you can either tell Claude what to change, or jump into the DistroVerse editing interface and edit there. You can also add a featured image using the DistroVerse editor.

The skill itself is published on Distro Skills, our skill registry – anyone with a Distro account can pull it down and install it. Source link: Distro release-rewrite skill on Distro Skills.

We're building in public here at Distro, and showing all of our work. Below this divider is the full, verbatim transcript of how this skill came together – from the first request to rewrite a MoonPay press release, through the editing pass where I changed several things in the draft, through the principle-extraction conversation that turned those edits into the skill itself.

The following is the full transcript of how I created the skill.

👤 BRAD:

I would like to write an article about this press release about MoonPay releasing a new way of using a crypto wallet to pay online merchants with a MasterCard debit card:
https://www.prnewswire.com/news-releases/moonpay-announces-moonagents-card-enabling-ai-agents-to-spend-stablecoins-anywhere-mastercard-is-accepted-302760128.html

For the style of this press release rewrite, I would like you to:

Please go through DeAI News and read about 20 of the hot takes and original stories to examine the style of those, and also please check out Brad's writing style.

Once you have done that, please use the following guidelines:

  1. the stories should have a straight lede about what the news is

  2. please assume that the readers don't know what these projects are, so you will have to describe what the project/company is or does. For this you can often find a description at the end of the press release, or maybe you might have to search prior DeAI News stories or as a last resort find their docs on the web. The end result would just be a simplified epithet, i.e. SingularityNET, a decentralized AI network,

  3. these press-release-based articles should be 4-5 grafs and no more than 250 words

  4. Use a professional, neutral but informed journalistic style; you are not a cheerleader and you are skeptical but curious

  5. explain why the company or project says this is important or useful or helpful, but attribute that - put it in their words not yours.

🙏

🤖 CLAUDE:

I'll start by examining DeAI News stories and Brad's voice, then read the press release.

🔧 Distro content list

Now let me read several full original Brad-bylined stories to understand the style. The Visa, Coinbase x402, Coinbase bazaar, and Bittensor stories look like original pieces – let me grab the full text of a few.

🔧 Distro content get
🔧 Distro content get
🔧 Distro content get
🔧 Distro content get
🔧 Distro content get

I have a strong sense of Brad's voice now. Let me also peek at the brads-voice skill, which is right here.

🔧 View file

I have everything I need on voice. Now let me read the actual MoonPay press release.

🔧 Web fetch

I have everything I need. Before drafting, one quick note on the framing — your question described this as "a way of using a crypto wallet to pay online merchants with a Mastercard debit card," but the headline news here is specifically that AI agents can spend stablecoins from an onchain wallet at any Mastercard merchant. I'll lead with that, since that's what makes it DeAI News material.

One question on byline before I publish:

🔧 Ask user input

Here's a draft for your review before I publish anything. Holding for the byline answer and your sign-off.

Headline: MoonPay rolls out Mastercard debit card for AI agents

Description: MoonPay: New "MoonAgents Card" lets agents spend stablecoins directly from an onchain wallet at any merchant that takes Mastercard.

Body:

MoonPay, a crypto payments network, said Friday it will issue a virtual Mastercard debit card that lets AI agents spend stablecoins directly from an onchain wallet at any online merchant that accepts Mastercard.

The new product, called MoonAgents Card, is being rolled out under an expanded partnership with self-custodial wallet provider Exodus and regulated card issuer Monavate. Stablecoin debit cards already exist, but MoonPay said theirs is the first designed to be managed programmatically by agents through its developer command-line tool, MoonPay CLI.

The card "extends" MoonPay's existing agent infrastructure, the company said in a press release, by giving agents a way to actually spend at merchants — something they couldn't do before. According to MoonPay, the card connects to a self-custodial wallet via a smart contract that authorizes access to stablecoin balances at the moment of purchase, with crypto-to-fiat conversion happening at checkout.

"Agents are already managing wallets, executing trades, and moving value onchain. The one thing they couldn't do was spend at a merchant. Now they can," said Ivan Soto-Wright, MoonPay's CEO and co-founder.

Wallet custody is never transferred and approvals can be revoked at any time, the release said. The card is available now through MoonPay CLI in the U.K. and LATAM, with U.S. and EU rollout planned in the coming months. Identity verification is required before issuance.

Word count: ~245. Source link will go to the PR Newswire release. Let me know the byline and any edits — happy to tighten, recast the lede, or swap quotes.

👤 BRAD:

Q: Which byline should this run under?
A: Bradley Keoun

🤖 CLAUDE:

Publishing as a draft to DeAI News (pub 109) with the Bradley Keoun byline.

🔧 Distro content publish
Filed as content ID 874 (draft).

Drafted as content ID 874 on DeAI News. Ready for your review in the Distro editor – let me know if you want any tightening, a different lede, or to push it live.

👤 BRAD:

all of the paragraph breaks in the body got lost. can you please fix those?

🤖 CLAUDE:

This is the distro_content_update requires HTML quirk – passing markdown collapses the breaks. Updating with explicit HTML paragraphs.

🔧 Distro content update

Fixed – paragraph breaks should now render properly in the draft.

👤 BRAD:

ok i have made some edits to the piece, and now I would like you to please analyze what I changed.

Where it's clear why I made the edits I made, please infer the general principle (please lmk what you infer so I can check/confirm that), and where you aren't sure, pls just ask.

one thing is that this is NOT a linked story but a release-rewrite story. it is a news story based on the press release. so the source in this case would not be Moonpay, and you would not include the source or the link in the metadata, but you DO want to weave in attribution to the press release along with the link in the body.

for your confirmations/questions here, let's please do those one-by-one rather than having a big checkilst

🤖 CLAUDE:

Got it. Let me pull the current version and diff it against my draft.

🔧 Distro content get

Got it. Let me note your framing point first – you're right, I had the source/sourceUrl populated as if this were a link-style story. For a release-rewrite, those metadata fields stay empty and the press-release link gets woven into the body instead, which is exactly what you did. Got it, won't make that mistake again.

Now, going through your edits one at a time:

Edit 1: Author changed from Bradley Keoun to Bradley Keoun, assisted by Claude.

Inferred principle: When a story is drafted with AI assistance – even when you've fact-checked and edited it yourself – disclose that in the byline. It's a transparency norm, not just for this piece.

Does that match? (And: should I bake this into a default for press-release rewrites going forward, or do you want to decide piece-by-piece?)

👤 BRAD:

yes, continue please

🤖 CLAUDE:

Confirmed on Edit 1, and I'll bake Bradley Keoun, assisted by Claude into the default for press-release rewrites going forward.

Edit 2: You added an editor's note at the top, in italics, inside parentheses:

(EDITOR'S NOTE: The first draft of this story was written on Claude Desktop using a custom skill designed to handle press-release rewrites. I then used Distro Publisher, our MCP server, to file a draft directly to DeAI News, and then used the DistroVerse editing interface to make some edits, and I personally checked all the facts prior to publication.)

Inferred principle: The byline disclosure ("assisted by Claude") tells readers AI was involved, but the editor's note shows them exactly how – which tools, which steps, and where the human judgment came in (fact-checking, editing). It's transparency about the agentic workflow itself, not just a disclaimer. This also doubles as a live demonstration of Distro's agentic-press thesis: the workflow is part of the story.

Open question: is this an every-time disclosure for press-release rewrites, or a sometimes-thing for stories where you want to showcase the workflow? My guess is it's the default for now (early-days agentic press, transparency matters), but you might dial it back later once it's table stakes – does that match?

👤 BRAD:

yes exactly on all of this! continue please

🤖 CLAUDE:

Confirmed.

Edit 3: In the lede, you changed:

  • "crypto payments network" → "crypto payments platform"

  • "said Friday it will issue" → "on Friday unveiled"

  • "onchain wallet" → "on-chain wallet"

Inferred principles:

a) "Platform" over "network" for MoonPay specifically – they're a payments processor/onramp, not an open network like Visa or x402. "Network" overstates the architecture. (Worth noting: their own release calls themselves a "payments network," but you're not bound by their framing.)

b) "Unveiled" over "said it will issue" – tighter, more active, and a wire-service verb that fits the press-release-rewrite register. Also avoids the slightly awkward "said... it will" construction.

c) "On-chain" hyphenated – house style, treats it as a compound modifier the way "off-chain" usually gets treated. (I had it un-hyphenated; I'll hyphenate going forward.)

Three distinct things in one edit – does that all match, or am I reading too much into any of them?

👤 BRAD:

yes perfect, continue please

🤖 CLAUDE:

Edit 4: In graf 2, you added attribution and the link to the press release:

  • "...regulated card issuer Monavate**, according to a [press release](...)**."

Inferred principle: This is the release-rewrite version of source attribution – instead of a top-line "MoonPay said in a press release," you weave a hyperlinked "according to a press release" into the natural flow of the second graf, after the first concrete factual claim that came from the release. It (a) gives the reader the receipt, (b) signals to them that this is a release rewrite (so they can calibrate skepticism), and (c) gets the link in early without the awkwardness of a parenthetical or a "(MoonPay press release)" tag.

Placement-wise: graf 2 rather than graf 1, because the lede should be clean news, and because graf 2 is where the supporting detail (Exodus, Monavate) lives – which is the natural anchor for "here's where this came from."

Does that match?

👤 BRAD:

yes exactly, please continue

🤖 CLAUDE:

Edit 5: In graf 3, you trimmed:

  • "the company said in a press release, by giving agents..." → "the company said, by giving agents..."

  • "...something they couldn't do before**.**" (you replaced my em dash with a comma)

Inferred principles:

a) Don't repeat the press-release attribution. Once you've established in graf 2 that this is sourced from a press release, every subsequent "the company said" is implicitly "in the press release." Repeating it is redundant and starts to feel like a disclaimer rather than reporting.

b) Comma over em dash here. I'm less sure on this one – possible reads: (i) you're rationing em dashes (one signature move per piece, not three), (ii) the clause "something they couldn't do before" is a tight appositive that flows better with a comma than the harder break of an em dash, or (iii) just a stylistic preference for this specific sentence.

Which of those is it – or something else?

👤 BRAD:

on a) yes this is right.

on b) there are two things. 1) readers hate em dashes in general b/c they are overused by AI bots in AI-assisted or AI-generated writing. Even though we are disclosing to readers that this piece is AI-assisted, we would like to avoid annoying them. 2) dashes are ok once in a while, especially for parentheticals when used sparingly, but I would like our style to use en dashes instead of em dashes, with a space before and after the end dash

🤖 CLAUDE:

Got it – both important and worth pinning down precisely. Let me restate to make sure I have it:

Em dashes: avoid in general. The signal-value they had in the brads-voice skill ("a signature move") gets cancelled out when readers associate them with AI slop, even with disclosure. So default to commas, periods, parentheticals, or en dashes instead.

En dashes with spaces: when a dash is the right move (parenthetical aside, mid-sentence pivot), use ` – ` (space, en dash, space) – not `—` (em dash, no spaces) and not `--` (double hyphen). And use them sparingly – once in a while, not every graf.

I'll update my mental model and the brads-voice skill's punctuation guidance accordingly. (Worth flagging next time we're in skill-editing mode – the current SKILL.md explicitly calls em dashes a "signature move," which is now wrong.)

Continuing –

Edit 6: In graf 4, you reworked the Soto-Wright quote. I had it as one continuous block:

"Agents are already managing wallets, executing trades, and moving value onchain. The one thing they couldn't do was spend at a merchant. Now they can," said Ivan Soto-Wright, MoonPay's CEO and co-founder.

You split it, putting the attribution after the first sentence:

"Agents are already managing wallets, executing trades, and moving value onchain," said Ivan Soto-Wright, MoonPay's CEO and co-founder. "The one thing they couldn't do was spend at a merchant. Now they can."

Inferred principle: Don't make the reader wait through three sentences of quote before learning who's talking. Wire-service convention: attribute after the first sentence (or first natural clause), then let the rest of the quote run. It also gives the punchy two-sentence kicker ("The one thing… Now they can") more rhetorical weight by letting it stand on its own after the attribution.

Does that match?

(Also: I notice there's a missing period after "co-founder" in the current draft – co-founder "The one thing – want me to fix that as a cleanup pass after we're done with the analysis?)

👤 BRAD:

For Edit 5 I meant to write - before and after the en dash, not before and after the end dash, if you can please acknowledge this before we move on to Edit 6 🙏

🤖 CLAUDE:

Acknowledged – "before and after the en dash," not "end dash." Got it. So the rule is: ` – ` (space, en dash, space), used sparingly.

Ready to continue with Edit 6 whenever you are.

👤 BRAD:

on Edit 6, yes exactly. please continue

🤖 CLAUDE:

That was the last edit I had flagged – but let me double-check I didn't miss anything by re-reading both versions side by side.

Going through your version once more against my draft:

  • Editor's note added ✓ (Edit 2)

  • Lede: "network" → "platform", "said Friday it will issue" → "on Friday unveiled", "onchain" → "on-chain" ✓ (Edit 3)

  • Graf 2: "according to a [press release]" added ✓ (Edit 4)

  • Graf 3: "in a press release" removed ✓ (Edit 5a)

  • Graf 3: em dash → comma ✓ (Edit 5b)

  • Graf 4: quote split with attribution moved up ✓ (Edit 6)

  • Author: "Bradley Keoun, assisted by Claude" ✓ (Edit 1)

One small thing I want to flag that's not really an "edit" but a typo in graf 4 of the current draft – the missing period after "co-founder" before the second part of the quote starts. That's almost certainly an artifact of the split and not intentional. Want me to fix that as a cleanup pass now?

And – to summarize the principles I'm taking away to apply going forward:

  1. AI-assisted byline disclosure on press-release rewrites by default

  2. Editor's note transparency about the agentic workflow (for now)

  3. "Platform" vs "network" – match the actual architecture, not the company's framing

  4. Wire-service verbs ("unveiled") and "on-chain" hyphenated

  5. For release-rewrites: link to the press release in graf 2 via "according to a press release," not in metadata

  6. Don't repeat press-release attribution after graf 2

  7. Avoid em dashes (AI-slop signal); use ` – ` (spaced en dash) sparingly when a dash is needed

  8. Attribute quotes after the first sentence, not after the whole block

Anything I'm missing or have wrong?

👤 BRAD:

yes please on the typo; thanks for catching that; pls fix. and thanks for the summary

🤖 CLAUDE:

🔧 Distro content update

Fixed – period restored after "co-founder" before the second part of the quote opens.

👤 BRAD:

ok thank you so much. Ok now I would like you to create a skill called the Distro release-rewrite skill. It should be generic for any newslode, not specifically for DeAI News.

The skill would guide you to write a story based on a press release using the style and editing principles we have outlined here. eventually it could be used by any Distro user to publish stories about press releases to their newslodes.

It would be up to the user to tell you which newslode to publish to.

But basically the command would be:

Please use the Distro release-rewrite skill on the following link and publish to TK newslode:
[user pastes url here}

-> where TK is the name of the newslode specified by the user.

And you would do the rest.

Can you please go ahead and generate that skill now?

🤖 CLAUDE:

Before I write the skill file, a few quick scoping questions so the skill actually behaves the way you want – taking these one at a time per your earlier instruction.

Question 1: How should the skill find the right newslode?

The user types something like "publish to Liqquidity's Newslode" – but the publish tool needs a numeric publicationId. There are a few ways to handle the lookup:

a) Always ask the user for the publication ID up front if it's not numeric in their command. Simple, but a little annoying.

b) List the user's publications via distro_content_list and match by name (fuzzy / case-insensitive). The user just types the name; the skill resolves it. If there's ambiguity or no match, ask.

c) Maintain a small lookup table inside the skill itself with your known publications (DeAI News = 109, Liqquidity's Newslode = 69, Hardcore Tech = 41, Distro Skills = 114, BubbyChubby's = 67, Distro Newslode = 68). Fast, but only works for you – not for "any Distro user," which is the goal you stated.

Which do you want? (Or a combo – e.g., try the lookup table first for known ones, fall back to listing publications?)

👤 BRAD:

I think if you don't already know the publicationID, you can just look it up using Distro Publisher?

🤖 CLAUDE:

Hmm – looking at the actual Distro Publisher tool list above, there's no list_publications or equivalent. The tools that take a publicationId (distro_content_list, distro_content_feed, distro_content_publish) all require you to already know the ID. distro_search searches content, not publications.

So the lookup-by-name path doesn't work without an extra round-trip – but there's a clean workaround: distro_content_list without a publicationId filter returns articles across publications, and each article in the response includes a publication object with both publication (name) and id fields. That's how the skill can resolve a name to an ID.

So the flow becomes:

  1. User says "publish to Liqquidity's Newslode"

  2. Skill calls distro_content_list (with no publicationId, maybe source: "publication" to scope to user's own pubs, limit ~50)

  3. Skill scans the returned articles for one whose publication.publication matches the requested name (fuzzy / case-insensitive)

  4. Pulls the ID from there

  5. If no match or ambiguous, ask the user

One caveat: this requires the user to have at least one article in the target publication. For a brand-new empty newslode, the lookup would fail. I'd handle that by falling back to "I couldn't find a publication called X – can you give me the publication ID?" which is a reasonable degraded state.

Does that approach work, or would you rather keep it simpler and just always ask for the ID if you haven't already provided it in the conversation?

👤 BRAD:

yes that works thanks

🤖 CLAUDE:

One more scoping question before I write – this one about the publishing flow:

Question 2: Should the skill always draft for review, or publish directly?

Three options:

a) Always draft, never publish directly. User reviews in Distro editor and publishes manually. Safest. This matches what you did this session, and what your existing skills (distro-link-post, distro-skill-publish) default to.

b) Always draft, then offer to publish after review in chat. Same as (a) but the skill explicitly asks "want me to flip it to published?" after the draft is filed. Slightly more guided.

c) Show the draft inline in chat first, get sign-off, then file as draft (or published). Most cautious – doesn't even create the draft on Distro until you've seen the prose. Good for first-time use of the skill on a new newslode where the user might want to course-correct on voice/length before anything hits the server.

My instinct is (c) for the first iteration – show the draft in chat, get sign-off, then file as draft to Distro. That mirrors what worked well in this session: you saw the prose, said go, I filed, you edited. But (a) is faster once you trust the skill.

Which feels right?

👤 BRAD:

how about C but then with the offer you describe in B?

🤖 CLAUDE:

Perfect, that's a clean flow. Let me write the skill now.

🔧 Bash
🔧 Create file

Now let me package it as a .skill file (zip) and put it in outputs so the native Save skill button shows up. First let me check the distro-skill-publish skill to see if there's a canonical packaging approach.

🔧 View file

Good context. Now let me package the new skill and present it for one-click install.

🔧 Bash
🔧 Present files

Packaged as distro-release-rewrite.skill – should show up with a native Save skill button for one-click install.

The skill encodes all the principles we worked through this session:

  • Trigger: "use the Distro release-rewrite skill on [URL] and publish to [newslode name]"

  • Newslode resolution: via distro_content_list scanning the publication object on returned articles, with fallback to asking for the ID

  • Flow: fetch → resolve → ask byline if needed → draft in chat → wait for sign-off → file as draft → offer to flip to published

  • Editorial principles: sentence-case headlines, wire-service lede with company epithet, press-release link in graf 2 via "according to a press release," no repeat attribution after that, split quote attribution after first sentence, no em dashes (spaced en dashes used sparingly when needed), on-chain hyphenated, [User], assisted by Claude byline, italic editor's note disclosing the workflow

  • Metadata rule: for release-rewrites, sourceName and sourceUrl stay empty – that's link-post territory

  • HTML-not-markdown for distro_content_update quirk noted

After you install and try it on the next press release, let me know what bites and I'll iterate. Want me to also publish it to your Distro Skills newslode (pub 114) as a draft so it's filed in the registry?

👤 BRAD:

yes, great idea, thanks - please go ahead and publish as draft on Distro Skills

🤖 CLAUDE:

Following the distro-skill-publish skill conventions: six-section story (intro, prereqs, features, install, source in four-backtick fence, when to use / not use, feedback), contentFormat: "markdown", draft status.

🔧 Distro content publish
Filed as content ID 875 on Distro Skills (pub 114), draft.

Filed as content ID 875 on Distro Skills (pub 114), as a draft. Edit link: https://app.distro.media/stories/875

So you've now got two artifacts from this session:

  1. distro-release-rewrite.skill in your downloads, ready for the one-click Save skill button

  2. Content ID 875 on Distro Skills as a draft, structured per your distro-skill-publish conventions (six sections, four-backtick fenced SKILL.md, install instructions for Desktop/Code/manual paths)

Once you've reviewed in the Distro editor and are happy, flip it live whenever – or let me know if you want any tweaks to the story copy first.

👤 BRAD:

Ok thank you so much. Here is what I would like you to do now. We will write a story in brad's writing style for Liqquidity's Newslode on what we have done here.

Hed:
How 3 decades of journalism informed Distro's press-release rewrite skill

Body:

I have just created a Distro skill using Claude that will guide the AI to handle the sometimes painstaking and tedious job of writing a news story based on a press release.

Here's how it works: (On Claude desktop, for now)

  1. Tell Claude to use the Distro release-rewrite skill to file a draft to a newslode based on the following url.

  2. Paste the url.

  3. Hit enter. (Claude will do the work at this point)

  4. Once Claude has written the draft, tell Claude to file a draft to your newslode using Distro Publisher MCP.

  5. Review the draft and fact-check.

  6. At this point you can tell Claude what to change, or you can go into the DistroVerse editing interface and edit there. You can also add a featured image using the DistroVerse editing tool.

🤖 CLAUDE:

Before drafting, two quick things – taking them one at a time per your earlier instruction.

Question 1: I want to clarify the headline.

You wrote "How 3 decades of journalism informed Distro's press-release rewrite skill" – but I'd flag that we didn't actually talk much about your three decades of journalism explicitly informing the skill design today. What we did was build the skill from a worked example: rewriting one press release together, you editing it, me extracting principles. Your journalism background is implicit in those edits – but the headline as written promises a piece that's about the experience-to-skill translation, which is a different (and probably more interesting) story than just "I made a skill."

Two options:

a) Lean into the headline as written – write it as a reflective piece where the lede pivots on the journalism-experience angle, and the how-it-works steps come after. Op-ed-leaning.

b) Match a more direct headline to the body you outlined – something like "I built a Distro skill that drafts news stories from press releases" – which fits the body content (announcement + numbered walkthrough) better.

Which is the piece you actually want?

👤 BRAD:

At the end of the body, we will have a separate section.

It will look like this:

***

The following is the full transcript of how I created the skill.

***

-> then I would like you to paste the entire transcript of this chat verbatim (up through this message). You can use Html for that so it would actually resemble a Claude Desktop chat even though it's inside Liqquidity's Newslode 🙏

-> the big idea here is that we are building in open here at Distro and showing all of our work

🤖 CLAUDE:

Got it – and the build-in-public framing is a great answer to my question 1, so I'll lean into the original headline. The journalism-experience angle becomes the why of the piece, with the steps as the how, and then the transcript as the show your work.

Two scoping notes before I draft:

a) Transcript length warning. This conversation is long – easily 30–40k+ characters of Q&A by now. The story body will be massive. That's fine for a "showing our work" piece, but worth flagging that the visible-above-the-fold content (the journalism reflection + numbered steps) will be a small fraction of the total. The transcript section becomes the bulk. I'll lay it out so the editorial top isn't drowned by the transcript below.

b) Faithful transcript reproduction. I'll reproduce the conversation verbatim – your messages and mine – including tool calls (rendered as readable summaries, not raw JSON, since raw tool-call JSON is unreadable and would balloon the length further). Style-wise I'll do a light Claude-Desktop-ish look in HTML: alternating user/assistant blocks with subtle visual distinction, monospace for code, italics for tool calls. No images, no fancy CSS that won't survive Tiptap.

Want me to proceed on both, or do you want raw tool-call JSON included for full fidelity?

👤 BRAD:

that is fine re the length - the goal is to show people how this was done, and also to show them how it works.

regarding what to show - I really just want people to see what I have seen here on Claude Desktop... you don't need to provide all of the details/jsons/tool calls etc that you don't show me here... however, I do want to see those little tool-call signifiers i.e. "Distro content publish" and "Distro content update" ... just as I see them in the chat here

🤖 CLAUDE:

Got it – show what you saw, with the tool-call signifiers as visual markers. I'll render those as small inline pill-style elements (just like Claude Desktop displays them) and skip the JSON payloads.

Let me draft this. First, let me confirm the Liqquidity's Newslode publication ID before I file anything.

🔧 Distro content list

Confirmed pub 69. Now drafting. I'll show you the editorial top in chat first, then explain how I'll handle the transcript section (and confirm before I file, since it's a long piece).

Here's the editorial top – the part above the transcript divider:

[Editorial top shown in chat – the same editorial top that appears at the top of this story]

Two notes on how I'll handle the transcript section:

Tool-call rendering. Each tool call will show as a small pill on its own line, like 🔧 Distro content publish or 🔧 Web fetch – matching what you see in Claude Desktop. No JSON, no parameter dumps. When the tool result is interesting (like "filed as content ID 874"), I'll surface that as a brief italic line under the pill.

My pre-tool-call narration. When I said "Let me pull the current version and diff it against my draft" before calling distro_content_get, I'll keep that in. When I said long internal-sounding "let me check the skill conventions" type stuff, I'll keep that too – it's part of showing how the work happens.

One thing I want to flag: the transcript will end with this very message you're reading right now – my draft + the question I'm about to ask. That's a little recursive but it's faithful to "verbatim transcript up through the previous message." I'll cut it cleanly at the end of the message before this one (your "show the tool-call signifiers" message), which is the natural cutoff.

Does this approach work? If yes, I'll generate the full HTML and show you a preview of the rendering before I file the draft to pub 69.

👤 BRAD:

perfect, thank you, please proceed

— end of transcript —

EDITOR'S NOTE: This story was originally published on Liqquidity's Newslode. The original is here.