home / skills / tldraw / tldraw / write-tbp

write-tbp skill

/.claude/skills/write-tbp

This skill helps you generate technical blog posts about tldraw implementations, guiding research, outlining insights, and drafting structured, code-backed

npx playbooks add skill tldraw/tldraw --skill write-tbp

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
3.4 KB
---
name: write-tbp
description: Writing technical blog posts about tldraw features and implementation details. Use when creating blog content about how tldraw solves interesting problems.
---

# Write technical blog post

This skill covers how to write technical blog posts about tldraw's implementation details.

## Process

### 1. Create the workspace

Create an assets folder for this topic:

```
.claude/skills/write-tbp/assets/<topic>/
├── research.md   # Gathered context and notes
└── draft.md      # The blog post draft
```

Use a short, kebab-case name for the topic (e.g., `scribbles`, `arrow-routing`, `dash-patterns`).

### 2. Research the topic

Use an Explore subagent to gather all relevant information:

```
Task (subagent_type: Explore, thoroughness: very thorough)

Find all code, documentation, and context related to [TOPIC] in the tldraw codebase.

Look for:
- Implementation files in packages/editor and packages/tldraw
- Type definitions in packages/tlschema
- Related examples in apps/examples
- Any existing documentation in apps/docs/content
- Tests that reveal behavior
- Comments explaining why things work the way they do

For each relevant file, note:
- What it does
- Key functions/classes
- Interesting implementation details
- Any "why" comments or non-obvious decisions

Output a comprehensive summary of how [TOPIC] works. This document will be read by another agent. No need to over-optimize for human readability.
```

Save the research output to `assets/<topic>/research.md`.

### 3. Identify the interesting angle

Before writing, answer these questions from the research:

- **What problem does this solve?** Not "what does it do" but "what would go wrong without it?"
- **What's surprising or unintuitive?** The obvious approach that doesn't work, or the hidden complexity.
- **What's the key insight?** The "aha" that makes the solution work.
- **What did we try first?** Any journey or iteration visible in the code or comments.

If you can't find an interesting angle, the topic may not be suitable for a technical blog post.

### 4. Write the draft

Create `assets/<topic>/draft.md` following the blog-guide structure:

1. **Frame the problem** — Hook the reader with context and tension
2. **Show the insight** — The key idea that makes it work
3. **Walk through the implementation** — Code and explanation, building complexity
4. **Wrap up** — Where it lives, tradeoffs, links to files

Target 800-1500 words.

### 5. Self-evaluate

Check the draft against the blog-guide checklist:

- [ ] **Opening** — Does it frame a problem before diving into solution?
- [ ] **Insight** — Is there a clear "aha" moment or key idea?
- [ ] **Specificity** — Is this grounded in tldraw's actual implementation?
- [ ] **Code** — Do examples build understanding, not just show syntax?
- [ ] **Tone** — Warm and personal, but not rambling?
- [ ] **Links** — Points to actual code in the repo?
- [ ] **Length** — Appropriate depth for the topic?

Revise the draft to address any gaps.

### 6. Output

Present the final draft to the user for review. The draft remains in `assets/<topic>/draft.md` until the user is satisfied, at which point they can move it to the appropriate location.

## References

- **Style guide**: See `../shared/blog-guide.md` for voice, tone, and structure.
- **Writing guide**: See `../shared/writing-guide.md` for general writing conventions.

Overview

This skill helps you write technical blog posts about tldraw features and implementation details. It guides research, discovery of an engaging angle, and drafting a focused post that explains why a solution exists and how it works in the tldraw codebase.

How this skill works

The skill prescribes a repeatable process: create a topic workspace, run a thorough codebase exploration to gather files and notes, identify the compelling technical angle, draft a structured post, and self-evaluate against a checklist. Research output and the draft are saved to a small assets folder so you can iterate and review before publishing.

When to use it

  • Explaining how a specific tldraw subsystem (routing, sync, rendering) is implemented
  • Turning tests, examples, or comments in the repo into a readable engineering article
  • Documenting non-obvious design decisions or tradeoffs in the SDK
  • Preparing a deep-dive for an engineering blog targeted at developers using tldraw
  • Creating educational content that links directly to implementation files and examples

Best practices

  • Use a short kebab-case topic name and create a dedicated assets/<topic>/ folder
  • Run a thorough Explore step: collect files, key functions, tests, and 'why' comments
  • Focus the draft on a clear problem, the surprising insight, and step-by-step implementation
  • Include concrete code snippets that build understanding, not just show syntax
  • Self-evaluate against checklist items: opening, insight, specificity, code, tone, links

Example use cases

  • A post that explains arrow-routing: why naive approaches fail and how tldraw routes connectors
  • A deep-dive into collaborative sync: what the protocol does and how conflicts are resolved
  • An article on infinite canvas rendering optimizations and how tile culling is implemented
  • A walkthrough of gesture handling in the React integration and event flow
  • A tutorial that maps tests and examples to real implementation files for learners

FAQ

How long should the draft be?

Target 800–1500 words so you can cover motivation, insight, and implementation with examples.

What files should I inspect first?

Start in packages/editor, packages/tldraw, and packages/tlschema, then check apps/examples, apps/docs/content, and tests for behavior clues.

What if I can't find an interesting angle?

If research yields no surprising tradeoffs or failures of simpler approaches, the topic may not be suitable for a technical deep-dive—pick a different area or broaden scope.