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.

Source: theoephraim/node-google-spreadsheet — distributed by TomeVault.