work-on

You are given an issue or external PR to implement. The input may be a URL, pasted issue text, or pasted PR diff/description.

**Input:** $ARGUMENTS

## Workflow

Follow these steps in order:

### 1. Understand the task
- If given a URL, fetch it to read the issue/PR details.
- Analyze the issue or PR to understand what needs to be done.
- Summarize the task back to the user and confirm before proceeding.

### 2. Create a branch
- Create a descriptive branch name based on the task (e.g., `fix/cell-formatting-bug`, `feat/add-batch-update`).
- Branch from `main`.

### 3. Implement the changes
- Make the necessary code changes.
- Follow existing code patterns and conventions in the project.

### 4. Add or update tests
- Add tests for the new functionality or bug fix in `src/test/`.
- Follow existing test patterns — tests are integration tests that hit real Google APIs.
- If modifying existing behavior, update relevant existing tests as needed.
- To validate, only run the relevant test file(s) to avoid rate limiting: `bun vitest run src/test/<relevant-file>.test.ts`
- Do NOT run the full test suite.

### 5. Update documentation
- If your changes affect the public API (new methods, changed parameters, new features, etc.), update the relevant docs in `docs/`.
  - Class API docs are in `docs/classes/` (one file per class: `google-spreadsheet.md`, `google-spreadsheet-worksheet.md`, `google-spreadsheet-row.md`, `google-spreadsheet-cell.md`).
  - Guides are in `docs/guides/`.
  - The sidebar is `docs/_sidebar.md` — update it if adding a new page.
- Match the style and format of the existing documentation.

### 6. Lint
- Run `bun run lint:fix` to auto-fix any lint issues.
- If lint errors remain, fix them manually.

### 7. Add a changeset
- Run `bun changeset` — since this is interactive, instead create the changeset file directly.
- Create a `.changeset/<descriptive-name>.md` file with the appropriate format:
  ```
  ---
  "google-spreadsheet": <patch|minor|major>
  ---

  <Short description of the change>
  ```
- Use `patch` for bug fixes, `minor` for new features and non-breaking changes, `major` for breaking changes.

### 8. Commit and push
- Stage and commit all changes with a clear commit message.
- Push the branch to origin.

### 9. Create a PR
- Use `gh pr create` to open a pull request.
- Write a clear title and description summarizing the changes.
- If the input was a GitHub issue, reference it in the PR body (e.g., "Fixes #123").
- Return the PR URL to the user.