Some checks failed
Deploy analytics worker / Deploy analytics worker to ${{ (github.ref == 'refs/heads/production' && 'production') || (github.ref == 'refs/heads/main' && 'staging') || 'preview' }} (push) Failing after 1s
i18n upload strings / Upload latest strings (push) Failing after 1s
Deploy bemo / Deploy bemo to ${{ (github.ref == 'refs/heads/bemo-production' && 'production') || (github.ref == 'refs/heads/main' && 'staging') || 'preview' }} (push) Failing after 1s
Deploy grafana resources / ${{ github.event_name == 'push' && 'Deploy grafana resources' || 'Validate grafana resources (dry run)' }} (push) Failing after 0s
End to end tests (dotcom) / Check for relevant changes (push) Failing after 0s
End to end tests (examples) / Check for relevant changes (push) Failing after 0s
End to end tests (mermaid readability) / Check for relevant changes (push) Failing after 1s
End to end tests (perf) / Check for relevant changes (push) Failing after 0s
Publish editor extensions / Publish editor extensions (push) Failing after 1s
Publish SDK packages / Remove the publish-packages label (push) Has been skipped
Checks / Tests & checks (push) Has been cancelled
Checks / Build all projects (push) Has been cancelled
Deploy templates / Deploy templates (push) Has been cancelled
End to end tests (dotcom) / End to end tests (dotcom) (push) Has been cancelled
End to end tests (mermaid readability) / End to end tests (mermaid readability) (push) Has been cancelled
End to end tests (perf) / End to end tests (perf) (push) Has been cancelled
Deploy .com / Deploy dotcom to ${{ (github.ref == 'refs/heads/production' && 'production') || (github.ref == 'refs/heads/main' && 'staging') || 'preview' }} (push) Has been cancelled
End to end tests (examples) / End to end tests (examples) (push) Has been cancelled
Publish SDK packages / Publish SDK packages (push) Has been cancelled
Publish SDK packages / Tell user released version (push) Has been cancelled
Publish SDK packages / Publishes code templates to separate repositories (push) Has been cancelled
Publish SDK packages / Deploys the template demos with the new SDK version (push) Has been cancelled
112 lines
3.3 KiB
Markdown
112 lines
3.3 KiB
Markdown
---
|
|
name: take
|
|
description: Find a GitHub issue in tldraw/tldraw, assign it, implement it, verify it, and open a pull request. Use when the user invokes take, asks to take an issue, implement an issue, work on an issue number or URL, or pick up an issue from a description.
|
|
---
|
|
|
|
# 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:
|
|
|
|
```bash
|
|
gh issue view 123 --repo tldraw/tldraw
|
|
```
|
|
|
|
- For a description, search open issues first:
|
|
|
|
```bash
|
|
gh issue list --repo tldraw/tldraw --search "dark mode" --state open --limit 10
|
|
```
|
|
|
|
- If no open issue matches, search all issues:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
yarn typecheck
|
|
yarn 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.
|