Concept template
When to use
Section titled “When to use”- Shelf:
learn/concepts/<topic>/ kind: concept- Diátaxis mode: explanation (one idea per page)
- Readers served: quick mental-model lookup; agents disambiguating terms before authoring
Shorter than a handbook chapter — one concept, one page.
Design rationale
Section titled “Design rationale”- One-sentence definition first — explanation docs must be repeatable by beginners (Diátaxis explanation).
- Why before how — motivation prevents rote memorization (inverted pyramid for technical concepts).
- How it works needs diagram for non-trivial flows — warrant test (visuals gate).
- When to use / avoid as paired sections — explicit boundaries reduce misuse (API design — document anti-patterns).
- Related links, not sequential next — concepts are non-linear (handbook/guide linking pattern).
Copy-paste skeleton
Section titled “Copy-paste skeleton”---title: "Concept name"description: One sentence definition a beginner can repeat back.sidebar: label: "Concept name" order: Ncategory: <topic>kind: conceptstatus: currenttags: [concept, topic]---
**<Concept>** is <one plain sentence>.
## Why it exists
The problem it solves — 2–4 sentences.
## How it works
\`\`\`mermaidflowchart LR A["Input"] --> B["Process"] --> C["Outcome"]\`\`\`
Numbered walkthrough if helpful (keep steps short).
## When to use it
- ✅ <good fit>
## When to avoid it
- ❌ <anti-pattern>
:::tip[Related][Handbook](/tech-stack/laravel/codecanyon/learn/handbooks/) · [Guide](/tech-stack/laravel/codecanyon/learn/guides/):::Anti-patterns
Section titled “Anti-patterns”- Do not turn concept pages into playbooks — link to Build for procedures.
- Do not skip diagram on multi-part processes.
- Do not use emoji-only bullets without prose context on public pages (prefer
-lists + short lead-in).
Worked example
Section titled “Worked example”- Content architecture — definitional opening, Learn vs Build, type lookup tables, Mermaid
Sources
Section titled “Sources”- Diátaxis — Explanation — single-idea concept pages.
- Google developer documentation style guide — Definitions — crisp definitional openings.
- Diátaxis — Overview — concept vs guide vs handbook depth.
- Doc components — warrant test — diagram triggers.
- Writing style → Doc-type spines