Back to list
tldraw

write-pr

by tldraw

very good whiteboard infinite canvas SDK

44,737🍴 2,941📅 Jan 23, 2026

Use Cases

📝

Documentation Generation

Auto-generate documentation from code.

✍️

Content Creation Support

Assist in creating blog posts and marketing content.

🎨

UI Component Generation

Generate UI components from designs.

SKILL.md


name: write-pr description: Writing pull request titles and descriptions for the tldraw repository. Use when creating a new PR, updating an existing PR's title or body, or when the /pr command needs PR content guidance.

Writing pull requests

Standards for PR titles and descriptions in tldraw/tldraw.

PR title

Use semantic PR titles (Conventional Commits format):

<type>(<scope>): <description>

Types

  • feat - New feature
  • fix - Bug fix
  • docs - Documentation only
  • refactor - Code change that neither fixes a bug nor adds a feature
  • perf - Performance improvement
  • test - Adding or fixing tests
  • chore - Maintenance tasks

Scope (optional)

A noun describing the affected area: fix(editor):, feat(sync):, docs(examples):

Examples

  • feat(editor): add snap threshold configuration option
  • fix(arrows): correct binding behavior with rotated shapes
  • docs: update sync documentation
  • refactor(store): simplify migration system

PR body

Use this template:

<description paragraph>

### Change type

- [x] `bugfix` | `improvement` | `feature` | `api` | `other`

### Test plan

1. Step to test...
2. Another step...

- [ ] Unit tests
- [ ] End to end tests

### Release notes

- Brief description of changes for users

Description paragraph

Start with: "In order to X, this PR does Y."

  • Keep it specific - avoid vague phrases like "improve user experience"
  • Link related issues in the first paragraph
  • Don't expect readers to also read the linked issue

Change type

  • Tick exactly one type with [x]
  • Delete unticked items

Test plan

  • List manual testing steps if applicable
  • Remove the numbered list if changes cannot be manually tested
  • Tick checkboxes for included test types

Release notes

  • Write brief notes describing user-facing changes
  • Use imperative mood: "Add...", "Fix...", "Remove..."
  • Omit this section entirely for internal work (CI, tooling, tests, etc.) that has no user-facing impact

API changes section

Include when changes affect api-report.md:

### API changes

- Added `Editor.newMethod()` for X
- Breaking! Removed `Editor.oldMethod()`
- Changed `Editor.method()` to accept optional `options` parameter

Search for and link relevant issues that this PR addresses.

Important

  • Never include "Generated with Claude Code" unless the PR directly relates to Claude Code
  • Never use title case for descriptions - use sentence case

Score

Total Score

80/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 1000以上

+15
最近の活動

1ヶ月以内に更新

+10
フォーク

10回以上フォークされている

+5
Issue管理

オープンIssueが50未満

0/5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

+5

Reviews

💬

Reviews coming soon