# 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](/en/documentation/style-guide/content/tutorials/) 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](/en/documentation/style-guide/content/how-to-guides/).
- 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](/en/documentation/style-guide/writing/sentence-structure/) holds the rules.

## Structure

A Quickstart page follows the tutorial skeleton, with one difference: its stage headings carry no numbers. [Tutorials](/en/documentation/style-guide/content/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:

```mdx
import DocCardGroup from '@aziontech/webkit/doc-card-group'
import DocCard from '@aziontech/webkit/doc-card'
import Tabs from '~/components/webkit/Tabs.vue'

This guide instructs you through <outcome, framed as a first:
your first bucket, your first deployment>.

- <What the reader will have done, as a short bullet list>
- <...>

To <reach the outcome>, you create and connect these objects:

1. <The first object, and what creates it.>
2. <The next object, and what it must be linked to.>
3. <The last link, and what it makes reachable.>

---

<One sentence telling the reader to select an interface, when the page documents more than one.>

<Tabs client:visible sharedStore="interface">
<Fragment slot="tab.console">Console</Fragment>
<Fragment slot="tab.cli">CLI</Fragment>
<Fragment slot="tab.api">API</Fragment>
</Tabs>

## Prerequisites

- <What every interface needs.>

<Tabs client:visible sharedStore="interface">

<Fragment slot="panel.console">

- <What only this interface needs.>

</Fragment>

</Tabs>

## <Imperative verb phrase>

<What this stage produces, in terms every interface shares.>

<Tabs client:visible sharedStore="interface">

<Fragment slot="panel.console">

To <reach the stage outcome> in Azion Console:

1. <A procedure, numbered when it has two or more actions.>

<The outcome sentence: what the reader now has or sees.>

</Fragment>

<Fragment slot="panel.cli">

<...>

</Fragment>

<Fragment slot="panel.api">

<...>

</Fragment>

</Tabs>

## <Imperative verb phrase>

<...>

## <Imperative verb phrase that activates or verifies>

<...>

## Next steps

<DocCardGroup cols={2}>
  <DocCard title="Title" href="/path/" label="one sentence on why the reader would follow it." />
  <DocCard title="Title" href="/path/" label="one sentence on why the reader would follow it." />
</DocCardGroup>
```

## 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](/en/documentation/style-guide/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](/en/documentation/style-guide/content/tutorials/) 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](/en/documentation/agent-setup/), 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](/en/documentation/style-guide/writing/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](/en/documentation/style-guide/writing/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:

```mdx
This guide instructs you through running your first function on the Azion Web Platform.

- Create a function and write its code.
- Connect the function to an application and a workload.
- Verify that the function answers a request.

To run a function, you create and connect these objects:

1. A **function**, which holds the code.
2. A **function instance**, which binds the function to an application.
3. A **rule** in the Rules Engine, which decides the requests that trigger the instance.
4. A **workload**, which the application is linked to and which receives the traffic.

---

## Prerequisites

- An [Azion account](https://console.azion.com/).
```

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:

```mdx
Select the interface you will use. Every stage below follows that choice.

<Tabs client:visible sharedStore="interface">
<Fragment slot="tab.console">Console</Fragment>
<Fragment slot="tab.cli">CLI</Fragment>
</Tabs>

## Create the function

A function holds the code. It runs only once an instance binds it to an application.

<Tabs client:visible sharedStore="interface">

<Fragment slot="panel.console">

To create the function in Azion Console:

1. Access [Azion Console](https://console.azion.com/) > **Functions**.
2. Select **+ Function**.
3. Enter a **Name** for the function.
4. Select **Save**.

The function appears in **Functions**, which lists its **Last Editor** and **Last Modified**.

</Fragment>

<Fragment slot="panel.cli">

To create the function with the Azion CLI:

<Code client:visible lang="bash" code={`azion create function --name my-function --code ./index.js`} />

The command returns the function's ID, which the next stage binds to an application.

</Fragment>

</Tabs>
```

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

## Related

- [Tutorials](/en/documentation/style-guide/content/tutorials.md): The base form this pattern applies.
- [How-to guides](/en/documentation/style-guide/content/how-to-guides.md): Where the options and the alternatives go.
- [Information architecture](/en/documentation/style-guide/content/information-architecture.md): Where the page sits in a product section.
- [Choose a content type](/en/documentation/style-guide/content/choose-a-content-type.md): The full catalogue of page kinds.