take

Take

tldraw/tldraw の問題を見つけ、実装し、プルリクエストを開きます。

ワークフロー

1. 問題を見つける

ユーザーは番号、URL、または説明で問題を参照する場合があります。

• 番号または URL の場合は、問題を直接取得します：

gh issue view 123 --repo tldraw/tldraw

• 説明の場合は、まずオープンな問題を検索します：

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

• 一致するオープンな問題がない場合は、すべての問題を検索します：

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

明確に一致するものが 1 つある場合は、先に進みます。複数の問題が一致する場合は、問題番号とタイトルから選択するようユーザーに尋ねます。一致するものがない場合は、issue スキルを使用して新しい問題を作成するかどうかを尋ねます。

2. 問題を理解する

問題とコメントをすべて読みます。以下を特定します：

• 問題の種類：バグ、機能、改善、クリーンアップ、ドキュメント、またはタスク。
• 要求される動作と受け入れ基準。
• 技術的な注意事項と影響を受けるファイル。
• 関連する議論や明確化。

エージェントが作成した問題には、## Confidence および ## Open questions セクションが含まれる場合があります。コードベースの調査によって意図された動作が明確であると証明されない限り、未回答の Critical: の質問、_Awaiting answer._ の項目、または More Info Needed ラベルをブロッカーとして扱います。ブロッカーは実装前にユーザーと解決します。_Deferred by user; not blocking implementation._ とマークされた非クリティカルな質問は、未解決のままにしておいてかまいません。

問題に詳細が欠けている場合は、実装が安全かどうかを判断する前にコードベースを調査します。

3. 問題をアサインする

問題を現在の GitHub ユーザーにアサインします。すでに他の誰かがアサインされている場合は、続行するかどうかをユーザーに尋ねます。

4. 実装を計画する

以下に基づいて、簡潔な実装チェックリストを作成します：

• 問題の説明。
• 受け入れ基準。
• コードベースの調査。
• 既存のリポジトリのパターン。

5. 実装する

main から新しいブランチを作成します。

チェックリストを順に進めます：

• 編集する前にファイルを読みます。
• 既存のパターンに従います。
• 変更は問題に焦点を当てたものに保ちます。
• 推測に基づく改善は避けます。
• 問題が要求する場合は、ドキュメント、サンプル、テスト、または API レポートを更新します。

6. 検証する

まず最も小さい関連するチェックを実行します。変更が共有動作に影響する場合は、より広範なチェックを使用します。

一般的な最終チェック：

pnpm typecheck
pnpm lint

パッケージに焦点を当てた変更の場合は、リポジトリ全体のチェックよりも関連するワークスペースのテストを優先します。

7. PR を作成する

pr スキルを使用します。

• Closes #<issue-number> で問題をリンクします。
• 問題の議論から関連するコンテキストを含めます。
• 明確なテスト計画を含めます。

8. まとめる

最後に以下を記載します：

• 実装した問題。
• 主な変更点と変更したファイル。
• 実行した検証。
• PR リンク。
• 該当する場合は、手動テストの手順。
• 満たすことができなかった受け入れ基準とその理由。

ルール

• 要件が不明確な場合はユーザーに尋ねます。未回答のクリティカルな質問や未解決の _Awaiting answer._ プレースホルダーを越えて実装しないでください。
• 指定されていない製品の動作を推測しないでください。
• 実装は問題の範囲内に保ちます。
• コミット、問題、PR に AI の帰属情報を含めないでください。