SkillForge’s product site began as a real test of the SiteSorted website builder. SiteSorted continues as Iter0, while SiteSorted.co.nz remains the New Zealand prompt-to-build offering. The goal was not to ask for a generic landing page. We supplied the product behavior, audience, visual direction, prohibited claims, responsive rules, required sections, and proof boundaries, then preserved the untouched output before writing any manual revision.
The brief was deliberately demanding
The first viewport had to say “Build better agent skills without writing Markdown” and show the actual editor idea: a personal skill library, one editable target, one protected reference, and an ordinary-language build request. The page needed distinct browser and desktop journeys, truthful Windows and Mac status, review safeguards, a practical FAQ, and no fake customers, usage numbers, security badges, or vague AI superlatives.
Responsive behavior was part of the contract. The editor proof could not become an illegible miniaturized desktop screenshot on a phone. It needed to preserve the same information hierarchy as readable stages. Actions needed useful tap targets, and no content could rely on motion to remain understandable.
The first reference failed before authoring
Raycast was the original reference because its site has a strong product-proof rhythm and clear platform conversion. The SiteSorted server-side Raycast capture failed before the authoring stage. That failure was retained as evidence rather than silently replaced or described as a successful clone.
We then used Lex because its calm editorial surface matched the already accepted SkillForge editor direction. The instruction was explicit: keep useful composition and density, but replace every piece of Lex identity, copy, asset, testimonial, and number with original SkillForge material.
What the untouched first paint achieved
The SiteSorted MCP completed the Lex capture and returned a full responsive page rather than a blank shell. It established a warm-white visual field, restrained blue accents, a large product frame, workflow explanation, browser and desktop areas, trust content, FAQ, and conversion points. Desktop and 390-by-844 mobile captures were saved before manual edits.
The delivered structure gave the manual pass a useful starting hierarchy. It did not prove the actual account flow, AI endpoint, download, Electron application, or macOS package. Those product surfaces had to be implemented and tested in the SkillForge repository.
What manual revision changed after the first run
The manual revision replaced loose marketing language with verified product actions, reduced disclaimers, removed any claim not backed by the application, and rebuilt the product illustration around the real renderer. Browser copy was narrowed to account-scoped drafts stored in the current browser. Desktop copy was tied to installed Codex or Claude tools. Windows availability and Mac signing status were driven by current artifacts.
The mobile editor proof became a readable sequence instead of a shrunken canvas. The final Electron renderer was later rebuilt to match the same website frame at 1190 by 720 pixels: top status bar, build strip, personal library, wide target editor, protected reference, and bottom status bar.
Why the second brief became documentation
The marketing page explained SkillForge, but it was a weak home for practical material about writing, reviewing, testing, and moving skills between runtimes. Publishing disconnected search pages would have created a blog shaped by keywords. A documentation structure gives each topic a stable place in one learning path: start with the job, build the skill, compare it with an example, review the proposal, test the behavior, and choose where it belongs.
The second SiteSorted run therefore used Vercel Docs as the structural reference and the live SkillForge product as the factual source. The 10,008-byte brief included product behavior, current availability, proof limits, navigation, responsive rules, the required overview sections, and links to six captured SkillForge pages. It explicitly asked for original SkillForge content rather than copied Vercel wording or identity.
What the Vercel Docs pass delivered
The MCP returned a complete responsive documentation overview with a compact product header, persistent desktop navigation, an article column, an on-page table of contents, a real editor illustration, a runtime compatibility table, safety notes, and guided next steps. The untouched version-five HTML and matched desktop and mobile captures were saved before repository changes.
SiteSorted also returned its own needs-review result with 56 candidate issues. Several were broad design checks, while the final concrete warning said the hero spacing was compressed relative to the reference. That result was useful evidence, not a reason to publish generated HTML unchanged.
What manual integration changed after the second run
The hand-authored pass turned the one-page candidate into a shared documentation system. It added generated routes for sixteen substantial guides and field notes, reusable navigation and source sections, canonical metadata, structured data, sitemap and feed output, a searchable index, keyboard search, a mobile navigation drawer, and direct paths into the working editor and installer.
Every generated link was checked against an actual route because the untouched candidate included placeholders and paths that did not exist. The product claims were reconciled with the application again: browser drafts stay in the signed-in user’s current browser, the Windows installer is public, desktop AI uses installed Codex or Claude tools, and public Apple signing for the macOS build remains pending.
How the result was judged
We kept separate evidence for both untouched first paints and each manual round. The comparison used the source reference, SiteSorted output, and final page at matched desktop and mobile viewports. The final review checked hierarchy, links, semantic structure, responsive behavior, visible product truth, search, navigation, and accessibility. That separation matters: a later manual improvement should never be attributed to the builder.
The useful lesson
A detailed brief can make generated work much more relevant, but a marketing page remains a hypothesis until the product path exists. The website improved when each sentence was checked against the account endpoint, browser persistence, AI request, downloadable file, and packaged application. SiteSorted accelerated the first composition; product truth and launch verification still required direct implementation.