Kit page template

When to use

• Shelf: resources/kits/<topic>/<slug>/
• kind: kit
• Diátaxis mode: how-to (goal-oriented install procedure)
• Readers served: beginners who want a bundle + script; perfectionists who need verify steps; agents that must run seed.sh and fill placeholders in order

Full rules: Writing style → Doc-type spines.

Design rationale

• Installation guides are a distinct doc type — Good Docs separates “how to install/configure” from tutorials and reference; kits are install artifacts, not teaching journeys (Good Docs installation guide).
• Download before Steps — readers must possess the bundle before commands make sense; putting Download first reduces “command failed: file not found” support load.
• Numbered Steps, not prose paragraphs — Diátaxis how-to guides assume the reader already decided to act; steps should be scannable and executable in order (Diátaxis how-to guides).
• <FileTree> after Steps — inventory belongs after the reader knows why they ran the installer; tree answers “what landed on disk?” without blocking the critical path (Google developer documentation — file structure).
• Playbook links for why, kit for what — the kit page installs; the playbook teaches. Splitting concerns avoids duplicating Phase-level narrative on every kit page (Diátaxis — don’t mix tutorial and how-to on one page).
• Placeholder table — install docs fail when <YOUR_APP_NAME> is ambiguous; an explicit table maps token → file → example (Good Docs installation guide — configuration).

Section	Job	Why it’s here
What this kit is	One-paragraph scope + playbook link	Orients before download
Which steps it shortcuts	Honest scope (e.g. steps 3–6)	Prevents “kit replaces whole playbook” confusion
Prerequisites	Gates before download	How-to assumes readiness
Download	Get the bundle	Install docs start with acquisition
Steps	Numbered install procedure	Executable spine
What’s inside	<FileTree> inventory	Reference after action
Placeholders	Table of tokens	Reduces misconfiguration
Troubleshooting	Common failures	How-to safety net
Full walkthrough	Links to playbook steps	Tutorial context without re-teaching

Copy-paste skeleton

Use in .mdx when you need <FileTree>.

---
title: "<Topic> kit"
description: One sentence — what the kit installs and which playbook phase it supports.
kind: kit
category: <topic>
subcategory: <slug>
format: other
downloadUrl: /kits/<slug>/MANIFEST.md
sidebar:
  order: N
tags: [kit, topic]
---

import { FileTree } from '@astrojs/starlight/components';

<p class="eyebrow">Resources · kit · &lt;topic&gt;</p>

Companion kit for **[Phase N · &lt;phase name&gt;](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/01-ai-system/)**. Copy into the project root, run `seed.sh`, fill placeholders, restart the session.

## What this kit is

&lt;2–3 sentences: bundle scope, not the full playbook.&gt;

## Which playbook steps it shortcuts

&lt;Honest list — e.g. steps 3–6 after steps 1–2 are done manually. Link to each step.&gt;

## Prerequisites

- &lt;Tool / phase gate&gt;
- &lt;Prior steps completed&gt;

## Download

&lt;Link to MANIFEST or zip — `/kits/...` or `/resources/kits/...`&gt;

## Steps

### 1. Copy the kit into the project root

&lt;One sentence. Where to extract; what `dot-*` prefix means if applicable.&gt;

\`\`\`bash
# Expected: kit files at repo root (or printed path from seed.sh)
\`\`\`

### 2. Run the installer

\`\`\`bash
bash seed.sh   # Expected: dot-* renamed; placeholders listed
\`\`\`

### 3. Fill placeholders

&lt;Point to table below; no secrets in docs.&gt;

### 4. Pick mode / restart session

&lt;Permission mode, IDE restart, or verify command.&gt;

### 5. Verify

&lt;Link to playbook verify step; 2–3 observable checks.&gt;

- [ ] &lt;Check 1&gt;
- [ ] &lt;Check 2&gt;

## What's inside

<FileTree>
- &lt;file-or-folder&gt;
- …
</FileTree>

[Browse the kit files →](/kits/…/MANIFEST.md)

## Placeholders

| Placeholder | You fill with | File |
| --- | --- | --- |
| `&lt;APP_NAME&gt;` | Product name | `AGENTS.md` |
| … | … | … |

## Troubleshooting

### &lt;Failure mode&gt;

&lt;Fix in 1–3 sentences.&gt;

## Full walkthrough

The playbook steps explain *why* — use them when adapting beyond the kit:

1. [&lt;Step title&gt;](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/)
2. …

Anti-patterns

• Do not ship a kit page with only a <FileTree> and no ## Steps (install procedure missing).
• Do not claim the kit replaces the whole playbook without listing which steps remain manual.
• Do not put secrets or real credentials in placeholders examples.
• Do not use playbook step spine (## TL;DR → ## Checklist + :::next) on a kit page — use this install spine instead.

Worked example

• CodeCanyon AI System kit — refactor target for this template
• System docs examples

Sources

• Good Docs Project — Installation guide template — Download → Prerequisites → Steps → Verify/installation spine for kit pages.
• Diátaxis — How-to guides — goal-oriented, assumes decision to act; distinct from tutorial/playbook teaching pages.
• Diátaxis — Overview — separation of how-to (kit install) from tutorial (playbook walkthrough).
• Google developer documentation style guide — Procedures — numbered steps, expected outcomes after commands.
• Writing style → Doc-type spines — ZajLibrary constitution for kit vs playbook vs template asset types.