Clean up release highlights copy and removing emdash from the docs (#5984)
This commit is contained in:
Kartik
+4
-4
@@ -10,17 +10,17 @@ API reference pages document a single endpoint contract. Present metadata, reque
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter must include `title`, `description`, `icon`, `method`, `path`. Heading should be `# METHOD /path`.
|
||||
- Provide a quick facts table (Method, Path, Auth, Rate limit) followed by an `<Info>` block describing when to use the endpoint. Add `<Warning>` for beta headers or scope requirements.
|
||||
- Requests require headers table, body/parameters table, and `<CodeGroup>` with cURL, Python, TypeScript. If a language is unavailable, include a `<Note>` explaining why.
|
||||
- When migrating an existing endpoint page, keep the canonical examples and edge-case notes—drop them into these sections rather than inventing new payloads unless the API changed.
|
||||
- When migrating an existing endpoint page, keep the canonical examples and edge-case notes. Drop them into these sections rather than inventing new payloads unless the API changed.
|
||||
- Response section must show a canonical success payload, status-code table, and troubleshooting tips. Document pagination/idempotency in `<Tip>` or `<Note>` blocks.
|
||||
- End with related endpoints, a sample workflow link, and two CTA cards (left = concept/feature, right = applied tutorial). Keep the comment reminder for reviewers.
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
|
||||
````mdx
|
||||
---
|
||||
@@ -108,7 +108,7 @@ const response = await fetch("https://api.mem0.ai/v1/memories", {
|
||||
|
||||
| Status | Meaning | Fix |
|
||||
| --- | --- | --- |
|
||||
| `201` | Memory stored successfully. | — |
|
||||
| `201` | Memory stored successfully. | N/A |
|
||||
| `400` | Missing required field. | Provide `user_id` and `memory`. |
|
||||
| `401` | Invalid or missing API key. | Refresh key in dashboard. |
|
||||
|
||||
|
||||
+2
-2
@@ -10,7 +10,7 @@ Concept guides establish a shared mental model before feature or API docs. Defin
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter must include `title`, `description`, `icon`. Lead with a definition + analogy in two sentences max.
|
||||
- Add an `<Info>` block (“Why it matters”) with 2–3 bullets summarizing user impact. Use `<Warning>` near limitations or beta callouts.
|
||||
- Introduce vocabulary via `## Key terms` (table or bullets) before diving deeper.
|
||||
@@ -21,7 +21,7 @@ Concept guides establish a shared mental model before feature or API docs. Defin
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
|
||||
````mdx
|
||||
---
|
||||
|
||||
Vendored
+9
-9
@@ -10,24 +10,24 @@ Cookbooks are narrative tutorials. They start with a real problem, show the brok
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Tell a story: problem → broken demo → iterative fixes → production patterns.
|
||||
- Keep tone conversational; use real names ("Max", "Sarah"), not `user_123`.
|
||||
- Opening must stay tight: ≤2 short paragraphs (no bullet lists) before the first section.
|
||||
- Inline expected outputs immediately after each code block.
|
||||
- When modernizing an existing cookbook, keep the narrative beats, screenshots, and sample outputs—reshape them into this arc instead of rewriting unless the workflow changed.
|
||||
- When modernizing an existing cookbook, keep the narrative beats, screenshots, and sample outputs. Reshape them into this arc instead of rewriting unless the workflow changed.
|
||||
- Limit callouts to 3–5 per page. Prefer narrative text over stacked boxes.
|
||||
- Always provide Python **and** TypeScript tabs when an SDK exists for both.
|
||||
- Every page must end with exactly two navigation cards (left = related/side quest, right = next cookbook in the journey).
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
Paste the block below into a new cookbook, then replace all placeholders. Remove any section you don't need **only after** the happy path works.
|
||||
|
||||
```mdx
|
||||
---
|
||||
title: [Cookbook title — action oriented]
|
||||
title: [Cookbook title: action oriented]
|
||||
description: [1 sentence outcome]
|
||||
---
|
||||
|
||||
@@ -132,14 +132,14 @@ Call out the most common mistake or edge case for this layer.
|
||||
|
||||
## Production Patterns
|
||||
|
||||
- **[Pattern 1]** — `[When to use it]`
|
||||
- **[Pattern 1]**: `[When to use it]`
|
||||
```python
|
||||
# Example snippet
|
||||
```
|
||||
```typescript
|
||||
// Example snippet
|
||||
```
|
||||
- **[Pattern 2]** — `[When to use it]`
|
||||
- **[Pattern 2]**: `[When to use it]`
|
||||
```python
|
||||
# Example snippet
|
||||
```
|
||||
@@ -149,9 +149,9 @@ Call out the most common mistake or edge case for this layer.
|
||||
|
||||
## What You Built
|
||||
|
||||
- **[Capability 1]** — [How the cookbook delivers it]
|
||||
- **[Capability 2]** — [How the cookbook delivers it]
|
||||
- **[Capability 3]** — [How the cookbook delivers it]
|
||||
- **[Capability 1]**: [How the cookbook delivers it]
|
||||
- **[Capability 2]**: [How the cookbook delivers it]
|
||||
- **[Capability 3]**: [How the cookbook delivers it]
|
||||
|
||||
## Production Checklist
|
||||
|
||||
|
||||
+3
-3
@@ -19,7 +19,7 @@ Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Ad
|
||||
- Frontmatter stays outcome-driven: `title`, `description`, `icon`, optional `badge` (e.g., “Advanced”).
|
||||
- Opening paragraph = two sentences: problem, then payoff. Keep energy high right from the start.
|
||||
- Include an `<Info>` block titled “You’ll use this when…” with 3 bullets (user persona, workload, expected benefit).
|
||||
- When reshaping legacy feature docs, carry over existing diagrams, tables, and gotchas—organize them under these headings rather than replacing them unless the product has changed.
|
||||
- When reshaping legacy feature docs, carry over existing diagrams, tables, and gotchas. Organize them under these headings rather than replacing them unless the product has changed.
|
||||
- If there’s a known caveat (pricing, performance), surface it early in a `<Warning>` so readers don’t get surprised later.
|
||||
- Optional but encouraged: add a Mermaid diagram right after the intro to show how components connect; delete it if the story is obvious without visuals.
|
||||
- Add a `## Configure access` snippet (even if it’s “Confirm your Mem0 API key is already configured”) so contributors never forget to mention the baseline setup.
|
||||
@@ -30,7 +30,7 @@ Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Ad
|
||||
2. **Configure it** – Step-by-step enabling instructions with `<CodeGroup>` or JSON/YAML snippets. Follow each code block with a short explanation of why it matters.
|
||||
3. **See it in action** – End-to-end example (often reusing operation snippets). Pair code with `<Info icon="check">` for expected results and `<Tip>` for optimization hints.
|
||||
- Insert `<Note>` blocks for cross-links (e.g., “Also available via REST endpoint `/v1/...`”).
|
||||
- Keep the tone instructive but light—no long manifestos.
|
||||
- Keep the tone instructive but light. No long manifestos.
|
||||
|
||||
### 3. **End – Evaluate and go deeper**
|
||||
- Add an `## Verify the feature is working` section with bullets (metrics, logs, dashboards).
|
||||
@@ -118,7 +118,7 @@ Walk through a real request/response. Include sample payloads and highlight nota
|
||||
|
||||
## Best practices
|
||||
|
||||
- Keep criteria minimal—overfiltering hurts recall.
|
||||
- Keep criteria minimal. Overfiltering hurts recall.
|
||||
- Pair with Memory Filters for hybrid scoring.
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
+6
-6
@@ -10,17 +10,17 @@ Integration guides prove a joint journey: configure Mem0 and the partner with mi
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter must include `title`, `description`, `icon`, and optional `partnerBadge`/`tags`. State the joint value in one sentence right after the H1.
|
||||
- List prerequisites for **both** platforms inside an `<Info>` block. Surface limited-access or beta flags in a `<Warning>` before any setup.
|
||||
- Default to Tabs + Steps when instructions diverge (Platform vs OSS, Python vs TypeScript). When only one path exists, add a `<Note>` explaining the missing variant.
|
||||
- When migrating an existing integration, keep the proven steps/screenshots—map them into this structure rather than rewriting unless either product has changed.
|
||||
- When migrating an existing integration, keep the proven steps/screenshots. Map them into this structure rather than rewriting unless either product has changed.
|
||||
- Keep any Mermaid diagrams optional and left-to-right (`graph LR`) to avoid vertical overflow; use only if architecture clarity is needed.
|
||||
- Every major step must finish with a verification `<Info icon="check">`. End the page with exactly two CTA cards (left = related reference, right = next integration/cookbook).
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
Paste the block below, replace placeholders, and delete optional sections only when unnecessary for this integration.
|
||||
|
||||
````mdx
|
||||
@@ -31,7 +31,7 @@ icon: "puzzle-piece"
|
||||
partnerBadge: "[Partner name]" # Optional
|
||||
---
|
||||
|
||||
# [Integration headline — Mem0 + Partner promise]
|
||||
# [Integration headline: Mem0 + Partner promise]
|
||||
|
||||
Combine Mem0’s memory layer with [Partner] to [describe the joint outcome].
|
||||
|
||||
@@ -168,8 +168,8 @@ partner.registerTool("recallPreferences", async (userId: string) => {
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- **[Issue]** — `[Fix or link to partner docs]`
|
||||
- **[Issue]** — `[Fix or link to Mem0 troubleshooting guide]`
|
||||
- **[Issue]**: `[Fix or link to partner docs]`
|
||||
- **[Issue]**: `[Fix or link to Mem0 troubleshooting guide]`
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
|
||||
+6
-6
@@ -10,18 +10,18 @@ Migrations lower blood pressure. They explain what’s changing, why it matters,
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Keep the frontmatter complete (`title`, `description`, `icon`, `versionFrom`, `versionTo`, and optional `releaseDate`). Readers should know at a glance what versions they are moving between.
|
||||
- Start with context: summary table + “Should you upgrade?” checklist. Highlight deadlines with `<Warning>` and call out optional paths with `<Tip>`.
|
||||
- Break the body into **Plan → Migrate → Validate**. Use numbered headings inside **Migrate** and put rollback instructions directly after any risky step.
|
||||
- When porting older migration guides, keep existing change tables, screenshots, and warnings—slot them into this format unless the upgrade path has materially changed.
|
||||
- When porting older migration guides, keep existing change tables, screenshots, and warnings. Slot them into this format unless the upgrade path has materially changed.
|
||||
- Document breaking changes with an `Old behavior` vs `New behavior` table. Use `<Info icon="check">` for mandatory verification steps.
|
||||
- Optional flow diagrams are allowed, but only when a left-to-right Mermaid (`graph LR`) clarifies the upgrade path.
|
||||
- End with two CTA cards (left = deep dive reference, right = applied example) and keep the comment reminder for reviewers.
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
Paste the block below, swap placeholders, and delete optional sections only after you’ve confirmed they aren’t needed.
|
||||
|
||||
```mdx
|
||||
@@ -34,7 +34,7 @@ versionTo: "[target version]"
|
||||
releaseDate: "[YYYY-MM-DD]" # Optional
|
||||
---
|
||||
|
||||
# [Migration headline — state the move]
|
||||
# [Migration headline: state the move]
|
||||
|
||||
| Scope | Effort | Downtime |
|
||||
| --- | --- | --- |
|
||||
@@ -130,8 +130,8 @@ npm install mem0ai@[version]
|
||||
|
||||
## Known issues
|
||||
|
||||
- **[Issue name]** — `[Status]`. `[Workaround or link]`.
|
||||
- **[Issue name]** — `[Status]`. `[Workaround or link]`.
|
||||
- **[Issue name]**: `[Status]`. `[Workaround or link]`.
|
||||
- **[Issue name]**: `[Status]`. `[Workaround or link]`.
|
||||
|
||||
## After you migrate
|
||||
|
||||
|
||||
+4
-4
@@ -10,18 +10,18 @@ Operation guides focus on a single action (add, search, update, delete). Show th
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter needs `title`, `description`, `icon`. Title should be a verb phrase (“Add Memories”).
|
||||
- Lead with a two-sentence promise (problem → outcome), followed by an `<Info>` prerequisites block and optional `<Warning>` for hazards (overwrites, rate limits).
|
||||
- Include a “When to pick this” bullet list (≤3 items) so readers confirm they’re in the right doc.
|
||||
- Use Tabs with Python and TypeScript examples. If only one SDK exists, add a `<Note>` stating that explicitly.
|
||||
- When migrating legacy guides, keep existing code paths and notes—slot them into these sections instead of replacing them unless behavior changed.
|
||||
- When migrating legacy guides, keep existing code paths and notes. Slot them into these sections instead of replacing them unless behavior changed.
|
||||
- Provide `<Info icon="check">` verification after each critical step; call out the most common error with a `<Warning>` close to where it can occur.
|
||||
- End with exactly two CTA cards: left = conceptual depth, right = applied example/cookbook.
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
|
||||
````mdx
|
||||
---
|
||||
@@ -30,7 +30,7 @@ description: [Outcome in one sentence]
|
||||
icon: "bolt"
|
||||
---
|
||||
|
||||
# [Operation headline — say what it does]
|
||||
# [Operation headline: say what it does]
|
||||
|
||||
[State the problem this solves.] [Explain the outcome after running it.]
|
||||
|
||||
|
||||
+5
-5
@@ -10,18 +10,18 @@ Parameter references document every input/output detail for one operation after
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter requires `title`, `description`, `icon`. Titles should mirror the operation (“Add Memories Parameters”).
|
||||
- Place canonical Python and TypeScript signatures right under the heading using `<CodeGroup>`. Mention defaults or breaking changes in an `<Info>` or `<Warning>` immediately after.
|
||||
- Parameter table must include columns: Name, Type, Required, Description, Notes. Add a Managed/OSS distinction either as a column or in Notes.
|
||||
- When updating legacy parameter sheets, keep the authoritative field lists and notes—reformat them into this structure rather than trimming details unless the schema changed.
|
||||
- When updating legacy parameter sheets, keep the authoritative field lists and notes. Reformat them into this structure rather than trimming details unless the schema changed.
|
||||
- Response table must include Field, Type, Description, Example. For nested objects, add subtables or `<CodeGroup>` JSON snippets beneath the row.
|
||||
- Examples section should show minimal Python and TypeScript calls with one-sentence explanations. If a language is missing, include a `<Note>` explaining why.
|
||||
- Finish with related operations, troubleshooting tied to parameter misuse, and a two-card CTA (operation guide on the left, cookbook/integration on the right).
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
|
||||
````mdx
|
||||
---
|
||||
@@ -127,8 +127,8 @@ These snippets confirm the method returns the new `memory_id` for follow-up oper
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- **`400 Missing user_id`** — Provide either `user_id` or `agent_id` in the payload.
|
||||
- **`422 Metadata too large`** — Reduce metadata size below 2KB (OSS hard limit).
|
||||
- **`400 Missing user_id`**: Provide either `user_id` or `agent_id` in the payload.
|
||||
- **`422 Metadata too large`**: Reduce metadata size below 2KB (OSS hard limit).
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
|
||||
+5
-5
@@ -10,28 +10,28 @@ Quickstarts are the fastest path to first success. Each page should configure th
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Keep the intro tight: one-sentence promise + `<Info>` prerequisites. Add `<Warning>` only for blocking requirements (e.g., “requires paid tier”).
|
||||
- Default to Python + TypeScript examples inside `<Tabs>` with `<Steps>` per language. If a second language truly doesn’t exist, add a `<Note>` explaining why.
|
||||
- Every journey must follow **Install → Configure → Add → Search → Delete** (or closest equivalents). Drop verification `<Info icon="check">` immediately after the critical operation.
|
||||
- When migrating an existing quickstart, reuse canonical snippets and screenshots—reshape them into this flow rather than rewriting content unless the product changed.
|
||||
- When migrating an existing quickstart, reuse canonical snippets and screenshots. Reshape them into this flow rather than rewriting content unless the product changed.
|
||||
- If you include a Mermaid diagram, keep it optional and render left-to-right (`graph LR`) so it doesn’t flood the page.
|
||||
- End with exactly two CTA cards: left = related/alternative path, right = next step in the journey. No link farms.
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
Paste the block below into a new quickstart, then replace **every** placeholder. Remove optional sections only after the happy path is working.
|
||||
|
||||
````mdx
|
||||
---
|
||||
title: [Quickstart title — action focused]
|
||||
title: [Quickstart title: action focused]
|
||||
description: [1 sentence outcome]
|
||||
icon: "rocket"
|
||||
estimatedTime: "[~X minutes]"
|
||||
---
|
||||
|
||||
# [Hero headline — promise the win]
|
||||
# [Hero headline: promise the win]
|
||||
|
||||
<Info>
|
||||
**Prerequisites**
|
||||
|
||||
+13
-13
@@ -6,21 +6,21 @@ icon: "megaphone"
|
||||
|
||||
# Release Notes Template
|
||||
|
||||
Release notes are heartbeat updates. They tell readers what shipped, what needs attention, and where to go for the deep dive—fast.
|
||||
Release notes are heartbeat updates. They tell readers what shipped, what needs attention, and where to go for the deep dive fast.
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter must include `title`, `description`, `icon`, `releaseDate`, and `version`. Add `tags` if you need filters (e.g., `["platform", "oss"]`).
|
||||
- Lead with a one-sentence headline plus a quick stats table (New features, Fixes, Required action). Keep the TL;DR in an `<Info>` block; use `<Warning>` only for breaking changes or deadlines.
|
||||
- Organize the body into Highlights, Improvements & fixes (grouped by product), and Known issues. Each bullet links to docs where appropriate.
|
||||
- When reshaping older release notes, retain the shipped items and shout-outs—map them to these sections instead of rewriting history.
|
||||
- When reshaping older release notes, retain the shipped items and shout-outs. Map them to these sections instead of rewriting history.
|
||||
- Include an Upgrade checklist with concrete next steps. Optional “Community shout-outs” should remain short.
|
||||
- Two-card CTA at the end, as always: left = deeper reference, right = applied next step.
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
Paste the snippet below, swap placeholders, and trim optional sections only once you know they’re unnecessary.
|
||||
|
||||
```mdx
|
||||
@@ -54,9 +54,9 @@ tags: ["platform", "oss"] # Optional filters
|
||||
|
||||
## Highlights
|
||||
|
||||
- **[Feature name]** — [One-sentence benefit]. [Link to doc]
|
||||
- **[Feature name]** — [One-sentence benefit]. [Link to doc]
|
||||
- **[Feature name]** — [One-sentence benefit]. [Link to doc]
|
||||
- **[Feature name]:** [One-sentence benefit]. [Link to doc]
|
||||
- **[Feature name]:** [One-sentence benefit]. [Link to doc]
|
||||
- **[Feature name]:** [One-sentence benefit]. [Link to doc]
|
||||
|
||||
## Improvements & fixes
|
||||
|
||||
@@ -77,18 +77,18 @@ tags: ["platform", "oss"] # Optional filters
|
||||
|
||||
## Known issues
|
||||
|
||||
- **[Issue name]** — `[Status]`. `[Workaround or link].`
|
||||
- **[Issue name]** — `[Status]`. `[Workaround or link].`
|
||||
- **[Issue name]:** `[Status]`. `[Workaround or link].`
|
||||
- **[Issue name]:** `[Status]`. `[Workaround or link].`
|
||||
|
||||
## Upgrade checklist
|
||||
|
||||
- [ ] `[Step 1 — update package or config]`
|
||||
- [ ] `[Step 2 — run migration or toggle setting]`
|
||||
- [ ] `[Step 3 — verify workflow or metric]`
|
||||
- [ ] `[Step 1: update package or config]`
|
||||
- [ ] `[Step 2: run migration or toggle setting]`
|
||||
- [ ] `[Step 3: verify workflow or metric]`
|
||||
|
||||
## Community shout-outs
|
||||
|
||||
- [Contributor or team] — `[Short thank-you message].`
|
||||
- [Contributor or team]: `[Short thank-you message].`
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
|
||||
+3
-3
@@ -10,18 +10,18 @@ Overview pages orient readers for an entire section. Summarize who it’s for, s
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter must include `title`, `description`, `icon`. Keep the hero paragraph under two sentences describing audience + outcome.
|
||||
- Provide an `<Info>` block pointing to the primary entry point (usually the quickstart). Use `<Warning>` only for major caveats (beta, deprecation).
|
||||
- Stage journeys in 4–6 cards total. Break into multiple `<CardGroup>` rows when a binary choice (e.g., Python vs Node) or stacked journeys reads better. Keep copy ≤15 words with icons + links.
|
||||
- When migrating an existing overview, reuse the established journeys, images, and stats—reshape them into this layout rather than cutting content unless it’s outdated.
|
||||
- When migrating an existing overview, reuse the established journeys, images, and stats. Reshape them into this layout rather than cutting content unless it’s outdated.
|
||||
- Optional accordions (`<AccordionGroup>`) can tuck detailed tables (feature breakdowns, comparisons) beneath the hero when extra context is helpful.
|
||||
- Optional visuals (comparison table, Mermaid diagram) should be left-to-right and only added when they reduce confusion.
|
||||
- Finish with exactly two CTA cards: left = adjacent/alternative track, right = next logical step deeper in the section.
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
|
||||
````mdx
|
||||
---
|
||||
|
||||
+3
-3
@@ -10,17 +10,17 @@ Troubleshooting playbooks map symptoms to diagnostics and fixes. Keep them fast
|
||||
|
||||
---
|
||||
|
||||
## ❌ DO NOT COPY — Guidance & Constraints
|
||||
## ❌ DO NOT COPY: Guidance & Constraints
|
||||
- Frontmatter must include `title`, `description`, `icon`. Lead with one sentence about the system or workflow this playbook covers.
|
||||
- Add an `<Info>` block (“Use this when…”) and a quick index table (Symptom, Likely cause, Fix link). Surface critical safety warnings in `<Warning>`.
|
||||
- Each symptom section needs: diagnostic command/snippet, `<Info icon="check">` expected output, `<Warning>` for the observed failure, numbered fix steps, and optional `<Tip>` for prevention.
|
||||
- If you’re migrating an existing playbook, carry forward the known failure modes and scripts—reformat them into this structure unless the troubleshooting path changed.
|
||||
- If you’re migrating an existing playbook, carry forward the known failure modes and scripts. Reformat them into this structure unless the troubleshooting path changed.
|
||||
- Group unrelated issues with horizontal rules and provide escalation guidance when self-service stops.
|
||||
- Conclude with prevention checklist, related docs, and the standard two-card CTA (concept/reference left, applied workflow right).
|
||||
|
||||
---
|
||||
|
||||
## ✅ COPY THIS — Content Skeleton
|
||||
## ✅ COPY THIS: Content Skeleton
|
||||
|
||||
````mdx
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user