← Timeline

1 capture, most recent first. Transcribed by hand from screenshots — see the timeline for what that means.

@mhmazur

— web clipping, 763 words — published 2026-08-25

Post by @mhmazur on X

My SaaS's support docs are something I've always updated and served through my support desk service. I decided to move them into the app. I tasked Claude with "migrate all of my support docs over to the rails app. put the content in individual markdown files. copy the existing images into the app and serve them behind a cdn." It searched the codebase and found the URL of the support docs, then scraped the docs homepage. That included links to some docs, but more importantly, links to individual doc categories, which it followed to compile a list of 83 articles. Except there were 87. Help Scout paginates categories at 20 per page, so two articles were sitting on a page two nobody links to, and two more were published but filed under no category at all. Claude probed every article ID from 1 to 170 and found all four. It parsed the HTML of those pages to figure out where the content lived, and extracted the content of each page. One interesting thing: the support docs were served by Cloudflare, which automatically obfuscates email addresses so naive scrapers can't scrape emails. I asked Claude afterwards how it figured out what emails to use. It replied: \> The real address is right there in the markup, in a data-cfemail hex blob: 0f676a637f4f7f7d… The first byte is an XOR key. Here it's 0x0f = 0000 1111, so XOR just flips the low nibble of each byte that follows: 0x67→0x68 "h", 0x6a→0x65 "e", 0x63→0x6c "l", 0x7f→0x70 "p", then 0x4f→0x40 "@". Once "help@" fell out I knew the guess held and let code finish the rest. Clever. At one point Cloudflare throttled it, so it added backoff and retries and kept going. It built a parser but ran into issues (\<img> and \<p> sitting directly inside \<ol>, between the \<li>s) but worked through them, eventually converting every support doc from HTML into markdown. Then it checked its own work by diffing the rendered markdown against the live pages. 22,178 words in, 22,178 words out. Every image and every link accounted for. That's how it caught the malformed HTML in the first place: an article that came out empty. It downloaded 190 images and confirmed they'd be served behind the CDN. I told it I wanted to change the URLs from like /article/127-add-event-to-timeline to like /support/add-event-to-timeline. It did that and set up redirects so all the old URLs pointed to the new pages. The redirects resolve on the ID, not the slug, which turned out to matter: my own docs linked to four articles by slugs that had changed years ago. I asked it to look through the docs and recategorize anything as it saw fit. It recategorized 11 articles. I then said "add search functionality", so it built a new endpoint as well as the front-end so users could search the docs. It searched the codebase and found 33 links across 25 files still pointing at the old docs, and updated them all. I then told it "look through all the docs you created and verify the information is still accurate. some of it may be outdated and needs updating." It checked all 87 articles against how the product currently works. Not by reading them. It pulled every bolded UI label out of the docs and grepped the views for each one, then checked the numbers against the constants and the plan claims against the plan table. Two articles promised restrictions that don't exist anymore, including one telling free users to upgrade for a feature they already have. Nine articles named buttons that had been renamed. It fixed all of it. It also used its read-only access to the production database to look for content referencing the old doc URLs. It found one, and gave me the command to fix it. It then walked me through the changes I needed to make in Cloudflare to point the old docs subdomain at the new site. It deployed the code, waited for it to go live, then ran a bunch of cURL requests to make sure everything worked. I plan to update the deployment skill to review pushed changes and make sure the public docs reflect any key changes. Put another way: Claude will maintain the docs going forward, ensuring they're always accurate and up to date. This entire docs migration consumed maybe 30 minutes of my time. It would have probably taken me a week to do this manually in the past, and I wouldn't have done nearly as good of a job as Claude did. Pretty amazing.