take

Take

Find an issue in tldraw/tldraw, implement it, and open a pull request.

Workflow

1. Find the issue

The user may reference an issue by number, URL, or description.

• For a number or URL, fetch the issue directly:

gh issue view 123 --repo tldraw/tldraw

• For a description, search open issues first:

gh issue list --repo tldraw/tldraw --search "dark mode" --state open --limit 10

• If no open issue matches, search all issues:

gh issue list --repo tldraw/tldraw --search "dark mode" --state all --limit 10

If there is one clear match, proceed. If several issues match, ask the user to choose from issue numbers and titles. If none match, ask whether to create a new issue using the issue skill.

2. Understand the issue

Read the full issue and comments. Identify:

• Issue type: bug, feature, enhancement, cleanup, docs, or task.
• Requested behavior and acceptance criteria.
• Technical notes and affected files.
• Relevant discussion or clarifications.

Agent-drafted issues may include ## Confidence and ## Open questions sections. Treat any unanswered Critical: question, _Awaiting answer._ entry, or More Info Needed label as a blocker unless codebase exploration proves the intended behavior is unambiguous. Resolve blockers with the user before implementing; non-critical questions marked _Deferred by user; not blocking implementation._ may remain open.

If the issue lacks detail, explore the codebase before deciding whether implementation is safe.

3. Assign the issue

Assign the issue to the current GitHub user. If someone else is already assigned, ask the user whether to proceed.

4. Plan the implementation

Create a concise implementation checklist based on:

• The issue description.
• Acceptance criteria.
• Codebase exploration.
• Existing repo patterns.

5. Implement

Create a new branch from main.

Work through the checklist:

• Read files before editing them.
• Follow existing patterns.
• Keep changes focused on the issue.
• Avoid speculative improvements.
• Update docs, examples, tests, or API reports when the issue requires it.

6. Verify

Run the smallest relevant checks first. Use broader checks when the change touches shared behavior.

Typical final checks:

pnpm typecheck
pnpm lint

For focused package changes, prefer the relevant workspace tests before repo-wide checks.

7. Create the PR

Use the pr skill.

• Link the issue with Closes #<issue-number>.
• Include relevant context from the issue discussion.
• Include a clear test plan.

8. Summarize

End with:

• Issue implemented.
• Key changes and files modified.
• Verification performed.
• PR link.
• Manual testing steps, if relevant.
• Any acceptance criteria that could not be met and why.

Rules

• Ask the user when requirements are unclear. Do not implement past unanswered critical questions or unresolved _Awaiting answer._ placeholders.
• Do not guess at unspecified product behavior.
• Keep the implementation scoped to the issue.
• Never include AI attribution in commits, issues, or PRs.