Wrong transition
“Done” can mean a state, transition ID, or a closed flag. Resolve intent against the provider before writing.
The safe write layer for coding agents
Create, update, comment on, and transition work across GitHub, Linear, Jira, and Azure DevOps with one typed API — with previews, idempotency, and conflict protection built in.
import { createWorkClient } from "work-sdk";
import { github } from "work-sdk/github";
const work = createWorkClient({
adapter: github({
owner: "acme",
repo: "api",
token: process.env.GITHUB_TOKEN!
}),
});
const change = await work.prepareUpdate(
"481",
{ state: "done" },
);
await work.commit(change, {
idempotencyKey: "merge:api#481",
});Proposed change
Mapped ‘done’ to GitHub’s closed state
Inspect exact changes and provider warnings before anything is written.
One normalized model for
More adapters welcome
Built for real side effects
Provider APIs disagree on states, identities, revisions, rich text, and error shapes. Work SDK puts those differences behind a typed, inspectable boundary.
“Done” can mean a state, transition ID, or a closed flag. Resolve intent against the provider before writing.
A timeout does not say whether a write succeeded. Idempotency makes retries deterministic.
An item can change between read and write. Revision checks stop agents from erasing newer work.
A safer primitive
Turn an irreversible API call into a change you can reason about, approve, log, and replay.
Fetch current state, normalize provider semantics, and calculate the exact diff.
work.prepareUpdate(…)Review field changes, lossy mappings, unsupported capabilities, and expected revision.
change.warningsVerify the plan and revision, then commit with a stable idempotency key.
work.commit(change)Small API, serious guarantees
A prepared change carries a fingerprint. Mutate it after inspection and the SDK rejects the commit.
Retry without creating duplicate comments or repeated updates.
Check support instead of asking an agent to guess.
Handle auth, rate limits, conflicts, and unsupported fields consistently.
ESM and CommonJS builds, zero runtime dependencies, Node.js 20+.
Honest by design
Capabilities are data, not scattered documentation. Detect support before an agent proposes an action.
Explore adapter docs| Capability | GitHub | |||
|---|---|---|---|---|
| Create and update | Supported | Supported | Supported | Supported |
| Comments | Supported | Supported | Supported | Supported |
| Custom states | — | Supported | Supported | Supported |
| Multiple assignees | Supported | — | — | — |
| Optimistic concurrency | Supported | Supported | Supported | Supported |
Straight answers
No. It is an open-source TypeScript library that runs in your application. You bring credentials for the trackers you already use.
Yes. Normalized entities can retain the raw provider payload for fields that are not part of the portable core.
No. Work SDK gives approval systems a concrete diff and warnings to evaluate. Your application decides when a human must approve a commit.
Yes. Adapters implement a compact contract and can be tested against the shared conformance suite.
Give agents a safer tool
Start with one provider. Keep one API when your stack changes.