Website Reports

A Claude Code toolkit for reviewing public websites and producing technical reports, with a plain-language version for founders who needed to decide what to fix.

Period
April 2026 – April 2026
Role
Research and development
Team
Solo, associated with VibeMastery
Stack
Claude Code, Skills and sub-agents, Mozilla Observatory, PageSpeed Insights, W3C Validator, WeasyPrint
Status
Closed

Website Reports came out of my work on VibeMastery. I wanted to inspect what an application exposed through its public website and turn that into a report its builder could use. A site could load and look finished while still leaving problems in the deployed application.

The toolkit used Claude Code skills to assign parts of a review to sub-agents. They inspected public responses and browser-delivered files, alongside checks from tools such as Mozilla Observatory and PageSpeed Insights. The scope was public inspection without signing in or changing the target application.

Scripts handled repeatable checks, including response headers and DNS records. Agents could then spend time reading the results and following questions specific to the site. That split mattered more to me than adding another category to a score.

A run kept its technical report and the agents' outputs together. Markdown was the source for the report. HTML and the WeasyPrint PDF were generated from it, so changing the report did not mean editing several versions.

The first reports assumed the reader knew what to do with a technical finding. I added a separate plain-language report for founders. It explained the problem and what needed attention. That was the change I learned most from. Finding a problem and explaining it to the person responsible for fixing it required different writing.

The project is closed, and there is no public repository for the toolkit. I am keeping the case study here because the reporting process is useful to remember. A technically detailed report still needs to help its reader choose a next action.