tldraw
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.
bunx add-skill tldraw/tldraw -s write-prLoading…
Standards for PR titles and descriptions in tldraw/tldraw.
Use semantic PR titles (Conventional Commits format):
<type>(<scope>): <description>
feat - New featurefix - Bug fixdocs - Documentation onlyrefactor - Code change that neither fixes a bug nor adds a featureperf - Performance improvementtest - Adding or fixing testschore - Maintenance tasksA noun describing the affected area: , ,
fix(editor):feat(sync):docs(examples):feat(editor): add snap threshold configuration optionfix(arrows): correct binding behavior with rotated shapesdocs: update sync documentationrefactor(store): simplify migration systemUse 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
Start with: "In order to X, this PR does Y."
[x]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.
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.