<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Márcio Florindo</title>
    <link>https://marcioflorindo.com/blog.html</link>
    <description>Writing on technical documentation, AI workflows, content architecture, and developer experience.</description>
    <language>en-us</language>
    <lastBuildDate>Tue, 19 May 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://marcioflorindo.com/feed.xml" rel="self" type="application/rss+xml"/>

    <item>
      <title>Writing is the output. This is the work</title>
      <link>https://marcioflorindo.com/post.html?slug=writing-is-the-output</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=writing-is-the-output</guid>
      <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
      <description>The label I&apos;ve been using for five years — technical writer — is accurate and fundamentally misleading at the same time. Accurate, because I write. Misleading, because writing is the output, not the work.</description>
    </item>
    <item>
      <title>AI doesn&apos;t replace tech writers — it gives them leverage</title>
      <link>https://marcioflorindo.com/post.html?slug=ai-does-not-replace-tech-writers</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=ai-does-not-replace-tech-writers</guid>
      <pubDate>Sat, 28 Mar 2026 00:00:00 GMT</pubDate>
      <description>There is a version of the AI narrative that tells you that AI writes content, therefore writers are obsolete. However this hasn&apos;t been my experience after a few months of building AI deeply into my daily workflow. AI has enabled me to do my job even better. Here&apos;s how.</description>
    </item>
    <item>
      <title>Separating what the AI knows from what the AI does</title>
      <link>https://marcioflorindo.com/post.html?slug=separate-ai-knowledge-from-actions</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=separate-ai-knowledge-from-actions</guid>
      <pubDate>Sat, 07 Mar 2026 00:00:00 GMT</pubDate>
      <description>As a technical writer, there are a lot of repetitive tasks I have to do manually that eat into my time. Over the past couple of months I&apos;ve been building a system of AI-assisted workflows that handles the mechanical parts of my job — the parts that eat hours without requiring much creative judgment. And it&apos;s genuinely changed how I work.</description>
    </item>
    <item>
      <title>Your AI assistant forgets everything between sessions — here&apos;s how I fixed that</title>
      <link>https://marcioflorindo.com/post.html?slug=blog-brain-system</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=blog-brain-system</guid>
      <pubDate>Sat, 07 Mar 2026 00:00:00 GMT</pubDate>
      <description>A colleague of mine built a system he calls Project Brains. The AI reads the context file first and starts every conversation already knowing what it needs to know. His core insight is that AI assistants become dramatically more useful when they have structured context to work from, not just raw files. So I built a system that captures those decisions automatically for my workflow, and makes them available in every future session.</description>
    </item>
    <item>
      <title>You don&apos;t need to remember 22 command names — the AI already knows them</title>
      <link>https://marcioflorindo.com/post.html?slug=blog-discovery-system</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=blog-discovery-system</guid>
      <pubDate>Thu, 05 Mar 2026 00:00:00 GMT</pubDate>
      <description>Over the past month or so I&apos;ve built 22 slash commands that automate different parts of my documentation workflow with OpenCode. But at some point around command number 15, I noticed that I didn&apos;t know what commands I had. So I built an automated system that lets the AI discover commands for me and suggests the best one bases on intent.</description>
    </item>
    <item>
      <title>The part before writing is the slowest part — so I automated it</title>
      <link>https://marcioflorindo.com/post.html?slug=automate-research</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=automate-research</guid>
      <pubDate>Wed, 25 Feb 2026 00:00:00 GMT</pubDate>
      <description>The other day I closed a P1 ticket that asked me to review a 5-lesson internal training course and figure out what was missing from our developer docs. The scope was big: compare the training material against hundreds of existing pages, identify content gaps, draft new conceptual documentation, and create follow-up tickets for anything out of scope. Normally, this kind of work takes the better part of a week. Research alone — reading the training, cross-referencing existing docs, searching the wiki, identifying stakeholders — can easily take a few days at least before you write a single word. This was exactly why I&apos;ve created a while back the `/research` command in [OpenCode](https://opencode.ai). Recently, I got to put it to the test for the first time with a big task, and the whole thing went from ticket to merged PR in about two working days.</description>
    </item>
    <item>
      <title>From one tool to a full toolkit: how I used AI to rename 4 products across 695 files in 3 days</title>
      <link>https://marcioflorindo.com/post.html?slug=ai-toolkit-rename-products</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=ai-toolkit-rename-products</guid>
      <pubDate>Fri, 20 Feb 2026 00:00:00 GMT</pubDate>
      <description>A few months ago, I was asked to lead the documentation side of a large product renaming project. So I build a whole toolkit with the help of AI to automate and accelerate this project.</description>
    </item>
    <item>
      <title>Building an AI research command for documentation tickets</title>
      <link>https://marcioflorindo.com/post.html?slug=research-command-tickets</link>
      <guid isPermaLink="true">https://marcioflorindo.com/post.html?slug=research-command-tickets</guid>
      <pubDate>Tue, 10 Feb 2026 00:00:00 GMT</pubDate>
      <description>Tech writers spend a lot of time researching before they can start writing. Gathering context for a Jira ticket means jumping between several other tickets, existing documentation, internal wiki pages with PRDs or technical specs, among other sources. To help speed up the process of researching, I&apos;ve used OpenCode to create a command that reads Jira tickets and researches all the appropriate sources.</description>
    </item>
  </channel>
</rss>
