| name | write-issue |
| description | Writing and maintaining GitHub issues for the tldraw repository. Use when creating new issues, editing issue titles/bodies, triaging issues, or cleaning up issue metadata (types, labels). |
Writing and maintaining GitHub issues
Standards for issues in tldraw/tldraw.
Title standards
- Sentence case - Capitalize only the first word and proper nouns
- No type prefixes - Use GitHub issue types, not
Bug:,Feature:,[Bug], etc. - Imperative mood for enhancements - "Add padding option" not "Adding padding option"
- Descriptive for bugs - Describe the symptom: "Arrow bindings break with rotated shapes"
- Specific - Readable without opening the issue body
Good titles
Arrow bindings break with rotated shapesAdd padding option to zoomToFit methodPinch zoom resets selection on Safari
Bad titles
Bug: arrow bug(prefix, vague)[Feature] Add new feature(prefix, vague)Not working(vague)
Title cleanup transformations
- Remove prefixes:
Bug: X→X - Fix capitalization:
Add Padding Option→Add padding option - Use imperative:
Adding feature X→Add feature X - Be specific:
Problem→[Describe the actual problem] - Translate non-English titles to English
Issue types
Set via the GitHub GraphQL API after creating the issue (the --type flag is not reliably supported):
| Type | Use for |
|---|---|
Bug |
Something isn't working as expected |
Feature |
New capability or improvement |
Example |
Request for a new SDK example |
Task |
Internal task or chore |
Labels
Use sparingly (1-2 per issue) for metadata, not categorization.
Common labels
| Label | Use for |
|---|---|
good first issue |
Well-scoped issues for newcomers |
More Info Needed |
Requires additional information |
sdk |
Affects the tldraw SDK |
dotcom |
Related to tldraw.com |
a11y |
Accessibility |
performance |
Performance improvement |
api |
API change |
Automation labels (do not apply manually)
keep, stale, update-snapshots, publish-packages, major, minor, skip-release, deploy triggers
Issue body standards
Bug reports
- Clear description of what's wrong
- Steps to reproduce
- Expected vs actual behavior
- Environment details (browser, OS, version) when relevant
- Screenshots/recordings when applicable
Feature requests
- Problem statement - What problem does this solve?
- Proposed solution - How should it work?
- Alternatives considered
- Use cases
Example requests
- What API/pattern to demonstrate
- Why it's useful
- Suggested approach
- Which example category it belongs to
Triage workflow
New issues
- Verify sufficient information to act on
- Set appropriate issue type
- Clean up title if needed
- Add
More Info Neededlabel and comment if details missing - Add
good first issueif appropriate
Stale issues
- Review if still relevant
- Close if no longer applicable
- Add
keeplabel if should remain open - Request updates if waiting on information
Important
- Never include "Generated with Claude Code" unless the PR directly relates to Claude Code
- Never use title case for descriptions - use sentence case