tldraw
Writing SDK documentation for tldraw. Use when creating new documentation articles, updating existing docs, or when documentation writing guidance is needed. Applies to docs in apps/docs/content/.
bunx add-skill tldraw/tldraw -s write-docsLoading…
Write like a colleague walking someone through code they know well. Confident, casual, code-first.
Characteristic patterns:
Have five minutes? Run this command...
That's pretty much it!
Let's add local persistence by passing a
persistenceKeyprop...
Need to create some shapes? Use Editor#createShapes. Need to delete them? Use Editor#deleteShapes.
What makes it work:
State facts. Don't soften them.
// Good
The Editor class is the main way of controlling tldraw's editor.
// Bad
The Editor class can be used to control tldraw's editor.
Real tldraw docs are code-heavy. A section might be 20 lines of code with 2 sentences of explanation. Don't pad with prose.
These break trust instantly:
---
title: Feature name
status: published
author: steveruizok
date: 3/22/2023
order: 1
keywords:
- keyword1
- keyword2
---
Use [ClassName](?) or [ClassName#methodName](?) for API references:
The [Editor](?) class has many methods. Use [Editor#createShapes](?) to create shapes.
Use <FocusLines> to highlight specific lines:
<FocusLines lines={[2,6,10]}>
\`\`\`tsx
import { Tldraw } from 'tldraw'
import { useSyncDemo } from '@tldraw/sync'
\`\`\`
</FocusLines>
<Image
src="/images/api/events.png"
alt="A diagram showing an event being sent to the editor."
title="Caption text here."
/>
Use tables for listing methods, options, or properties:
| Method | Description |
| ------------------------ | ---------------------------------------------- |
| [Editor#screenToPage](?) | Convert a point in screen space to page space. |
| [Editor#pageToScreen](?) | Convert a point in page space to screen space. |
| Value | Description |
| --------- | ---------------------------------------------------- |
| `default` | Sets the initial zoom to 100%. |
| `fit-x` | The x axis will completely fill the viewport bounds. |
Show code early, explain around it. Don't build up to code with paragraphs of context.
// Good: Real shape, real values
editor.createShapes([
{
type: 'geo',
x: 0,
y: 0,
props: { geo: 'rectangle', w: 100, h: 100 },
},
])
// Bad: Placeholder nonsense
editor.createShape({ type: 'example-type', props: { prop1: 'value1' } })
Full components are fine when showing integration patterns:
export default function App() {
return (
<div style={{ position: 'fixed', inset: 0 }}>
<Tldraw persistenceKey="example" />
</div>
)
}
Minimal snippets when showing a single API:
editor.setFocusedGroup(groupId)
1-2 paragraphs establishing what and why before diving into how.
Start with the common case. Add complexity incrementally. Put edge cases later.
End sections with links to relevant examples:
> For an example of how to create custom shapes, see our [custom shapes example](/examples/shapes/tools/custom-shape).
Or in a section:
---
See the [tldraw repository](https://github.com/tldraw/tldraw/tree/main/apps/examples) for examples of how to use tldraw's Editor API.
Use when you need to run Flow type checking, or when seeing Flow type errors in React code.
Use when you want to validate changes before committing, or when you need to check all React contribution requirements.
Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or adding new flags to React.
Use when you need to check feature flag states, compare channels, or debug why a feature behaves differently across release channels.