work-on

Engineering Community

Repo stars 2,483
License MIT
Author repo node-google-spreadsheet

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Work on an issue or PR - implement changes, add tests, update docs, lint, add bump file, and create a PR You are given an issue…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Workflow”, “1. Understand the task”, “2. Create a branch”, “3. Implement the changes”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name work-on directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Workflow / 1. Understand the task / 2. Create a branch” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

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.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 94 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @theoephraim · MIT
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: macOS · Linux · Windows
Runtime requirements: Bun
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: External requests
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview work-on.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

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

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Workflow → 1. Understand the task → 2. Create a branch → 3. Implement the changes → 4. Add or update tests → 5. Update documentation
terms    -> Input · You are given an issue or external PR to implement. · <Short description of the change> - Use patch for bug fixes, minor for new features and non-breaking changes, major for breaking changes.
files/cmd -> fix/cell-formatting-bug · feat/add-batch-update · main · src/test/ · bun vitest run src/test/<relevant-file>.test.ts · docs/ · docs/classes/ · google-spreadsheet.md
body sha256 -> 004549b64a69