Qv Docs Solution Create

Solutions Page Create

Publish one page in the Solutions collection of the documentation website.

Most documentation is written from the inside out: a feature exists, so it gets documented. Solutions works from the outside in. Someone brings a real scenario, the expansion team works through it with them, and the generalized answer becomes a page the next person with a similar scenario can reuse. The collection exists so that knowledge stops living only in chat threads, proofs of concept, and calls.

The expansion team writes most of these pages. The docs owner maintains this skill and the collection's editorial standard, so an author never has to remember the structure.

Read before drafting:

• references/editorial-contract.md — the frontmatter rules, the required and optional sections, and the heading conventions of this collection.
• docs/website/AGENTS.md — the authoring rules the website package sets for its own content and source.
• docs/website/README.md — the framework, content layout, build, and automation the package owns.

Defer to the package's own sources for anything about the site itself; this skill defines only what is specific to Solutions. Reuse the conventions the project already has, and never introduce a new abstraction where an existing one fits. Fill assets/solution-template.mdx.

Scope gate

Two checks run before drafting. Both must pass.

The first check classifies the material. Solutions documents how to build, deploy, or integrate something with QVAC. It is not a defect catalog.

Draft a Solution when the material is a use case: someone set out to achieve something with QVAC, and the recommended way to do it is now known.

If the material is a defect, a crash, an error message, a missing system library, an environment that fails to start, or a regression, do not draft a Solution. That knowledge belongs in the SDK's troubleshooting.mdx, which already carries the Situation / Cause / Solution shape for it. Say so and stop.

If the material is setting up or building an app on a platform the docs already teach, do not draft a Solution. That knowledge belongs in the matching tutorial under the SDK's tutorials/ — electron.mdx for Electron, expo.mdx for Expo. Say so and stop.

Both live inside the SDK's current documentation line, whose folder is the parenthesized one under docs/website/content/docs/sdk/. Resolve it from the version manifest in docs/website/src/lib/versions.ts rather than hard-coding a version.

If the material is an unresolved product gap with no working approach yet, recommend an issue instead of a page.

A Solution may state a known limitation and the architecture that works around it, as long as the subject of the page is the use case and not the defect.

A Solution may run on a platform a tutorial covers, as long as the subject of the page is the use case and not the platform setup. Link the tutorial under Related resources rather than repeating it.

The second check tests the objective against the site as it already is. State in one sentence the objective the page would serve, phrased as the reader's goal. Then search docs/website/content/docs/ for a page that already serves that same objective, by title, by description, and by content.

If a page already fulfills exactly that objective, do not draft a Solution. Name that page and stop. Propose extending it instead when the material adds something the page lacks.

Overlapping subject matter is not a reason to stop. Solutions indexes the documentation by scenario, while the rest of the site indexes it by surface, so the same facts legitimately appear on both axes. Only an identical objective blocks the page. Never restate a specification another page owns — summarize what the Solution needs and link that page under Related resources.

Ground the page

The source material is the trigger for the page, not its source of truth. A thread records what was believed when it was written, and the product moves. Re-verify every technical claim at the time of writing against:

• the current package manifests and source in this repository;
• the documentation pages the Solution will rely on;
• the release notes and API reference for the versions involved;
• the current state of any referenced issue or pull request, via gh.

Correct the material wherever the repository contradicts it. Never carry a workaround into a page after the fix has shipped. State no roadmap or forthcoming-support claim, and no performance figure that was not measured.

Intake and readiness

The material behind a Solution can arrive as any of these, alone or combined:

• chat threads;
• technical investigation;
• proofs of concept;
• tests;
• benchmarks;
• conversations with developers;
• context given directly in the prompt;
• code and configuration present in this repository;
• existing documentation.

Ask only for what is missing, one question at a time unless the author asks for a batch. A Solution is ready to draft when these are known:

• what the developer or company was trying to achieve;
• the environment, constraints, and requirements that decide when the page applies;
• the recommended approach and why it is preferable;
• which QVAC surfaces it involves, such as SDK API, CLI, HTTP server, addon, or model;
• what was tried and did not work, when that shaped the approach;
• what was actually tested, and on which hardware, model, quantization, and version.

If the recommended approach or its rationale would have to be invented, stop and ask. Label every assumption the author still has to confirm.