docs(content): complete public frontend workflows for the Content Engine

.claude/skills/vitnode-docs/references/docs-site.md

@@ -40,7 +40,6 @@ Apply these checks to public documentation. Preserve access controls on private
 - Confirm changed pages through direct HTML/Markdown requests, metadata inspection, link checks, and the existing build. Use available crawl diagnostics when authorized. A successful check does not guarantee retrieval or citation by any service.
 
 Authoritative references for verification, not text to copy into reader-facing docs:
-
 - https://developers.google.com/search/docs/fundamentals/seo-starter-guide
 - https://developers.google.com/search/docs/appearance/ai-features
 - https://developers.openai.com/api/docs/bots

AGENTS.md

@@ -92,6 +92,8 @@ Pick one indicator per piece of pending work, by what is pending:
 - Document every new feature. Keep it simple, SEO-friendly, and understandable at any skill level.
 - Friendly and lightly funny tone - don't overdo it.
 - Skip big comments; code is self-documenting.
+- Docs call the VitNode API with `fetcher` (`rawFetcher` for generated Content Engine admin routes), never raw `fetch` or a browser-console snippet. A check that needs a request with no UI yet uses a small temporary component with a button.
+- Never end a page with a "Next step" (or "Next", "What's next") section; the sidebar and page footer link the following page. Use `## Related` for links worth following.
 - Developer-facing APIs in feature code (exports of `@vitnode/core` and plugins that app or plugin authors call) need concise English JSDoc on the original declaration:
   - Say what it is for, plus constraints, side effects, runtime (server-only, browser-only or universal) and `@throws` only when they are real and non-obvious.
   - Document configuration properties one by one, including non-obvious defaults and constraints.