> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zapier.com/llms.txt
> Use this file to discover all available pages before exploring further.

> [Template] Template for tutorial and quick-start pages on docs.zapier.com. Use when writing a learning-oriented, step-by-step page where the reader builds a working example end to end (a quick start, a first integration, a first API call). Diataxis type: Tutorial.

# SKILL

# Tutorial template

Use this template for a **tutorial**: a learning-oriented page where the reader follows numbered steps and ends with something that works. Quick starts are tutorials. This is the Tutorial quadrant in [dev-doc-types](../dev-doc-types/SKILL.md).

A tutorial is not a how-to. A tutorial teaches a skill through a guided, linear path with no branching ("you could also…"). A how-to helps a competent reader hit a known goal. If the reader already knows what they want and just needs the steps, write a [how-to](../template-how-to/SKILL.md) instead.

## When to use

* A quick start ("Make your first API call")
* A first end-to-end build ("Create your first trigger inbox")
* Onboarding a reader to a product area through a worked example

## Always apply

Apply all Foundational skills as you write — writing standards, accessibility, formatting, code examples, terminology. See [SKILLS-INDEX](../SKILLS-INDEX.md).

## Template location

[assets/template-tutorial.mdx](assets/template-tutorial.mdx) — structure and placeholders only. All writing rules live in this SKILL.md.

***

## Required sections (in order)

| Section                    | Purpose                                                                                                                                           |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Intro (no heading)         | One or two sentences: what the reader will build and why it is useful. Lead with the payoff. Link to the complete script if the tutorial is long. |
| `## Before you begin`      | Prerequisites as a bullet list with links (account, token, installed SDK). Nothing the reader has to hunt for later.                              |
| `## Step N: [verb phrase]` | One action per step. Each step has a runnable code block and states the expected result.                                                          |
| `## What you built`        | The success state. What now works, and what the response or output looks like.                                                                    |
| `## Next steps`            | 2–4 links to the logical next pages (a how-to, a concept, the reference).                                                                         |

## Writing the intro

* Lead with what the reader's code can do at the end, not "In this tutorial we will…".
* Keep it to one or two sentences.
* If the tutorial is long, link to the complete script: "In a hurry? Skip to the [complete script](#complete-script)."

## Writing steps

* **One action per step.** If a step contains "and" or "then", split it.
* Start each step heading with a verb: `## Step 1: Create an inbox`. Do not put "Step 1:" in the page title.
* Every step that involves an API call or SDK method needs a runnable `<CodeGroup>` example (cURL → TypeScript → Python).
* Carry values between steps with environment variables (`export INBOX_ID=...`), per [code-examples](../code-examples/SKILL.md).
* State the expected result after the action ("The response includes the new `inbox_id`."), so the reader can confirm they are on track.
* Keep the path linear. Move alternatives and edge cases into an `<Accordion>` or a linked how-to.

## Naming

* Title is a verb phrase describing the outcome: "Create your first trigger inbox", "Make your first API call".
* Do not name it "Tutorial" or put "Step 1" in the title.

### Quickstart pages

A quickstart is the fast, getting-started tutorial for a product or feature. Name every quickstart the same way so they are consistent in the sidebar and unique to search and agents:

* **Spelling:** one word, "Quickstart" (not "Quick start" or "quick-start").
* **`title`:** always scope it to the product or feature so the page is unique across sections. Use either `"<Product> quickstart"` (for example `"MCP quickstart"`, `"Trigger Inbox quickstart"`) or a verb phrase that names the product (`"Connect your AI to Zapier MCP"`). Never a bare `"Quickstart"`, which collides across sections.
* **`sidebarTitle`:** always `"Quickstart"`, so the nav stays short and scannable.
* **`description`:** state the task, with a time-to-value cue where it is honest (for example "Connect a web AI agent to Zapier MCP in under 5 minutes.").
* Update the page's `llms.txt` entry so its label matches the `title`.
* Prefer "quickstart" over "onboarding" for these pages: "onboarding" is ambiguous and collides with partner onboarding.

## Frontmatter

Set only `title` and `description` (see [formatting-guidelines](../formatting-guidelines/SKILL.md)). List prerequisites in the `## Before you begin` body section, not in frontmatter.

## Before you finish

Register the page in `docs.json` and update `llms.txt` ([contribute-docs](../contribute-docs/SKILL.md)), then run [review-before-done](../review-before-done/SKILL.md).