Quickstart pages

Purpose

A Quickstart page is a tutorial whose goal is the first activation of one product: from not using it to the smallest working result. It follows the tutorial base form.

Quickstart is the per-product slot. The platform onboarding section at /documentation/get-started/ carries a similar name and is a different thing: it belongs to no product.

When to use

• Write a Quickstart page when a product needs a documented path to its first working result.
• Write at least one Quickstart page per product, as the entry point directly after the product Overview.
• Add an interface panel when a product’s first run goes through Azion Console, the Azion CLI, or the API.
• Do not write a Quickstart page for a task the reader already has in mind. That task needs a how-to guide.
• Do not compare interfaces or offer options inside a panel. A panel documents one interface, end to end.
• Do not write a separate Quickstart page for a feature. The pattern covers one whole product.

Register

Procedural: 20 words per sentence, one instruction per step, imperative and active. Tone: directive, plain, brisk, certain. Sentence structure holds the rules.

Structure

A Quickstart page follows the tutorial skeleton, with one difference: its stage headings carry no numbers. Tutorials argues each part, and this list names what the pattern requires. A page takes the title <Product> quickstart, whether it documents one interface or several in tabs. A page that exists because the stages could not be shared takes <Product> quickstart using <interface>: using Azion Console, using the Azion CLI, using the API, or using an AI agent.

Required components

• Opening move: This guide instructs you through <outcome>. followed by a short bullet list of what the reader will have done. Frame the outcome as a first: “your first bucket”, “your first deployment”.
• Object chain: after the opening move, name every object the reader creates and what each one must be linked to, in order. One short list, before the prerequisites.
• Prerequisites: a ## Prerequisites section with bulleted items. Each item is a link, a one-line command, or a noun phrase naming the requirement. A single prerequisite is a sentence, not a list.
• Stages: stage headings without numbers, ## <Imperative verb phrase>, in build order, ending in a stage that activates or verifies. (Optional) opens the heading of an optional stage: ## (Optional) Change the model the function calls. Each stage holds one procedure and ends with its outcome sentence. Where the stage carries interface tabs, the procedure and the outcome sentence sit inside each panel.
• Next steps: a ## Next steps closing, a DocCardGroup with one card per destination: the title, the link, and one sentence on why the reader would follow it.

Optional components

• An interface selector: one <Tabs client:visible sharedStore="interface"> block above the prerequisites, carrying the tab.* slots alone, when the page documents more than one interface. Each stage then carries a block of the same store holding only its panel.* slots.
• Screenshots: for a step whose visible result is a screen, not command output.
• Asides: rare. A tutorial full of note blocks tries to be reference material.

Template

Copy the template and replace each <placeholder>. A product with one interface drops the <Tabs> block and writes the procedure directly under the stage heading:

Rules

• State the object chain before the first step. Name every object the reader creates and what it must be linked to, in order. A quickstart that lists clicks without the composition model leaves the reader unable to repeat the result with different objects.
• The reader selects the interface once, at the top of the page. One <Tabs> block above the prerequisites holds the tab.* slots and nothing else: that is the only tab strip on the page. Each stage carries its own block of the same store, holding only panel.* slots, and renders no strip of its own. The stage heading and the sentence that introduces the stage stay outside the block, so the page keeps one table of contents entry per stage. Console first. The mechanics are in Components.
• Split the prerequisites as well. What every interface needs stays in the list. What only one interface needs goes in a panel block directly under it, so a reader never reads a requirement that is not theirs. Once a panel carries the item, drop the qualifier that named the interface.
• The tab selects the interface, not the path. Every panel creates the same objects, in the same stages, to the same verified outcome, and only the mechanics differ. This is why a quickstart uses tabs where a tutorial does not: the reader still chooses nothing about what they build.
• Give every block the same sharedStore="interface" and the same panel keys. The one selection then governs every stage, and follows the reader to the next page. A stage that omits an interface the selector offers opens on its own first panel, which silently moves the reader to another interface mid-page.
• Write each panel to be read alone. The lead-in names the interface, and the outcome sentence belongs inside the panel: Azion Console shows a list where the API returns a response body. Never write “as you selected above”: the selection does follow the reader to the next page, but a page that does not offer that interface opens on its own first panel.
• Split into separate pages when the stages cannot be shared. Interfaces that need different stages, or a different object chain, are different paths rather than different mechanics. Give each its own page, titled <Product> quickstart using <interface>, under one Quickstart group in the sidebar, Console first. The group is a menu parent, not a page. Name the siblings in one line under the opening move: Prefer the CLI? Refer to [<Product> quickstart using the Azion CLI](/path/).
• An AI-agent first run is always its own page. A path the reader drives by prompt shares no stage with a click path or a command. Title it <Product> quickstart using an AI agent, connected through the Azion MCP server, and name it in the sibling line.
• Document only an interface you have run end to end. Leave out a panel you cannot verify yet, rather than filling its steps from the other panels. A stale first-run path fails the reader at first contact.
• Write each stage as a procedure. Steps follow Procedures, and every stage ends with its outcome sentence.
• Refer to a stage by what it produces, never by number. The headings carry no numbers, so “the ID from stage 1” points at nothing. Name the object instead: “the id of the zone you created”, “curl, to send the final request”.
• Keep prerequisites to the minimum real set. Every item is a reason to abandon the page.
• End in a stage that activates or verifies. The reader leaves with proof of the working result.
• Link tutorials and the main how-tos in ## Next steps. Give each card its reason.
• Test every command before the page ships. One instruction per step, and a visible result at each one.
• Show the output after every command. The reader sees what success looks like before the next step depends on it. The rule is in Procedures.
• Place it directly after the product Overview.

Examples

This excerpt of a Quickstart page for Functions shows the opening move, the object chain, and the prerequisites:

The chain tells the reader why four objects exist before a single request reaches their code. Without it, the steps read as unexplained clicks.

This excerpt shows the selector at the top of the same page, then one stage. The strip is declared once; the stage block carries panels alone. The stage heading and the sentence that frames the stage sit outside the block, and each panel carries its own lead-in and its own outcome sentence:

Both panels reach the same object, so the stage heading and the object chain hold for either reader.

Related